From: Gregory Maxwell <gmaxwell@gmail•com>
To: Peter R <peter_r@gmx•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: Sun, 15 Nov 2015 02:10:43 +0000 [thread overview]
Message-ID: <CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com> (raw)
In-Reply-To: <6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com>
On Sun, Nov 15, 2015 at 1:45 AM, Peter R <peter_r@gmx•com> 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 of a block.
The size of a block is not a type 1 failure. There is a clear, known,
unambiguous, and easily measured rule in the system that a block is
not permitted to have a size over a threshold. A block that violates
this threshold is invalid. The only way I can see to classify that
as a type 1 failure is to call the violation of any known system rule
a type 1 failure. "Spends a coin that was already spent" "provides a
signature that doesn't verify with the pubkey" "creates bitcoins out
of thin air" -- these are not logically different than "if size>x
return false".
> Type 2 consensus failures are more severe but also less likely (I’m not aware of a Type 2 consensus failure besides the 92 million bitcoin bug from August 2010). If Core was to accept a rogue TX that created another 92 million bitcoins, I think it would be a good thing if the other implementations forked away from it (we don’t want bug-for-bug compatibility here).
The only consensus consistency error we've ever that I would have
classified as potentially type 1 had has been the BDB locks issue.
Every other one, including the most recently fixed one (eliminated by
BIP66) was a type 2, by your description. They are _much_ more common;
because if the author understood the possible cases well enough to
create an "I don't know" case, they could have gone one step further
and fully defined it in a consistent way. The fact that an
inconsistency was possible was due to a lack of complete knowledge.
Even in the BDB locks case, I don't know that the type 1 distinction
completely applies, a lower layer piece of software threw an error
that higher layer software didn't know was possible, and so it
interpreted "I don't know" as "no"-- it's not that it chose to treat I
don't know as no, its that it wasn't authored with the possibility of
I don't know in mind, and that exceptions were used to handle general
failures (which should have been treated as no). Once you step back to
the boundary of the calling code (much less the whole application) the
"I don't know" doesn't exist anymore; there.
next prev parent reply other threads:[~2015-11-15 2:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 6:57 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
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 [this message]
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=CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=peter_r@gmx$(echo .)com \
--cc=telemaco@neomailbox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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