From: Peter R <peter_r@gmx.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Date: Thu, 29 Oct 2015 21:04:22 -0700 [thread overview]
Message-ID: <3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com> (raw)
In-Reply-To: <CAAS2fgTga_vTfOKrFu_hEzXSfTfg9FRfJ6aL6ginuGFqnbm7=w@mail.gmail.com>
> On Oct 29, 2015, at 8:35 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Oct 30, 2015 at 3:04 AM, Simon Liu via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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 it must be _consistent_, between all nodes.
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 the unspent outputs can be found in the database, and if the relevant information about each output can be retrieved without corruption, then that’s all that really matters as far as the database is concerned.
Let’s use an unspent pay-to-pubkey-hash output as an example: Alice spends this to Bob (she signs it properly), the TX propagates across the network and…then what? Do some nodes disagree on whether or not the TX is valid? What exactly would they disagree on? Are you suggesting that a database bug would cause some nodes to think the output was actually already spent, while others can correctly see that it’s unspent? Or maybe some nodes think the output doesn’t exist while others do? Or are you suggesting that the details about this output might be retrieved with errors from certain databases but correctly from others?
I’d like a concrete example to help me understand why more than one implementation of something like the UTXO database would be unreasonable.
Peter
next prev parent reply other threads:[~2015-10-30 4:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 6:57 [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db telemaco
2015-10-29 8:03 ` Luke Dashjr
2015-10-30 3:04 ` Simon Liu
2015-10-30 3:35 ` Gregory Maxwell
2015-10-30 4:04 ` Peter R [this message]
2015-10-30 4:28 ` Gregory Maxwell
2015-11-15 1:02 ` Peter R
2015-11-15 1:08 ` Gregory Maxwell
2015-11-15 1:45 ` Peter R
2015-11-15 2:10 ` Gregory Maxwell
2015-11-15 2:58 ` Peter R
2015-11-15 3:30 ` Gregory Maxwell
2015-11-15 4:10 ` Peter R
2015-11-15 10:12 ` Jorge Timón
2015-11-15 11:28 ` Jorge Timón
2015-11-15 15:48 ` Peter R
2015-11-15 17:06 ` Peter R
2015-11-17 13:54 ` Tamas Blummer
2015-11-17 15:24 ` Tom Harding
2015-11-17 22:17 ` telemaco
2015-11-20 14:15 ` Jorge Timón
2015-11-16 1:52 ` Rusty Russell
2015-11-15 3:04 ` Luke Dashjr
2015-11-15 3:17 ` Peter R
2015-10-29 8:17 ` Gregory Maxwell
-- strict thread matches above, loose matches on Subject: below --
2015-10-22 21:26 Jeff Garzik
2015-10-22 21:54 ` Patrick Strateman
2015-10-22 21:56 ` Joseph Gleason ⑈
2015-10-23 6:53 ` Jonas Schnelli
2015-10-23 7:45 ` Lucas Betschart
2015-10-28 20:28 ` Sean Lynch
2015-10-28 21:11 ` Jeff Garzik
2015-10-23 10:30 ` Tom Zander
2015-10-26 18:06 ` Douglas Roark
2015-10-28 15:52 ` Tom Zander
2015-11-18 0:06 ` Jonathan Wilkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com \
--to=peter_r@gmx.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=gmaxwell@gmail.com \
--cc=telemaco@neomailbox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox