> This could be a failure at any point in the bitcoin software.
No, it can only be a failure in the code that determines whether a block is valid. This is a small amount of code, subject to pretty intense scrutiny. And it can only be a bug that makes clients produce conflicting answers, not one that makes clients crash outright. (The 0.7 client, apparently, caught an exception and handled it by treating the block as invalid. We now know that this was a mistake; it should be made to crash instead.)
During the fork, 0.7 clients detected that they weren't on the longest chain and received an automatic message saying that their client might be out of date. People are now talking about building fork detection into merchants' systems, to fall back to safe mode if a fork is detected.
The code that actually determines whether a block is valid is not a small amout of code at all though - that's the entire problem! Whether a block is valid or not depends on subtle behavioural details of huge third-party libraries. The current issue resulted from a quirk of BDB and the developers still haven't managed to fully figure out when exactly it does cause a block to be treated as invalid. We also already knew that block validation inherits some of OpenSSL's quirks which aren't compatible with other, more spec-compliant crypto libraries. It's entirely likely that other code outside of the Bitcoin client also affects which blocks are valid.
I can't find what you mean by block validation inheriting OpenSSL's quirks. Could you explain what you mean? A quick google search suggests that Bitcoin uses OpenSSL only by passing it messages and fixed-size ECDSA keys for validation.
The BDB problem is not mysterious like you suggest, and the whole thing could've been converted from a fork to a DoS by changing a 'return false' to an 'assert'.
I forget the exact problem with OpenSSL, but it accepts particular invalid representations of signatures that the applicable standards say it shouldn't accept, because it doesn't treat the sign bit as a sign bit. This isn't generally a problem because those numbers should never actually be negative, but it's an issue for Bitcoin because everyone needs to agree on which signatures are valid.
That is a beautiful thing. So if I construct a block such that 100% of the clients fail on it, I can then have my own patched client control the entire BTC betwork, right?
No. You would have 100% control of the subtree following that failing block, but it would be very quickly outpaced by another subtree that the rest of the network would be working on. You need to construct a block that close to 50% of clients fail on, so that the network's work is split between two subtrees and they grow at about the same rate.
Well, if they crashed on a certain block then the operators of the client would notice and presumably update to a newer version of the client. The problem in this case was more subtle: the old clients did not crash on the block, they simply rejected it as invalid and continued working on an alternate subtree.
If you did somehow create a block that all clients except yours crashed on, you still wouldn't gain control of the network because the difficulty of creating a new block is calibrated according to the total power of the network, and only re-calibrates every few blocks. So for a while, you would still be effectively competing against the former power of the network, giving the client developers time to fix the crash.
No, it can only be a failure in the code that determines whether a block is valid. This is a small amount of code, subject to pretty intense scrutiny. And it can only be a bug that makes clients produce conflicting answers, not one that makes clients crash outright. (The 0.7 client, apparently, caught an exception and handled it by treating the block as invalid. We now know that this was a mistake; it should be made to crash instead.)
During the fork, 0.7 clients detected that they weren't on the longest chain and received an automatic message saying that their client might be out of date. People are now talking about building fork detection into merchants' systems, to fall back to safe mode if a fork is detected.