Timechain Wiki

Chain reorganizations

11 min read

A chain reorganization ("reorg") happens when a Bitcoin node receives a new chain of blocks that has more cumulative work than its current chain — and switches to the new chain, treating its prior tip as a stale fork. Reorgs occur naturally and benignly when two miners find blocks at the same height nearly simultaneously, producing a temporary fork that resolves when the next block is found on one side or the other. Most reorgs are 1 block deep; deeper reorgs (2+ blocks) become exponentially rarer because each successive block adds Proof of Work that an attacker would need to overcome. The empirical record shows roughly one 1-block reorg per week on Bitcoin mainnet; reorgs deeper than 3 blocks have been extremely rare in normal operation (a single 6-block reorg in March 2013, caused by a software bug not a malicious actor; effectively zero deep adversarial reorgs in Bitcoin's history). The probability of reversal at confirmation depth d falls roughly exponentially with d, which is what gives rise to the 6-confirmation convention as a practical security threshold for typical transaction values.

Why this note matters

Reorgs are the structural answer to “what does it mean for a transaction to be confirmed?” — and they’re the empirical mechanism connecting Proof of Work to transaction finality. Every Bitcoin transaction’s effective security depends on the reorg-probability distribution: a transaction with 1 confirmation has some risk of being reversed; with 6 confirmations the risk is small; with 100 confirmations the risk is negligible.

The chain-reorganization mechanism also defines what 51%-attacks structurally are. A theoretical attacker with 51% of network hashrate could, in principle, produce a longer chain that excludes their previous spending transactions — a deep reorg. The substantive engagement with whether and when this is feasible lives in Consensus-layer attack theories (Criticisms section); this note is the underlying mechanism reference.

How forks happen

The Bitcoin network is geographically distributed. Block propagation, even with modern compact-block-relay infrastructure, takes a small but nonzero amount of time. When two miners find valid blocks at the same height within the propagation window, two valid chains briefly coexist:

... ← Block N ← Block N+1 (Miner A's block, propagated first to some nodes)
              ← Block N+1 (Miner B's block, propagated first to others)

Nodes that see Miner A’s block first treat it as the tip; nodes that see Miner B’s block first treat that as the tip. Both chains are equally valid (each has one block of work past block N).

The fork resolves when the next block is found. Whichever miner extends one of the chains first creates a chain with more cumulative work, and all nodes converge on it:

... ← Block N ← Block N+1 (B) ← Block N+2  (this becomes the main chain)
              ← Block N+1 (A)              (this becomes a 1-block stale fork)

The block on the “wrong” side of the fork is called an orphan or, more precisely (since “orphan” originally meant a block whose parent was unknown), a stale block. The miner of the stale block loses their block reward — their PoW expenditure was wasted on a chain that no longer wins.

The longest-chain rule (most-cumulative-work)

Nakamoto’s consensus is summarized as “the longest chain wins.” More precisely:

  • Each block contributes work proportional to its target’s inverse — higher difficulty target means more expected hash trials to produce
  • The “main chain” is the chain with the greatest cumulative work, not the greatest block count
  • In practice these almost always coincide (because difficulty adjusts only every 2016 blocks; within a 2016-block window all blocks have the same work)

When two competing chains exist, the rule is to extend whichever you saw first (avoiding favoritism between equally-valid candidates) but switch immediately to a longer chain when one emerges. This is the chain reorganization.

The rule is mechanically simple and economically self-enforcing: miners are rewarded only on the chain they ultimately settle on, which incentivizes building on whichever chain has accumulated the most work (and is therefore most likely to be the eventual winner).

Reorg depth and probability

Reorgs are weighted by depth. A 1-block reorg requires only that a second miner extend the “wrong” chain to height N+2 before any miner extends the right chain. A 2-block reorg requires the wrong chain to extend twice in a row before the right chain extends once. The probability falls geometrically.

Empirical distribution on Bitcoin mainnet (rough averages from chain analysis):

  • 1-block reorgs: ~1 per week
  • 2-block reorgs: ~1 per several months
  • 3-block reorgs: a handful per year
  • 4-block reorgs: very rare; possibly a few in the entire history
  • 5+ block reorgs: extremely rare; effectively only the March 2013 software-bug incident

The March 2013 incident. A consensus bug between Bitcoin Core 0.7 and 0.8 caused a chain split at block 225,430. The split lasted roughly 6 blocks before being resolved manually by miners downgrading to 0.7 (the more conservative side). No funds were lost; the split was caused by a software incompatibility, not by adversarial behavior. This remains the deepest reorg in Bitcoin’s mainnet history.

Theoretical attack-driven reorgs. A 51%-hashrate attacker could produce arbitrary-depth reorgs in expectation, including deep ones. The substantive analysis of when and how such attacks become feasible lives in Consensus-layer attack theories (Criticisms section).

Confirmation depth conventions

Because reorg probability falls with depth, transactions become progressively harder to reverse as more blocks pile on top. The conventional thresholds:

  • 0 confirmations (in mempool, not yet in a block) — accepted only for very-low-value or zero-trust scenarios (e.g., small Lightning channel opens that will close to confirmed funds anyway).
  • 1 confirmation (in the most recent block) — acceptable for low-value retail (sub-$1000 typical). 1-block reorgs do happen routinely.
  • 3 confirmations — exchange deposits for small amounts; some merchant transactions.
  • 6 confirmations — the canonical Bitcoin convention; ~1 hour. Acceptable for typical commercial transactions. The threshold descends from Satoshi’s original whitepaper analysis.
  • 100 confirmations — required for coinbase outputs to become spendable (protocol-enforced). Roughly 16-17 hours. Used by some exchanges for very-large deposits and for inheritance / very-long-term settlements.

The 6-confirmation convention has no protocol-level enforcement; it’s a social/operational standard. It corresponds to the rough point at which an attacker would need substantial computational resources (>>100% of network hashrate sustained for ~1 hour) to produce a reversal — practically impossible without state-level resources.

Per-value scaling. High-value transactions warrant deeper confirmations:

  • $1 transactions: 0-1 confirmations
  • $1,000 transactions: 3-6 confirmations
  • $1 million transactions: 6+ confirmations
  • $100 million transactions: 30+ confirmations (some operators wait days)

The scaling is intuitive but not formalized. The deeper the transaction value, the more attractive an attack becomes, and the deeper confirmations a defender should require.

Double-spending and shallow reorgs

A “double-spend” via reorg looks like:

  1. Attacker constructs transaction T₁ (paying merchant) and broadcasts it
  2. Merchant accepts T₁ at 1 confirmation; delivers goods
  3. Attacker secretly mines an alternative branch containing T₂ (paying themselves with the same input as T₁)
  4. Attacker’s branch surpasses the merchant’s chain in cumulative work
  5. Network reorgs; T₁ is removed from the chain; T₂ takes its place
  6. Merchant has delivered goods but never received Bitcoin

This is the classic 51%-attack threat. The mechanism requires the attacker to outpace the rest of the network in hashrate — which is what makes it expensive and self-limiting (the larger the network’s honest hashrate, the more expensive an attack becomes).

Selfish-mining variant. A mining pool with somewhat-less-than-50% hashrate can in some game-theoretic models gain disproportionate share of rewards by withholding blocks strategically, inducing the rest of the network to waste work on stale chains. The substantive engagement is in Consensus-layer attack theories (Criticisms).

Mitigations beyond confirmation depth. Merchants can refuse 0-confirmation transactions, require pre-confirmed Lightning channels, or use settlement intermediaries that themselves require sufficient confirmation depth. Different transaction values warrant different practices.

Mempool handling during reorgs

When a reorg occurs:

  1. Blocks on the now-stale chain are removed from the chain state
  2. Transactions from those stale blocks return to the node’s mempool (if still valid)
  3. Transactions from the new chain’s blocks are removed from the mempool (they’re now confirmed)
  4. The UTXO set is updated to reflect the new chain

Edge cases. A transaction that was in the stale chain may not return to the mempool if:

  • A conflicting transaction was confirmed in the new chain
  • The original transaction has been evicted for unrelated reasons (mempool eviction during the reorg window)
  • The original transaction depends on a now-invalid UTXO (e.g., a stale-chain coinbase that was reorged out)

This handling is automatic for full nodes. SPV light clients, which trust the longest chain, see reorgs reflected automatically when they re-sync headers.

Tradeoffs and design choices

Why longest-chain rule (vs alternatives)? Nakamoto Consensus chooses simplicity: extend the chain with the most work; everyone converges. Alternative consensus approaches (PBFT-style finality, GHOST tree-based selection, PoS-based slashing) provide stronger or different properties but at substantial complexity costs. Bitcoin’s choice prioritizes minimal trust assumptions and maximal protocol simplicity.

Why 10-minute block times specifically? Long block times reduce orphan rates and reorg frequency. Bitcoin’s 10-minute average produces ~0.5% orphan rate; Ethereum’s ~12-second blocks produce uncle rates around 5-10%. The tradeoff is confirmation latency vs reorg safety. Bitcoin’s choice optimizes for safety.

Why no “rollback after deep reorg” mechanism? The protocol has no exception path for “this reorg is too deep, undo it.” If a 100-block reorg happened, every node would switch to the new chain automatically — even if that meant reversing legitimate-seeming transactions. The reliance on hashrate-economic incentives to prevent such events is the protocol’s structural defense.

6-confirmation convention strength. Six confirmations corresponds to a ~60-minute attack window. For an attacker with 30% of network hashrate, the probability of successfully reversing a 6-confirmation transaction is ~1 in 10,000. For 40%, it’s ~1 in 100. For 50%, it’s near-certain over time. The 6-confirmation convention assumes attackers are in the <30% range, which is empirically the case for current Bitcoin mining.

Reorg-cost economic interpretation. Reversing 6 blocks costs the attacker the foregone block subsidies and fees they’d have earned by honest mining — on the order of 65,000 BTC price, plus fees). For a transaction below this value threshold, the attack is economically irrational even when technically feasible.

Stratum / Coinbase Pro reorg policies. Major exchanges and custodial services formalize their per-coin reorg-handling policies (e.g., “Bitcoin deposits credit after 3 confirmations and become withdrawable after 6”). These policies are tuned empirically against the historical reorg distribution.

For substantive engagement with the 51%-attack and selfish-mining theoretical concerns, see Consensus-layer attack theories (Criticisms). For the structural mining-centralization landscape that determines attack feasibility, see Mining centralization concerns (Criticisms) and Mining pool centralization and the AI infrastructure pivot (Controversies).

Open questions for further development

  • How does the long-run security budget affect reorg risks? As block subsidies decline and fees become the primary mining reward, miner incentives may shift in ways that interact with reorg-economic-defenses. See Long-term security budget.
  • Are there practical second-layer constructions (e.g., Lightning’s force-closure mechanisms) that need explicit confirmation-depth tuning as reorg patterns evolve?
  • What is the right operational policy for exchanges and custodians as Bitcoin’s hashrate-concentration shifts? Are 6-confirmation conventions still appropriate, or should they tighten or loosen?
  • Should there be a formal protocol-level metric for “this transaction is settled and cannot be reversed under any feasible attack”? The current implicit consensus around 100+ confirmations is informal.

Canonical sources for this note

Foundational sources

Empirical research

  • Various academic papers on Bitcoin’s reorg empirical distribution (e.g., Gencer et al. on decentralization metrics; the chain-of-blocks measurement work).
  • Glassnode, Coin Metrics, and similar on-chain analytics platforms publish ongoing reorg-frequency data.

Attack-theoretic analysis

  • Majority is not Enough (Eyal and Sirer, 2014) — the selfish-mining paper; foundational for non-honest reorg attacks.

Graph View

Backlinks