New Rabbit Hole on LearnBitcoin:
The 2013 Chain Forkhttps://www.learnbitcoin.com/rabbit-hole/2013-chain-forkSome of you were here for it, and the threads from that night are still on this forum, so this is the crowd most likely to catch what I got wrong. It follows the 11-12 March 2013 fork from the #bitcoin-dev log with UTC timestamps, checked against block headers and the 0.7.2 and 0.8.1 source.
The parts I'd expect an argument about:
- Length. Almost every summary says 24 blocks and six hours. Two separate 0.8 nodes logged "REORGANIZE: Disconnect 25 blocks" at 06:22, the abandoned chain ran 225,430 to 225,454 inclusive, and it was 7 hours 41 minutes from Slush's block (22:39:09) to the block that overtook it (225,455 at 06:20:04).
- Cause. Not block size. 998 kB and about 1,750 transactions touching a little over 5,000 tx-index entries, against set_lk_max_locks(10000) in db.cpp, with locks taken per page so the ceiling varied from node to node.
- The decision. Gavin opened with "first rule of bitcoin: majority hashpower wins" and "The bug is clearly in 0.7." sipa and Luke-Jr argued a majority is not enough for a hard fork. Eleuthria started rolling BTC Guild back fourteen minutes before the ACKs came.
- Slush. BIP-50 says both pools downgraded. The log has slush unable to get 0.7 synced and rejoining on 0.8 with sipa's emergency blacklist patch.
- BIP-50 itself. Parts of it were rewritten in February 2016, so it is not all 2013 wording.
- The 0.8.1 rule. The consensus rule was at most 4,500 distinct txids per block from 21 March to 15 May. The 500 kB figure was a cap on what 0.8.1 itself would mine.
- One log archive runs an hour behind UTC in its later captures, and a well-known 2015 analysis inherited that. Times in the chapter are from the other archive and match the block headers and mailing list stamps.
If you were in the channel, or you have and will share a debug.log from that night, I'd like to hear where this is off. It gets fixed the same day and credited.
