It seems like almost every technical thread about bitcoin{d,-qt} needs to take a detour into the DB-land.
Not too surprising, it's one hell of a weakness right now. BDB is just not the right fit for how we use it.
I just wanted to stress that the "append-only" is the key concept to understand what is required architecturally to implement Bitcoin efficiently. Incidentally it is also a key ingredient to make any Bitcoin implementation GAAP-compliant.
I was talking about the storage system, not wallet semantics (which is what you want changed to conform to those rules). Even if we move to an append-only wallet file, that doesn't mean anything will observably change.
LevelDB unfortunately will not be "exactly what we need" unless a significant reachitecturing is undertaken.
Mike Hearn had explained this succintly. I'll find the link and post it here.
Mike Hearn also implemented a first Bitcoin-on-LevelDB port himself (see
pull request 1619), which was abandoned after I modified it to work on top of my rewrite of the validation engine (see
pull request 1677).
The problem you probably were referring to is the fact that Bitcoin relied on reading uncommitted data during block validation, something that isn't supported by LevelDB (it just has atomic writes, no real database transactionality). Mike solved that in his port by writing a tiny caching layer around LevelDB. I solved it by avoiding the need for such operations altogether, with a nice performance improvement along the way.
He wasn't talking about the storage layer. He was referring to your request for changing the wallet semantics. I disagree that it would take that long, by the way, but I disagree it's within our scope right now. There are enough alternative wallets already, those are in a perfect place to experiment with different types of wallets.
By the way, changing the wallet storage (but just that) to use an append-only format is also already implemented (by me), but it had some issues left, and I felt other things were more important to work on.
