Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Large blockchain re-orgs can fail #925
TD and jrmithdobbs ran into this with version 0.6rc1.
Block 170060 has an invalid-under-new-rules BIP16 transaction. That block is rejected by 0.6rc1 unless you run with the -paytoscripthashtime= argument to move the BIP16 acceptance date.
There is a fairly long alternative chain fork at that point, because a couple of mining pool operators who were supporting BIP16 didn't restart their bitcoind's with the new BIP16 deadline.
The 0.6rc1 code will save both chains to disk, but rejects the longer as invalid. So far, so good.
The bug: If you upgrade or set -paytoscripthashtime to the correct date then the next found block will trigger a really big reorg operation. And with the settings we're using for Berkeley DB, that re-org fails because the database code runs out of locks.
Workarounds: recompile bitcoin so bdb allocated more locks. Or re-download the blockchain.
Short-term fix: Add a command-line flag so anybody who runs into this issue can just re-run with more locks.
Long-term fix: Rework the block re-org code so it doesn't create one massive database transaction.
I attempted to reproduce this (after jrmithdobbs mentioned it) by copying the chain to some isolated nodes, modifiying it so difficulty 1 was accepted and try to reorg the real chain onto short splits I created. I was unsuccessful, though I'm not sure why.
One unexplained thing is that some people on the fork upgraded to rc2 even as late as today and reorged with no trouble. Differences in BDB versions?