Chain reorganization

Nodes do not follow the chain they saw first. They follow the one carrying the most proof of work, and when a better branch appears they roll back to the fork point and replay forward. Almost every reorganization on bitcoin's main chain is one block deep and finishes in seconds; the deepest on record, 24 blocks in March 2013, was caused by a software bug rather than an attacker.

How it works

A chain reorganization has three steps, and a node performs all of them on its own without consulting anybody.

First it walks back from its current tip to the last block the two branches share, undoing each block as it goes: outputs that block created are removed from the unspent set, outputs it consumed are restored, and its transactions go back into the mempool. Then it connects the blocks of the competing branch in order, validating each one exactly as if it had just arrived. Finally it recomputes the mempool, dropping anything that has now been confirmed and keeping anything that has not.

The second step is where the safety lives. More work is necessary but not sufficient. If any block on the challenging branch fails a single consensus check, the node stops, marks that branch invalid and keeps the chain it already had. A miner with unlimited hash power still cannot make a node accept a block that pays itself too much or spends an output twice.

The rule is most accumulated work, not longest chain. Work is summed from the difficulty each block was mined at, so a branch with fewer blocks mined at a higher difficulty can outrank a longer one. On bitcoin the two measures coincide almost always, because difficulty only changes every 2,016 blocks.

Depth is what separates routine from alarming. One block deep is normal housekeeping. Bitcoin Core treats anything substantial as newsworthy and raises a large work fork warning to the operator when it sees a competing branch diverge more than six blocks from the active chain.

Why this matters when you buy bitcoin

Confirmation counts are a bet on reorganization depth, and every platform you use has quietly placed one on your behalf.

An exchange that credits a deposit after three blocks has decided that a three block reversal is not worth insuring against. One that waits for six has priced the risk higher. Neither number comes from the protocol; both are policy, which is why the same deposit clears in twenty minutes on one platform and over an hour on another. When you are moving coins between the exchanges we review, that difference is worth checking before you assume something has gone wrong.

Your keys are untouched by any of this. A reorganization can change which transactions are in the chain and in what order, but it cannot produce a signature, so coins sitting in a wallet you control are not part of the exposure. What sits in the blast radius is value in motion: a deposit that has been credited but not buried, a payment you accepted for goods, a peer to peer trade where you released cash against one confirmation.

History gives one instructive warning. On July 4, 2015, several large pools were building on blocks they had not validated, a practice known as SPV mining, and produced a six block chain that turned out to be invalid. Bitcoin.org published an alert advising users to wait for 30 confirmations until the situation resolved. The lesson was not that bitcoin is fragile; it was that the depth you need depends on what is going wrong, and one confirmation is never a lot.

If you also hold smaller proof of work coins, treat their reorganization history as a separate question entirely. Exchanges demand far more confirmations for chains that have actually been reorganized, and that requirement is a useful public signal about how secure a chain really is.

The 24 block reorganization of March 2013

The deepest reorganization bitcoin's main chain has ever undergone was caused by two versions of the software disagreeing about a block both should have accepted.

Bitcoin 0.8, released in February 2013, replaced the Berkeley DB storage engine with LevelDB. On March 11, block 225,430 arrived carrying an unusually large number of inputs. Nodes running 0.8 accepted it. Nodes running 0.7 hit a Berkeley DB lock limit they had never been configured past and rejected it. The network split in two, with each side perfectly certain the other was wrong.

Developers coordinated on IRC within the hour and made an uncomfortable call: ask pools to downgrade to 0.7, deliberately abandoning the branch with more work, because that branch was the one a majority of running nodes could not follow. The split lasted around six hours. When the 0.7 chain overtook, the discarded branch ran to 24 blocks. One payment processor, OKPay, reported being double spent during the window.

The fix shipped days later in 0.8.1, which made new nodes imitate the old limit until a coordinated cutover date. BIP50 documents the whole episode in detail and is the single best thing to read about how bitcoin handles a genuine emergency. It is also the reason the deepest reorganization in bitcoin's history is a story about database configuration rather than about mining power.

Chain reorganization vs hard fork

A chain reorganization happens inside one set of rules and ends with everyone back on the same chain. A hard fork changes the rules so that the two branches can never reconcile, and both keep growing as separate assets, which is what happened to Bitcoin Cash on August 1, 2017. One is a temporary disagreement about which valid chain is the best chain. The other is a permanent disagreement about what valid means.

Chain reorganization vs double spend

A reorganization is a mechanism; a double spend is one thing you could do with it, and rarely the thing that actually happens. The overwhelming majority of reorganizations simply re-mine the same transactions in a different block, so nobody's payment changes. A reversal requires the winning branch to contain a conflicting transaction that the attacker put there on purpose, which means either enormous hash power or extraordinary luck. Cheaper double spend attempts never involve a reorganization at all, because they target payments that were never confirmed in the first place.