On March 11, 2013, a miner running Bitcoin 0.8.0 produced the block at height 225,430. Gavin Andresen described it in the developers’ IRC channel that night as a “998,081 byte, 1700+ transaction block.” Nodes running 0.8 accepted it and kept building on it. Nodes running 0.7 and earlier rejected it and kept mining a chain of their own. No rule anyone had written made the block invalid, and the two chains would not merge by themselves.
A rule nobody had written
BIP 50, the post-mortem Andresen wrote nine days later, traced the split to a database setting. Versions before 0.8 kept their block index in Berkeley DB and configured too few locks for a block with that many transaction inputs; Pieter Wuille found in the channel that the block touched over 5,000 transaction index entries. Version 0.8 had moved that data to LevelDB, the change the storage design page describes, and LevelDB had no such limit. In BIP 50’s words, the lock limit “implicitly had become a network consensus rule determining block validity.”
Nobody had hit it because nobody had built such a block. Maximum-size blocks had passed on the testnet, and before 0.7 unmodified mining nodes limited their own blocks to 500,000 bytes. Version 0.7 made that target configurable, and in the week before the fork miners had been encouraged to raise it.
The longer chain or the older one
The 0.8 chain had around 60% of the hash power, so it was the longer one, and in Bitcoin the longer chain normally wins. The first to say so:
Gavin Andresen (#bitcoin-dev IRC, March 11, 2013)first rule of bitcoin: majority hashpower wins
A minute later came the answer that this case was different, because every node still running the old software would refuse the longer chain however much work it carried:
Pieter Wuille (#bitcoin-dev IRC, March 11, 2013)i disagree with majority hashpower wins; this is a hardfork - just a majority isn’t enough
He added that “even with 90% of mining power on 0.8, all merchants on an old client will be vulnerable,” and that “the only sane choice is making a chain that we know now everyone accepts.” Luke Dashjr was already contacting pool operators and asking the developers for a recommendation that miners downgrade. Gregory Maxwell put the reasoning in one line: “This is a hardfork. We need to get consistency with a chain accepted by the least common denominator.”
The operator of BTC Guild, the pool that by his count supplied about half of the 0.8 chain’s hash power, told the channel that his pool alone could hand the majority back to 0.7 and that he only needed confirmation. Jeff Garzik and Wuille gave it, and Andresen, who had just said that going backwards was the wrong thing to do, joined them: “if you can cleanly get us back on the 0.7 chain, ACK from here, too.”
Turning back
BTC Guild suspended payouts, copied a pre-0.8 block chain onto its servers and switched them to 0.7. Marek Palatinus, whose pool also ran 0.8 nodes, came into the channel, was told by Garzik “we are switching to 0.7 chain,” and asked what he needed to do. BIP 50 credits both men with downgrading quickly “despite the fact that this caused them to sacrifice significant amounts of money”: every block their pools had found on the 0.8 chain would be orphaned.
Andresen sent a network alert. Garzik’s advice in the channel was the version most users needed: “merchants should pause transaction processing. miners should mine 0.7. everyone else just wait.” Exchanges suspended deposits and BitPay suspended payments. Once the 0.7 chain had more work behind it, 0.8 nodes reorganized onto it on their own, and the 0.8 chain’s blocks were left as orphans; BTC Guild’s operator put the whole episode at about six and a half hours from the first forked block. BIP 50 records one large double spend in that window, made by someone testing whether it was possible.
What changed afterwards
Version 0.8.1, signed on March 17, introduced “a temporary block validation rule to avoid an incompatibility with version 0.7.2 and earlier”: for two months it rejected blocks likely to need more than 10,000 locks and capped the blocks it built at 500,000 bytes, and a patch for older versions raised their lock limit. The same post-mortem reviewed who held the alert keys and added an -alertnotify option so services could act on alerts. On August 16, 2013, block 252,451 was accepted by the main network, and nodes still running the unpatched old software were forked off.
Two and a half years earlier, in the value overflow incident, the fix came from Satoshi, and the chain that won was the one his patched client built. In March 2013 the fix came from a few developers in an IRC channel and the operators of two pools, and the chain that won was the shorter one. That night showed that Bitcoin’s rules include whatever its oldest running software would refuse, written down or not, and the people who kept the network whole were the two who paid to honor it.
