The March 2013 Bitcoin Fork Suggested Fixes

The bitcoin blockchain experienced a fork due to a subtle bug in the pre-0.8 bitcoin app. The 0.8 version was being used by a majority of the miners. After it had been suggested to increase the maximum blocksize, a large block (#225430) was generated by miners on 0.8. This large block was not processable by pre-0.8 apps. There was a significant percentage of miners on pre-0.8 and that brings us to the first, and core problem - how pre-0.8 handled the error.

Fix 1) Block 225430 was a valid block. It was the error handling of the bitcoin client that caused the problem. The hash was valid for its contents and for its place in the blockchain. The client should have been able to verify that before iteration over the transactions. It was the number of transactions that causes bdb to fail. The client should be changed to compartmentalize an exception that happens after the validity of the block is determined. When this valid block caused an error in processing after validation, the client should treat that as an irrecoverable internal error. The pre-0.8 miners and clients would have shut down and the chain would not have forked.

Fix 2) It is my understanding that all the forks exist in each client's blockchain. If so, put up a large warning that a fork exists and things may not be what they seem. The greatest let-down of this blockchain fork event is that the great promise to merchants was invalidated. Since I've been using bitcoin, the mantra has been that after 3, and at most 6, confirmations, it was statistically impossible to get a false-positive on a transaction. Thats true for a single chain. The large, now infamous, payment made on the 0.8fork that was simply un-done out of thin air when the pre-0.8 chain achieved the most length, showed that iron-clad agreement to be false. If the app could warn the user of the existence of a fork, then they'd have a chance to investigate further.