Re: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks
And now a more elaborate explanation:
0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept "too large" blocks (we don't yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.
However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.
The solution is to (for now) go back to the old chain, which has block 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430.
0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept "too large" blocks (we don't yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.
However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.
The solution is to (for now) go back to the old chain, which has block 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430.
Just to ask a couple of questions.
Could this have been deliberate in any way in that someone, or group, figured out the weakness of the 0.7 client?
Is this just a random occurrence with some ASIC's coming online and Hash rate going up?
In my ignorant opinion, seems to me that if it was known the 0.7 had a dbase limit then that client should have been voted off the network a while ago.
For the newbie fun I just did a cash deposit on Gox. Was like WOW look at these prices, bought then couldn't transfer to BTCe and finally got wise looking at the chat feed there. Thankfully, I was able to back out on Gox and go back to cash at just a little loss.
From what I can tell this problem was not caused by a malformed transaction, but by a malformed, mined block. If an attacker crafted a bad block, they would have to do so as a miner which would take an awful lot of patience or resources, so I don't think it was intentional.
As to why this wasn't caught in testing, that's a great question but I'll bet it's a tricky kind of bug specific to BDB that is hard to replicate if you aren't looking for it. Once the mess is cleaned up, and once we carve a clear upgrade path to 0.8 and beyond we'll be leaving BDB and it's bugfest behind, though.
