📅 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
>
Simon Liu [ARCHIVE] /
npub1a3…r6s85
2023-06-07 17:43:54
in reply to nevent1q…ja3s
Author Public Key
npub1a3zpmn53lhv8jv7vjg3daletu2e6e9ce88737ga2r7dkr7yc7dss7r6s85Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:43:54Event JSON
{
"id": "bc57e2c3e74a5d2fcb29e14533540ce549e530be48f46b2a35c8e3976f8712e2",
"pubkey": "ec441dce91fdd87933cc9222deff2be2b3ac971939fd1f23aa1f9b61f898f361",
"created_at": 1686159834,
"kind": 1,
"tags": [
[
"e",
"09f07bc0e1ba48805727ba44deb034dc283bfadbc39b90714e52ddd0cad07414",
"",
"root"
],
[
"e",
"d35bdf1a6fefe316291e23d633c0c842fac64bdcb01cec91ae9cfd4c1b3d7c20",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 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",
"sig": "1d7d4f59a92d3cedcb5264124af2307bfd6fab512365d4427c3862e0c615c33f9b7acd26ed1a3f1f915e3d3d7c827491c00d9f795204ec7d4583b721796bfd8b"
}