incompatibility between versions should be called (at least) an issue imho...
My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7
Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested.
Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for. What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site.
The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen?
A block rejected by all nodes is by definition invalid. Someone wil produce a new valid one, and the building will continue as normal.
Is there any evidence that all nodes would reject it? It looks like, according to Pieter's preliminary statement, that certain configurations will (correctly) accept the blocks.
Quote
Immediate solution is upgrading to 0.8, or manually setting the number of
lock objects higher in your database. I'll follow up with more concrete
instructions.
lock objects higher in your database. I'll follow up with more concrete
instructions.
