Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com>
Date: Sat, 14 Nov 2015 18:58:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <13D7C936-4D2E-4BAC-AC61-3DA80581C946@gmx.com>
References: <5631C363.5060705@neomailbox.net>
	<201510290803.52734.luke@dashjr.org>
	<5632DE33.7030600@bitcartel.com>
	<CAAS2fgTga_vTfOKrFu_hEzXSfTfg9FRfJ6aL6ginuGFqnbm7=w@mail.gmail.com>
	<3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com>
	<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
	<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
	<CAAS2fgTLE1cpDqKTiy0r1VMex7zTAB8tgUC=Y0WXmbNBJL42xQ@mail.gmail.com>
	<6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com>
	<CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.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
Precedence: list


> On Nov 14, 2015, at 6:10 PM, Gregory Maxwell <gmaxwell@gmail.com> =
wrote:
>=20
> 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.
>=20
> 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. =20

You are looking at the problem from a =E2=80=9Ctop down=E2=80=9D =
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. =20

You said that "a block that violates this [block size limit] threshold =
is invalid.=E2=80=9D  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). =20=


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. =20


>  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=E2=80=9D.

I think you=E2=80=99re 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. =20


>> Type 2 consensus failures are more severe but also less likely (I=E2=80=
=99m 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=E2=80=99t want =
bug-for-bug compatibility here).
>=20
> 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.=20

> 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.
>=20
> 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=E2=80=99t 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=E2=80=94as development becomes =
decentralized and multiple protocol implementations emerge=E2=80=94develop=
ment philosophies will change. Tracking consensus and the will of the =
market will be most important.  Personally, I hope to see design =
philosophies that support =E2=80=9Cbottom up=E2=80=9D governance instead =
of the current =E2=80=9Ctop down=E2=80=9D model. =20

Best regards,
Peter