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: Sat, 14 Nov 2015 18:58:50 -0800 [thread overview]
Message-ID: <13D7C936-4D2E-4BAC-AC61-3DA80581C946@gmx.com> (raw)
In-Reply-To: <CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com>
> On Nov 14, 2015, at 6:10 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
>
> 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.
You are looking at the problem from a “top down” governance perspective assuming you know what code is actually being run and what rules the market wants. The reality is that you can only make estimates about these two things. As Bitcoin evolves away from the current development monoculture, rules such as the max block size may no longer be perfectly clear. However, we can prove that the following results will continue to hold:
1. A node with a block size limit greater than the hash-power weighted median will always follow the longest chain.
2. An excessive (e.g., greater than 1 MB) block will be accepted into the longest chain if it is smaller than the hash-power weighted median block size limit.
Already today, different nodes have different block size limits. There are even some miners today that will attempt to build upon blocks larger than 1 MB if anyone dares to create one. At some point, the majority of the hash power will support something larger than 1 MB. When that first bigger block comes and gets buried in the longest chain, hold-out nodes (e.g., MP says he will never increase his limit) will have to make a choice: fight consensus or track consensus! I know that I would want my node to give up on its block size limit and track consensus. You may decide to make a different choice.
You said that "a block that violates this [block size limit] threshold is invalid.” I agree. If the nodes and miners rejected the block as invalid then it would not persist as the longest chain. If the nodes and miners accepted the block and continued to build on top of it, then that chain would be Bitcoin (whether you personally agree of not).
Bitcoin is ultimately a creature of the market, governed by the code people freely choose to run. Consensus is then an emergent property, objectively represented by the longest persistent chain. Proof-of-work both enforces and defines the rules of the network.
> 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”.
I think you’re being intentionally obtuse here: accepting a block composed entirely of valid transactions that is 1.1 MB is entirely different than accepting a TX that creates a ten thousand bitcoins out of thin air. The market would love the former but abhor the later. I believe you can recognize the difference.
>> 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.
Thank you for conceding on that point.
> 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.
Please don’t take my comments and observations as criticisms. I think the Core Dev team has done excellent work! What I am saying instead is that as we move forward—as development becomes decentralized and multiple protocol implementations emerge—development philosophies will change. Tracking consensus and the will of the market will be most important. Personally, I hope to see design philosophies that support “bottom up” governance instead of the current “top down” model.
Best regards,
Peter
next prev parent reply other threads:[~2015-11-15 2:59 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
2015-11-15 2:58 ` Peter R [this message]
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=13D7C936-4D2E-4BAC-AC61-3DA80581C946@gmx.com \
--to=peter_r@gmx$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(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