Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

Why not allow two options: 1/ a default RocksDB/SQLite/LevelDB (whatever is decided) 2/ alternative provide instructions for connection to any other rdbms using odbc or jdbc. Why not allowing async disk writes or incredibly fast database systems if someone wants to have a node in a very fast

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Thu, Oct 29, 2015 at 6:57 AM, telemaco via bitcoin-dev wrote: > Why not "outsource" totally that data management part to the already > existing with decades of experience database world. People would be able to > create incredibly easy bitcoin

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Thursday, October 29, 2015 6:57:39 AM telemaco via bitcoin-dev wrote: > Why not allow two options: > > 1/ a default RocksDB/SQLite/LevelDB (whatever is decided) > 2/ alternative provide instructions for connection to any other rdbms > using odbc or jdbc. I predict this would be a disaster.

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Fri, Oct 30, 2015 at 3:04 AM, Simon Liu via bitcoin-dev wrote: > Given that UTXO storage is considered critical, it seems reasonable to This sounds like a misunderstanding of what consensus criticial means. It does not mean that it must be right (though

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Fri, Oct 30, 2015 at 4:04 AM, Peter R wrote: > Can you give a specific example of how nodes that used different database > technologies might determine different answers to whether a given transaction > is valid or invalid? I’m not a database expert, but to me it would seem

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

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: