0xFEED

> Someone submitted a Bitcoin transaction which did, in fact, exhaust the number of locks available to the Berkeley DB.

You really need to get up to speed with the event before commenting on it, there's a very good writeup in the form of BIP50.

https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...

The issue has nothing to do with a particular transaction or block, it was going to fail anyway and just happened to be triggered by a large block. The oversight meant that all 0.7 clients were inconsistent with one another depending on the history of the node and how long it had been operating.

> No sane person says "An important feature of the Bitcoin Protocol is that conforming clients MUST REJECT any Bitcoin transaction which would exhaust the default number of locks available to the Berkeley DB."

Nobody did say that, the failure was implicit not explicit.

> Several hours of transactional history got wiped out.

No it didn't, it was replaced with a slightly different history, or history remained the same, depending on which side and which client you happened to be running at the time.

> Weren't all transactions made on the v0.8 blockchain eventually rendered null and void?

No they were not null and void, there's no lasting records of what happened but they would have either existed on both chains (likely), or been returned to the memory pools of miners when they were reorganized out (likely). There was only one recorded instance of double spend during the event which was intentional, it and any descendant transactions would have been invalidated on the chain that did not win.

> Please explain why all of the above does not count as the network being "shut down" in any sense of the word.

Well "shut down" implies that nothing was operational, the network was perfectly functional it just happened to have fragmented due to an oversight in the way the underlying database in 0.7 was configured (you could non deterministically run out of locks, 0.8 didn't have the same failure but wasn't wide spread at the time). It might not have been safe to rely on untrusted transactions from outside sources during the event but anybody not doing this had zero risk whatsoever. The main losers in this event were the miners who threw away their block reward to speed up the resolution of the fork, which were re compensated at a later time anyway.

> and also that any transactions that you did on the v0.8 block might need to be re-broadcast?

The client handles this automatically.

They share no similarity other than being related to currency.

There's a number of things in that which aren't totally correct.

> No, seriously, the decentralized nobody-needs-to-trust-anybody payments network was shut down by an IRC channel's consensus* for 8 hrs.*

It wasn't "shut down" in any sense of the word, the network kept working (in duplicate, no less). It was the decision of two pool owners with extraordinary hashrates to sacrifice their chain (which was actually the "correct" one as far as intentions go), rather than the core developers. Nobody has some magic key to shut down the network (though originally, Satoshi's alert key did enable a "safe mode", this is long gone)

> Bitcoin is not a protocol in any meaningful sense of word. It is a single C++ codebase that you have to be bug-for-bug compatible with.

That's the reality of distributed consensus. Matching it bug for bug is completely foolhardy (and many have failed at the task), you should be just linking in the consensus library which is currently being broken out of the bitcoin core source.

> Most advantages of Bitcoin which matter are captured by, and improved upon by, a LAMP app which simply holds account balances.

Except for the key one, that a LAMP setup running on a shared host isn't a distributed consensus. You could replace your car with a hamster wheel and it would still go round and round, but it's missing the core function of getting you to work.

> Bitcoin presently costs on the order of $6.5k per megabyte of data added to the block chain.

Which is why signatures are made with ECDSA, a very compact signature system compared with lamport or RSA. You don't want to be storing data in the block chain, and it's never been posited to be good for this (quite the opposite).

> Time between Bitcoin blocks is not guaranteed (follows a Poisson distribution). Sometimes all pending transactions just stop for a while

This isn't at all surprising, if they were regular then Bitcoin wouldn't be a functioning distributed consensus. You can get near instant, low trust "confirmations" by using a multisignature oracle which promises not to sign double spends. There's at least one company doing this at the moment, though it hasn't seen huge adoption.