The Night Bitcoin Had Two Valid Histories

Block 225,430 was not created with the intention of splitting the network. However, it contained more transaction inputs than previous blocks, and thus loaded the database in a way that revealed the difference between versions. Bitcoin 0.8 used LevelDB and processed the block. Version 0.7 with Berkeley DB encountered a lock count and ended with an error.

The result was deceptively inconspicuous. Both groups of nodes followed the rules as their program could execute them. The newer branch was not fraudulent according to the intended consensus rules, and the older nodes were not attacked. The network split due to an undocumented practical limit of one database technology.

Miners with version 0.8 built on the new block. Miners with the older version continued from its predecessor. As both branches gained additional blocks, a payment confirmed on one might not exist on the other. A user could not safely rely on the usual number of confirmations until it was clear which history the economic majority would accept.

The newer branch initially carried approximately sixty percent of the hash rate. Under normal circumstances, the chain with the greater cumulative work would gain an advantage. However, the older nodes could not accept the new block without regard to its work. Reorganization alone would not bridge a block that the local validation software considered invalid.

The incident thus revealed the limit of the simple rule 'the longest chain wins.' More precisely, the chain with the most work among those that the node first recognizes as valid wins. When nodes disagree on validity, the hash rate alone is not enough for immediate unification.

Developers noticed the problem when the heights and hashes of the nodes they monitored began to differ. Communication focused on the IRC channel, where they could compare logs, branch performance, and the reactions of large pools. Gavin Andresen later documented the timeline and decisions made during the night in BIP 50.

The choice was not between a purely correct and an obviously wrong branch. Supporting version 0.8 would have maintained the chain with the greater work, but would have cut off a number of older nodes. Returning to the 0.7 branch meant convincing new miners to abandon blocks they had already legitimately mined and for which they expected a reward.

A practical reason for returning was compatibility. Version 0.8 could accept smaller blocks created for the older branch, while 0.7 nodes could not accept the problematic block of the new branch. If the hash rate moved to a branch acceptable to both groups, the network could reunite without an immediate forced upgrade of all older nodes.

The decision was not a command that Andresen could send through the protocol. Developers contacted pool operators and explained the situation. Exchanges were advised to suspend deposits. Bitcoin.org published a warning and asked large pools to return to the older software version so the network could reunite on a compatible branch.

This coordination was rapid precisely because the circle of key participants was still relatively small and people knew each other from public channels. The speed helped save the network from a longer split, but also showed the social bonds on which early operation depended. Bitcoin had no boss; it had people whose phone call or message could move a large portion of the hash rate.

The IRC conversation carried no legal authority and no secret administrative key. Its significance lay in bringing together, in one place, people with different capacities for intervention. Developers could explain the cause, pools could redirect hashrate, exchanges could halt deposits, and node operators could change versions. Each step carried its own risk, and no one could guarantee that the others would comply. The decision to support the branch compatible with version 0.7 was therefore not a technical command from the center of the network, but a coordinated bet that this path would restore shared history most quickly with the least impact on users. Its success cannot be separated from the small size of the community at the time, nor presented as a universal crisis procedure.

A decisive step came from BTCGuild, run by Michael Marsee, known as Eleuthria, and Slush Pool, run by Marek Palatinus. Both operators rolled back from version 0.8 to 0.7 and directed their hashpower to the older branch. Their move helped shift the balance of accumulated work between the two histories.

It was not a free gesture in the ledger. Blocks mined on the abandoned branch ceased to be part of the main chain during reorganization, so their rewards should not have remained spendable. BIP 50 explicitly notes that pools sacrificed significant money to return the network to a common branch.

Once the older branch took the lead, updated 0.8 nodes could accept it and reorganize their history. Old nodes were already on it. The split was closed not because one version remotely overwrote the other, but because enough miners created more work above the point that both could verify.

During the incident, there was at least one major double spend, described as an experiment rather than a planned attack. The event nonetheless showed a real risk: a transaction could be confirmed on a branch that would later be abandoned. The recommendation to stop deposits was not panic; it protected services from accounting balances based on temporary history.

Pools at this point did not own the network. They could influence the block order with the hash rate that miners entrusted to them, but they could not force every full node to accept arbitrary rules. Their success depended on a narrow goal: to create a branch that both old and new nodes considered valid and to give it the most work.

Gavin Andresen later documented the incident in BIP 50. It does not claim that the network worked flawlessly. It explains the cause, the course of events, the lost blocks, the double spend and the measures intended to catch similar disagreements earlier. Publishing that analysis meant the experience of the crisis was not confined to the memories of those involved. Other developers could learn from it too.

One lesson was that consensus includes not just rules written in comments or documentation. The practical behavior of a widely deployed program can become a network limitation, even if no one intended it to have monetary significance. Database migration must therefore not be considered a purely internal change if it can alter block acceptance.

Another lesson was the need to coordinate upgrades more carefully and test blocks close to operational limits. Version 0.8 brought performance improvements, but the difference only manifested in the actual chain. After the incident, developers introduced temporary limits and prepared a path that would later allow old dependencies to be safely abandoned.

The story is sometimes used as evidence that Bitcoin is controlled by a few developers, and sometimes as evidence that it is automatically indestructible. Neither shortened version fits. People were able to urgently coordinate a fix, but they needed the cooperation of pools, exchanges, and node operators. The software decided on each computer separately, and the common result emerged only from their combination.

The night of March 11–12 ended with a single main chain, but not because the disagreement resolved itself. Some participants raised the alarm, others suspended services, and miners gave up completed work to restore a compatible history. Bitcoin survived its two competing pasts through a combination of rules, economic costs and people willing to accept that the newer software had to give way this time.

BIP 50 matters because it does not close the incident with a declaration of victory for decentralization. It records the specific cause, the timeline, the lost work and the steps meant to prevent a similar surprise. An uncomfortable failure becomes a basis for further testing. It also leaves a question open: how many unwritten assumptions lie between two versions of a program that we consider compatible? Consensus is more than a list of rules on paper. Independent implementations and nodes must reach the same result even in edge cases. The importance of that agreement becomes clearest when it breaks down.