> .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.
I use BDB and I doubt they are actually running in to any kind of hard limit of the database. They are probably just running out of locks. Number of locks is a configuration option.
Each modified database page needs an allocated lock that is held during the database transaction until it is committed.
> It seems this database has a limit on the size of the modification it can make atomically to the database.
If this were an unlucky edge case, I could understand. But it seems like they allowed larger block sizes without testing them on pre v0.8 miners - which might be 25% of miners and the upgrade to v0.8 was less than 1 month ago. It's nice to think that 100% of people will upgrade within a few weeks, but that's just not how some people work.
> If this were an unlucky edge case, I could understand. But it seems like they allowed larger block sizes without testing them on pre v0.8 miners
That is not entirely correct. Multiple large blocks were tested on v0.7 (and older clients). Blocks up to the 1MB hard limits were validated and relayed by older clients.
The "problem block" in particular wasn't rejected due to simply being too large. It was somewhat rare in that it exceeded the number of low level locks available to v0.7 clients. It had a large number of transactions with a large number of inputs and outputs and those happened to have a large number of compressed keys. Without using a high number of compressed keys it wouldn't be possible to have a block with this number of inputs and outputs in the 1MB limit.
Granted in hindsight more testing should have been done but it wasn't like nobody said "hey we should test large blocks, nah I am sure it will be fine".
> .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.
[1] https://bitcointalk.org/index.php?topic=152030.msg1613200#ms...