On March 11, 2013, a block at height 225,430 exposed a disagreement between Bitcoin software versions. Nodes running version 0.8 accepted it; some older nodes did not. The network temporarily followed competing histories. The incident notice.
The problem was in a database limit
The post-mortem identifies a Berkeley DB locking limit in older software. A block with an unusually large number of transaction inputs required more locks than some installations could handle. Version 0.8 used LevelDB and did not encounter the same restriction.
This was not simply a deliberate vote to increase Bitcoin’s block-size limit. A database constraint had become an unintended part of how older software decided which blocks it could process. The technical root cause.
How the network converged
The response involved people coordinating a software change. BTC Guild and Slush switched their mining nodes back to version 0.7. As more work accumulated on the branch compatible with older nodes, version 0.8 nodes could reorganize onto it.
The post-mortem records a successful double spend during the incident, describing it as an experiment rather than an attempt to steal. It also documents the response and subsequent software fixes. The recovery should not be summarized as either “nothing happened” or “Bitcoin’s cryptography was broken.” The response and its consequences.
What this episode teaches
Independent validation means that a node applies its own rules. If implementations disagree about those rules in practice, proof of work alone does not make an invalid block acceptable to that node.
The historical alert includes operational instructions for the affected software. They describe a 2013 response, not instructions to downgrade a current installation. The dated alert.
For the underlying concepts, read confirmations and reorganizations and how Bitcoin upgrades work.