Bitcoin is a chain of decisions, not a single date · 2013

The night two versions of Bitcoin existed

In March 2013, the network unexpectedly split: new software accepted a large block while some older software rejected it. For several hours, two incompatible transaction histories existed.

Block 225,430

On March 11, 2013, a miner produced a block containing an unusually large number of transaction inputs. Bitcoin 0.8 processed it and kept building. Some earlier nodes exhausted an internal Berkeley DB lock limit, rejected the same block and began extending a different branch.

Rules that were not quite identical

Developers had not intended to change consensus. The difference arose from a technical detail in two data-storage implementations. For the network, however, the effect was equivalent to a rule change: the same block was valid to new nodes and invalid to old ones.

Why the stronger branch did not simply win

The new chain had roughly 60% of the network's hash power, so waiting did not guarantee a quick reunification. Many users and services also remained on earlier versions. Continuing the new branch would have left them following a different history.

The decision to step back

Developers contacted the large BTC Guild and Slush mining pools. They voluntarily moved their nodes from version 0.8 back to 0.7, even though their new branch held more accumulated work. The old-compatible chain became stronger, and new nodes reorganized onto it. The network again confirmed one shared sequence of blocks.

This was not a new coin

The two branches existed temporarily and did not become separate projects with different names and communities. Participants aimed to restore compatibility. Version 0.8.1 later constrained the blocks it produced so older software could accept them.

The lesson that night preserved

Decentralization does not mean an absence of communication or human decisions. It means different participants verify rules with their own nodes and choose which software to run. The incident demonstrated the value of backward compatibility, cautious upgrades and public post-mortems. Bitcoin's history is not only a list of release dates; it is a chain of decisions like these.

A shared network history is not preserved by magic. It depends on compatible rules, independent verification and participants choosing to enforce those rules.

Verify the primary sources

  1. Official notice about the March 11–12, 2013 chain fork
  2. BIP 50: the technical post-mortem
  3. Bitcoin-Qt 0.8.1 compatibility release

Historical and educational material. Not financial advice.

Back to the rubric