v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened. It was a landmine.
Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...
I agree on that 100%. It is inevitable that to survive Bitcoin will need to be move beyond a monoculture. Right now all the clients share the same "DNA". If there is a fatal genetic flaw in it then the network will not survive. This time the "landmine" was accidental, next time it may be planted.
That is not correct. v0.7 nodes accepted a 1MB block on testnet. The issue was more complex then just the size of the block. By the protocol the block which was rejected by some nodes SHOULD have been accepted. The 250kb soft limit was simply a default for block construction. Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit. It also appears not all v0.7 nodes were affected. Some accepted the problem block and some didn't. The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.
v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened. It was a landmine.
Notwithstanding that blocks of 1mb should have been accepted if valid, the limit prevented too many of them from being made.
If the limit had been removed at a reasonable time, those blocks would have occasionally been made, and the overall problem would have been much contained.
I would like to also point out that the alexkravets idea re specification is sound. The only way forward for the dev team, provided they wish to preserve a shred of dignity, is a. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete and b. immediately start work on removing all magic numbers and assorted code smelliness from their UNreference implementation of crap, and not release any further version before they've released a clean one.
In that order.
Whoa... All of this... Agreement...