P10-L07 · P10 · P10-M02
Build a timeline from independently inspectable records
Prerequisites: P10-L06
Learning objectives
- Build a timeline from independently inspectable records
- Reproduce the ordering of a bounded resolution-phase incident timeline and distinguish it from an attributed postmortem.
Why this matters
An incident story often compresses months of protocol response into one causal arrow. Independently inspectable headers provide a narrower chronology, while the official publication supplies attributed context.
Explanation
HISTORICAL PROVENANCE WARNING: this package concerns Bitcoin’s 2013 chain incompatibility and a bounded August resolution-phase segment. BIP50 is frozen at an exact repository revision. It describes the March fork and later handling; its assignment date is a document field, not the exact instant of the incident. The package does not reconstruct the March orphan chain or independently verify every miner’s behavior.
The chain portion contains raw 80-byte headers for heights 252450 and 252451, indexed block JSON and exact coinbase transaction references. Run the package verifier: double-SHA256 reproduces both header IDs; the second header’s previous-hash field points to the first. Timestamp subtraction reproduces the declared interval. The record ordering can therefore be inspected separately from the postmortem’s narrative. Canonical-chain and coinbase inclusion labels remain indexer assertions; no full-node replay or native merkle inclusion proof is packaged.
Use two evidence lanes. In the chain lane place precisely scoped header facts; in the publication lane place what the protocol authors say about incompatible software and the resolution boundary. Agreement between them supports the selected locator, not every causal or impact claim. Leave March branch details, global upgrade adoption and economic loss unresolved.
Key terms
Header linkage: previous-block field referencing the preceding header hash.
Declared block time: miner-supplied timestamp, not exact network arrival.
Postmortem: attributed protocol account of an incident.
Resolution phase: bounded later segment, not a complete incident replay.
Historical example
Historical header 252450: 000000000000004bd037574c9171b4871185e7218c529734a1c5445f29114fbe, declared time 2013-08-16T11:45:05Z. Header 252451: 0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07, declared time 2013-08-16T12:09:07Z, references 252450. Difference: 1,442 seconds (24 minutes 2 seconds). BIP50 identifies 252451 in its August resolution discussion. Exact coinbase IDs are preserved in incident-252450-coinbase-id.txt and incident-252451-coinbase-id.txt, with indexed transactions; they are locators, not causal attribution.
OBSERVED: saved publication text, locally reproduced header hashes/link/time fields. INFERRED: compatibility of the selected header locator with the publication’s resolution narrative. UNKNOWN: every node’s upgrade status, complete March competing branches and loss. INSUFFICIENT EVIDENCE: a claim that these two headers prove all participants resolved the incident.
Visual specifications
Historical signal timeline with publication lane for March context and raw-header lane for the two August records. Label declared-time interval 24m02s, exact heights/hashes, indexer inclusion boundary and a March-branch collection gap.
Caption: Historical bounded resolution-phase chronology; not a complete fork replay or all-node recovery proof.
SPECIFICATION_ONLY — the rendered visual has not been produced or independently reviewed.
What the evidence proves
The frozen raw headers reproduce the selected identifiers, their linkage and 1,442-second declared-time interval. The saved official publication contains an attributed incident/resolution account.
What the evidence does not prove
The package proves no exact propagation delay, worldwide node agreement, full March fork history, attacker identity, intent or economic loss. Header spacing is not incident duration.
Common mistakes
Calling the two-header interval the entire incident duration; treating document assignment date as exact event time; claiming all nodes upgraded; using publication context as a substitute for missing branch records.
Practical exercise
Construct a three-row timeline: attributed March context, header252450 and header252451. Compute the interval, label each row’s time basis and source type, and reject the claim “all nodes were fixed after24m02s.”
Show worked correction
The March row belongs to the publication lane and remains attributed context with the postmortem’s precision. The August header rows use raw declared times and exact hashes; 12:09:07 −11:45:05 =24m02s. The second header points to the first, establishing selected-record order. “All nodes were fixed” is not established by two headers or an attributed publication. Report only the bounded resolution locator; leave node census, March branches and incident-wide duration unresolved. Coinbase transaction references are reproducible indexed locators, not evidence of universal adoption.
Checklist
- Verify header hashes and previous-hash linkage offline.
- Separate chain fields from publication assertions.
- Retain exact transaction locators and retrieval times.
- State the bounded August scope and missing March branches.
Summary
Independently inspectable header ordering and attributed protocol context can coexist without supporting a complete incident or impact reconstruction.
Summary
- Chain time and publication dates have different meanings.
- A bounded timeline must show its missing phases.
- Header linkage cannot establish global node behavior.
Next lesson
P10-L08
Tools
Use the named ZECOIN tool only as an evidence-reading context. This lesson creates no tool output, account session or entitlement. Offline exercise; do not sign, deploy, approve or fund anything.
Sources & claim boundaries
-
BIP50: BIP50 — pinned historical postmortem — Attributed March 2013 fork narrative and August block-252451 resolution boundary. Boundary: Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.
-
API: Esplora public API specification — GET routes, integer satoshis and indexed confirmation/outspend fields. Boundary: Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.
-
CHAIN: Frozen historical chain locator — Single-indexer record; historical bytes are frozen, no independent native inclusion or human identity proof.
Evidence classifications
HISTORICAL — event dates and retrieval dates are separate. See frozen package and collection gaps.
Observation date
2026-10-02 (retrieval date; not event time)
Content version
1
Review date
null
Review status
needs_review
Visual specifications
P10-L07-V01
Build a timeline from independently inspectable records
Historical bounded resolution-phase chronology; not a complete fork replay or all-node recovery proof.
Historical signal timeline with publication lane for March context and raw-header lane for the two August records. Label declared-time interval 24m02s, exact heights/hashes, indexer inclusion boundary and a March-branch collection gap.
Historical signal timeline with publication lane for March context and raw-header lane for the two August records. Label declared-time interval 24m02s, exact heights/hashes, indexer inclusion boundary and a March-branch collection gap.
Stack observations, assumptions, gaps and conclusion at 390 px; retain full IDs and a complete text equivalent. Any wide table scrolls locally.
Prose may follow RTL; IDs, quantities and time axes remain LTR. Preserve dependency direction.
P10-FROZEN-RECORDS-v1
Sources & claim boundaries
BIP50 · OFFICIAL_PROTOCOL_PUBLICATION
BIP50 — pinned historical postmortem
- Supported claim
- Attributed March 2013 fork narrative and August block-252451 resolution boundary.
- Verification boundary
- Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.
- Checked at
- 2026-10-02
https://github.com/bitcoin/bips/blob/24e96e870fffaa257b465ce1f0370c14aac588e8/bip-0050.mediawiki
API · PRIMARY_DOCUMENTATION
Esplora public API specification
- Supported claim
- GET routes, integer satoshis and indexed confirmation/outspend fields.
- Verification boundary
- Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.
- Checked at
- 2026-10-02
https://github.com/Blockstream/esplora/blob/master/API.md
CHAIN · PUBLIC_CHAIN_RECORD
Frozen primary chain record locator
- Supported claim
- Exact historical record locator; frozen bytes and claim mappings are in docs/academy-2/datasets/p10.
- Verification boundary
- Single-indexer record; historical bytes are frozen, no independent native inclusion or human identity proof.
- Checked at
- 2026-10-02
https://blockstream.info/api/block/0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07/header
Dataset provenance
id: P10-FROZEN-RECORDS-v1
dataStatus: HISTORICAL
observedAt: 2026-10-02
timeBasis: Historical header timestamps distinct from UTC retrieval times
source: docs/academy-2/datasets/p10/dataset.json
scope: Frozen Bitcoin chain records and attributed BIP50 publication; see source-to-claim matrix and explicit collection gaps.