Chain Reorganization (Reorg)

What Is a Chain Reorganization?

A chain reorganization (commonly called a "reorg") is a process where a Bitcoin node replaces its current view of the blockchain with a competing chain that has more accumulated proof-of-work. When this happens, one or more blocks at the tip of the node's chain are discarded (becoming "stale blocks"), and the blocks from the heavier chain are adopted in their place.

Reorgs are a fundamental part of how Bitcoin reaches consensus across a decentralized network. Because miners worldwide are racing to find blocks simultaneously, two valid blocks can be found at nearly the same time. Different nodes may initially see different blocks depending on network propagation delays. The reorg mechanism resolves these temporary forks by ensuring all nodes eventually converge on the single chain with the most work.

It is important to note that reorgs are a node-local phenomenon: each node independently reorganizes its own view of the chain when it discovers a heavier alternative. The entire network does not reorganize simultaneously.

How It Works

Bitcoin uses the "heaviest chain" rule (often simplified as the "longest chain" rule). Nodes always adopt the valid chain with the most cumulative proof-of-work, not merely the most blocks. When a node receives a new block that creates a heavier competing chain, the reorganization process follows these steps:

1. The node identifies the fork point: the last block shared by both the current chain and the competing chain
2. Blocks from the current chain tip back to the fork point are disconnected. Spent UTXOs are restored, and newly created UTXOs from those blocks are removed
3. Transactions from the disconnected blocks are returned to the mempool in dependency order so parent transactions are processed before children
4. Blocks from the competing chain are connected from the fork point forward, with full validation applied to each block
5. The mempool is filtered to remove any transactions that conflict with the newly adopted chain

Bitcoin Core Implementation

In Bitcoin Core, the reorg process is triggered by the ActivateBestChain() function whenever a new block is received. The process is split into steps via ActivateBestChainStep() to avoid holding the main chain state lock for extended periods during large reorgs. Two key functions handle the chain switching:

// Simplified reorg flow in Bitcoin Core:
// 1. DisconnectTip() - called in a loop to roll back blocks
//    - Restores spent UTXOs to the UTXO set
//    - Removes UTXOs created in the disconnected block
//    - Moves chain tip pointer backward

// 2. ConnectTip() - called to add each new-chain block
//    - Validates the block against consensus rules
//    - Updates the UTXO set
//    - Removes conflicting transactions from mempool

// 3. MaybeUpdateMempoolForReorg()
//    - Feeds disconnected block transactions back into mempool
//    - Filters out transactions invalid under the new chain tip

Reorg Depth and Frequency

Not all reorgs are equal. The depth of a reorg (measured in blocks) determines its impact:

One-block reorgs occur because two miners occasionally find valid blocks at nearly the same height. The stale block rate has generally decreased over time as mining pools have adopted low-latency block relay networks. Between blocks 800,000 and 900,000, approximately 73 stale blocks were observed: a rate of 0.73 per 1,000 blocks.

The 6-Confirmation Standard

The widely cited recommendation to wait for 6 confirmations before treating a Bitcoin transaction as final originates from Section 11 of the Bitcoin whitepaper. Satoshi modeled a double-spend attempt as a Gambler's Ruin problem, where an attacker with hashrate fraction q tries to catch up from being z blocks behind the honest chain.

The probability of attacker success drops exponentially with each additional confirmation:

At 6 confirmations, an attacker controlling 10% of the network hashrate has a negligible chance of success. This threshold has become the de facto standard for high-value transactions, though many exchanges now accept deposits with fewer confirmations for practical reasons: some require as few as 2-3 confirmations for moderate amounts.

Relationship to 51% Attacks

A 51% attack is the adversarial exploitation of the reorg mechanism. An attacker controlling more than half the network's hashrate can:

1. Mine a secret, parallel chain while the honest network mines the public chain
2. Make a payment on the public chain (for example, depositing Bitcoin to an exchange)
3. Continue mining privately until the secret chain accumulates more proof-of-work
4. Broadcast the secret chain, forcing all honest nodes to reorganize
5. The original payment transaction is reversed: the attacker has double-spent

With majority hashrate, an attacker's success probability is 100% regardless of how many confirmations the victim waits for. This is why Bitcoin's security fundamentally depends on no single entity controlling majority hashrate. The cost of mounting a 51% attack on Bitcoin is extraordinarily high due to its massive total hashrate, making such attacks economically impractical under normal conditions.

Lower-hashrate blockchains are far more vulnerable. Ethereum Classic suffered three separate 51% attacks in August 2020 alone, with reorgs reaching thousands of blocks deep. Bitcoin Gold lost an estimated $18 million to 51% attack double-spends in May 2018. These incidents underscore why raw hashrate is the primary security guarantee against deep reorganizations.

Real-World Reorg Incidents

The Value Overflow Bug (2010)

On August 15, 2010, block 74,638 contained a transaction that created over 184 billion BTC due to an integer overflow vulnerability (CVE-2010-5139). A patched version of Bitcoin was released within hours. The corrected chain overtook the buggy chain at block 74,691, requiring a 53-block reorganization: one of the deepest reorgs in Bitcoin's history.

The BIP-50 Consensus Split (2013)

On March 11-12, 2013, a consensus split occurred between Bitcoin Core versions 0.7 and 0.8 due to differing database backends (BerkeleyDB vs. LevelDB). A block triggered a lock limit in BerkeleyDB that LevelDB did not have, causing the two versions to disagree on which blocks were valid. Mining pools voluntarily downgraded to version 0.7 to resolve the fork after approximately 5 hours. This incident was documented as BIP-50.

March 2026 Two-Block Reorg

In March 2026, a two-block reorganization occurred at approximately block height 941,880, involving competing blocks from Foundry USA and AntPool/ViaBTC. It resolved naturally within minutes with no double-spends or lost funds. Developers described it as routine behavior under Bitcoin's proof-of-work system, highlighting that shallow reorgs remain a normal part of network operation.

Why It Matters

Chain reorganizations directly affect how payment systems and exchanges handle Bitcoin deposits. Any service accepting Bitcoin must decide how many confirmations to require before crediting a deposit: too few confirmations risk losses from reorgs, while too many create unnecessary delays for users.

For merchants and payment processors, understanding reorg risk explains why zero-confirmation transactions are inherently risky. The adoption of Replace-By-Fee (full RBF became the network standard in Bitcoin Core 28.0) has made zero-conf acceptance even less reliable, since any unconfirmed transaction can now be replaced by a conflicting one with a higher fee.

Layer 2 solutions like the Lightning Network and Spark address this challenge by enabling instant transactions that do not depend on block confirmations. By moving transactions off the base layer, these protocols provide instant settlement while the underlying Bitcoin chain provides long-term finality guarantees.

Risks and Considerations

Transaction Reversal

The primary risk of a reorg is transaction reversal. When blocks are disconnected, transactions in those blocks return to the mempool. If a conflicting transaction exists in the new chain, the original transaction becomes permanently invalid. This is the mechanism behind double-spend attacks: the attacker's conflicting transaction in the reorganized chain replaces the original payment.

Exchange Deposit Theft

Exchanges are particularly vulnerable to reorg-based attacks. An attacker deposits Bitcoin to an exchange, trades for another asset, withdraws it, then executes a reorg that reverses the original deposit. The exchange loses the withdrawn asset while the deposit transaction disappears. This is why exchanges typically require multiple confirmations before allowing trading or withdrawals.

Checkpoint Removal

Bitcoin Core v30 (released in 2025) removed all legacy checkpoints: hardcoded block hashes that previously prevented reorgs past certain historical points. The headers pre-sync functionality introduced in v24 now provides protection against low-proof-of-work header attacks instead. The assumevalid parameter remains as a performance optimization but gracefully falls back to full validation if a reorg occurs past that point.

Mining Centralization

The risk of deep reorgs increases as mining becomes more concentrated. If a small number of pools control a large share of hashrate, the barrier to executing a 51% attack decreases. Bitcoin's security against deep reorgs is ultimately a function of how distributed its mining power is across independent operators.

Frequently Asked Questions

Are transactions in reorged blocks lost forever?

Not necessarily. Transactions from disconnected blocks are returned to the mempool and can be included in future blocks. However, if the new chain contains a conflicting transaction that spends the same inputs, the original transaction becomes invalid and will not be re-mined.

How can I protect against reorg risk?

Wait for sufficient confirmations before treating a transaction as final. For high-value transactions, the traditional 6-confirmation standard provides strong protection against attackers with less than 10% of network hashrate. For lower-value transactions, 2-3 confirmations may be sufficient. Alternatively, use a Layer 2 solution like Lightning or Spark for instant settlement without reorg risk.

Can a reorg happen at any depth?

In theory, Bitcoin's protocol allows arbitrarily deep reorgs: there is no hardcoded depth limit. In practice, the probability of a natural reorg decreases exponentially with depth, and a deep reorg would require an attacker to possess an enormous amount of hashrate. On Bitcoin's mainnet, no reorg deeper than 53 blocks has ever occurred, and that was due to a critical software bug in 2010 rather than an attack.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.