Back

Historical incident reconstruction

P10-L07 · P10 · P10-M02

Build a timeline from independently inspectable records

HISTORICAL · needs_review

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

SPECIFICATION_ONLY · HISTORICAL

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
Open primary source
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
Open primary source
https://github.com/Blockstream/esplora/blob/master/API.md

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.

Test your reasoning

P10-L07-Q1 · What does the second header’s previous-hash field establish?
P10-L07-Q2 · What is the declared-time interval?
P10-L07-Q3 · How should BIP50’s narrative enter the report?
P10-L07-Q4 · Which limitation is material to a March fork reconstruction?
P10-L07-Q5 · Why retain the coinbase IDs without claiming independent inclusion?