{"type":"rich","version":"1.0","author_name":"npub1a3zpmn53lhv8jv7vjg3daletu2e6e9ce88737ga2r7dkr7yc7dss7r6s85","author_url":"https://nostr.ae/npub1a3zpmn53lhv8jv7vjg3daletu2e6e9ce88737ga2r7dkr7yc7dss7r6s85","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-30\n📝 Original message:Storage of UTXO data looks like an implementation detail and thus one\nwould have thought that the choice of database would not increase the\nodds of consensus protocol failure.\n\nBtcd, a full node implementation written in Go, already provides a\ndatabase interface which supports different backends:\n\nhttps://github.com/btcsuite/btcd/tree/master/database\n\nGiven that UTXO storage is considered critical, it seems reasonable to\nlet a node operator decide for themselves if they want data stored in\nLevelDB (which is not fully ACID compliant) or a database like Sqlite,\nOracle, DB2 etc.\n\nIf the storage requirements for UTXO data are fairly simple, consisting\nmainly of puts and gets, there is a decent argument that using a\ndedicated key-value store provides superior performance over a\ntraditional SQL database.\n\nHowever, from a practical perspective, given that nodes operate on a\nrange of different hardware and even a little Raspberry Pi can run a\nfull node and keep up with the network, why not let those users with the\nresources to operate big iron databases do so?  It would be a good\nfeature to have.\n\n\nOn 10/29/2015 01:03 AM, Luke Dashjr via bitcoin-dev wrote:\n\u003e I predict this would be a disaster. UTXO storage is CONSENSUS-CRITICAL code.\n\u003e Any divergence in implementation behaviour, including bugs AND bugfixes, may \n\u003e cause consensus failure. For this to have a reasonable *hope* of working, we \n\u003e need to choose one storage engine, and *will* need to maintain consensus-\n\u003e compatibility of it ourselves (since nobody else cares).\n\u003e \n\u003e Fixing LevelDB frankly seems like an easier task than switching to anything \n\u003e SQL-based, which would require a *lot* more *difficult-to-get-consensus-\n\u003e compatible* code that we are all (or at least mostly) very unfamiliar with.\n\u003e \n\u003e Research is fine, but let's be realistic about deployment.\n\u003e \n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}