rich1.0npub1a3zpmn53lhv8jv7vjg3daletu2e6e9ce88737ga2r7dkr7yc7dss7r6s85https://nostr.ae/npub1a3zpmn53lhv8jv7vjg3daletu2e6e9ce88737ga2r7dkr7yc7dss7r6s85njumphttps://nostr.ae📅 Original date posted:2015-10-30 📝 Original message:Storage of UTXO data looks like an implementation detail and thus one would have thought that the choice of database would not increase the odds of consensus protocol failure. Btcd, a full node implementation written in Go, already provides a database interface which supports different backends: https://github.com/btcsuite/btcd/tree/master/database Given that UTXO storage is considered critical, it seems reasonable to let a node operator decide for themselves if they want data stored in LevelDB (which is not fully ACID compliant) or a database like Sqlite, Oracle, DB2 etc. If the storage requirements for UTXO data are fairly simple, consisting mainly of puts and gets, there is a decent argument that using a dedicated key-value store provides superior performance over a traditional SQL database. However, from a practical perspective, given that nodes operate on a range of different hardware and even a little Raspberry Pi can run a full node and keep up with the network, why not let those users with the resources to operate big iron databases do so? It would be a good feature to have. On 10/29/2015 01:03 AM, Luke Dashjr via bitcoin-dev wrote: > I predict this would be a disaster. UTXO storage is CONSENSUS-CRITICAL code. > Any divergence in implementation behaviour, including bugs AND bugfixes, may > cause consensus failure. For this to have a reasonable *hope* of working, we > need to choose one storage engine, and *will* need to maintain consensus- > compatibility of it ourselves (since nobody else cares). > > Fixing LevelDB frankly seems like an easier task than switching to anything > SQL-based, which would require a *lot* more *difficult-to-get-consensus- > compatible* code that we are all (or at least mostly) very unfamiliar with. > > Research is fine, but let's be realistic about deployment. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >