March 2013 Chain Split

On 11 March 2013, a node running Bitcoin 0.8 mined block 225 430. The new version accepted it, while some nodes running 0.7.2 and earlier rejected it; a branch containing that block and a branch without it therefore grew from the same parent. The difference was not in the hash or proof of work itself, but in whether local software regarded the block as valid at all. [2]

The trigger was not simply the block size in bytes. The block contained an unprecedented number of transaction inputs, and old nodes exhausted the default Berkeley DB lock count while writing them. The locks required also depended on the layout of database pages on a particular node, so a smaller but otherwise valid block could fail where earlier maximum-size test blocks had succeeded. [1]

Bitcoin 0.8 moved the block and transaction indexes from Berkeley DB to LevelDB, which did not have the same lock limit. About 60 % of the hashrate initially built on the 0.8 branch, but older nodes did not count its work because they rejected its first block. The heaviest-chain rule chooses only among histories a node has first validated; it therefore could not resolve this disagreement by itself. [1]

Pieter Wuille published the emergency warning and advised merchants to suspend payment processing. After discussion among developers and operators, the BTCGuild pool led by Michael Marsee, known as Eleuthria, and Marek Palatinus’s Slush Pool switched back to Bitcoin 0.7. The aim was not to declare the technically newer branch permanently wrong, but to concentrate work quickly on a history both widely deployed versions could validate. [3]

When the compatible branch gained the lead in cumulative work, 0.8 nodes reorganised to it and blocks mined only on the original 0.8 branch became stale. BIP 50 records at least one large double spend during the split; the post-mortem says it was an experiment rather than an intended theft. The event still showed why exchanges and merchants pause deposits and wait for further confirmations when the chain tip is uncertain. [1]

Bitcoin Core 0.8.1 was released on 18 March 2013. It introduced a temporary block-acceptance rule enforced from 21 March to 15 May that prevented acceptance of blocks older peers could not process, and added a built-in checkpoint at block 225 430. The post-mortem also specifies an estimated limit of 10 000 locks, a mining limit of 500 000 bytes and backports with a 537 000 Berkeley DB lock limit. [4]

Temporary compatibility was not the final state. Operators of older nodes had until 15 May to move to 0.8.1, an updated backport or an explicitly higher lock limit; miners were told not to raise the limit before the coordinated date, lest they again create a block the rest of the network would reject. On 16 August 2013 the network accepted block 252 451 and permanently left unpatched nodes behind. [5]

The incident showed that consensus is more than a description of the block format. It includes the exact behaviour of validation code, libraries, database transactions, error paths and boundary tests. Follow-up work therefore included stress-generating transactions on testnet, better alerts for services, monitoring long side branches and more careful coordination of changes; the rapid recovery also exposed the network’s dependence at the time on a few reachable developers and large pools. [1]