<oembed><type>rich</type><version>1.0</version><author_name>npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_name><author_url>https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-10-29&#xA;📝 Original message:On Thursday, October 29, 2015 6:57:39 AM telemaco via bitcoin-dev wrote:&#xA;&gt; Why not allow two options:&#xA;&gt; &#xA;&gt; 1/ a default RocksDB/SQLite/LevelDB (whatever is decided)&#xA;&gt; 2/ alternative provide instructions for connection to any other rdbms&#xA;&gt; using odbc or jdbc.&#xA;&#xA;I predict this would be a disaster. UTXO storage is CONSENSUS-CRITICAL code.&#xA;Any divergence in implementation behaviour, including bugs AND bugfixes, may &#xA;cause consensus failure. For this to have a reasonable *hope* of working, we &#xA;need to choose one storage engine, and *will* need to maintain consensus-&#xA;compatibility of it ourselves (since nobody else cares).&#xA;&#xA;Fixing LevelDB frankly seems like an easier task than switching to anything &#xA;SQL-based, which would require a *lot* more *difficult-to-get-consensus-&#xA;compatible* code that we are all (or at least mostly) very unfamiliar with.&#xA;&#xA;Research is fine, but let&#39;s be realistic about deployment.&#xA;&#xA;Luke</html></oembed>