|
|
|
|
|
|
by greatreorx
4854 days ago
|
|
|
> 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. |
|
|
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".