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

On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Isolating storage from the rest of consensus code is technically desirable, but implementations using different storage will be unlikely bug-for-bug compatible, > hence able to split the

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

Isolating storage from the rest of consensus code is technically desirable, but implementations using different storage will be unlikely bug-for-bug compatible, hence able to split the network. Such split was disastrous on the network level if partitions were of comparable magnitude - as was

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

Benchmarks for various DBs under discussion: http://symas.com/mdb/microbench/ On Mon, Oct 26, 2015 at 11:06 AM, Douglas Roark via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 2015/10/23 03:30, Tom Zander via bitcoin-dev wrote: > > On Thursday 22 Oct 2015 17:26:42 Jeff Garzik

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

Shouldn't a odbc jdbc jconnect or equivalent be totally transparent for the consensus code? I mean, the client would write or store the data communicating to the driver provided by the vendor. Using the schema bitcoin suggests adapted to many different vendors (one table schema for Oracle,

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

On Nov 15, 2015 5:10 AM, "Peter R via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > What rules does Bitcoin obey? Thanks to the worl of many people, part of the consensus rules are finally encapsulated in the libbitcoinconsensus library. I'm currently writing a document to

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

Hello Jorge: > > What rules does Bitcoin obey? > > Thanks to the worl of many people, part of the consensus rules are finally > encapsulated in the libbitcoinconsensus library. I'm currently writing a > document to complete the encapsulation of the specification of the consensus > rules. > I

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

On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote: > My previous email described how Type 1 consensus failures can be safely dealt > with. These include many kinds of database exceptions (e.g., the LevelDB > fork at block #225,430), or consensus mismatches regarding the max size

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

On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote: > A group of us have been exploring this “meta-cognition” idea with Bitcoin > Unlimited. For example, Bitcoin Unlimited can be (optionally) made to > automatically fork to the longest chain if it “gets stuck” and can neither >

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

> On Nov 14, 2015, at 6:10 PM, Gregory Maxwell wrote: > > On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote: >> My previous email described how Type 1 consensus failures can be safely >> dealt with. These include many kinds of database exceptions (e.g., the

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

> On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote: >> A group of us have been exploring this “meta-cognition” idea with Bitcoin >> Unlimited. For example, Bitcoin Unlimited can be (optionally) made to >> automatically fork to the longest chain if it “gets stuck” and can

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

Hi Greg, Like you said, the issue with using more than one database technology is not that one node would prove that Block X is valid while the another node proves that Block X is NOT valid. Instead, the problem is that one node might say “valid” while the other node says “I don’t know.” It

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:

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

On Monday 26 Oct 2015 11:06:56 Douglas Roark via bitcoin-dev wrote: > While not exactly the most rigorous link, > https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability seems like an > okay place to start. Thanks for that link! Another Google open source product I'll avoid like the plague ;)

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

On Wed, Oct 28, 2015 at 4:28 PM, Sean Lynch wrote: > On Fri, Oct 23, 2015 at 1:23 AM Lucas Betschart via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Facebook has a LevelDB fork which is maintained. >> It's called RocksDB and the API seems to be nearly

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

On 2015/10/23 03:30, Tom Zander via bitcoin-dev wrote: > On Thursday 22 Oct 2015 17:26:42 Jeff Garzik via bitcoin-dev wrote: >> It was noted that leveldb is unmaintained, and this is part of researching >> alternatives that are maintained and reliable. > > Apart from it being unmaintained, any

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

On Thursday 22 Oct 2015 17:26:42 Jeff Garzik via bitcoin-dev wrote: > It was noted that leveldb is unmaintained, and this is part of researching > alternatives that are maintained and reliable. Apart from it being unmaintained, any links to what are problems with levelDB?

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Here is the beginnings of an implementation to replace leveldb > with sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite > > It builds, but still needs work before passing tests. Nice work! Although not sure if we should focus directly