> On Oct 29, 2015, at 8:35 PM, Gregory Maxwell via bitcoin-dev
> wrote:
>
> 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.
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 that
> if all th
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 obviously that is
preferable) but that i
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:
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 statistics/graphs/analisys with existing
> software
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. UTX
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
