1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D873D941
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 02:59:01 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6513111C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 02:59:00 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx103)
with ESMTPSA (Nemesis) id 0MMCSP-1a30j21Lmn-00810Q;
Sun, 15 Nov 2015 03:58:53 +0100
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>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:D5UCaQW2otFM6YpDOcn5g8G7Ev4WajM1z1nhJH2HQI9TXQptgLb
+c1uMdBmnz4xhwlMZPY0CiAwITexV+a9aAxJty8dQVXvvgTL4xflYJteX+LiYkSgxIXcQHR
OkOwtQ9NUIXXAkBAwhshCug6Yhu5gravAGXZjIkScN4ZXmAOdebTlQg1veA6WYpNkM0ZGEo
gfheEBfsZrS11tcTbF+kQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:0UYMxGbv7No=:B7Iax/8OEd+4TBG4A6Tfzz
XGnaVq8uIOpm8zyqSJ4NErlq9mrcXDzEVztIqrLFHn5zbHIMO5Nd+xslJ3pnDbgeBZ7fMAhem
WV5SCKN0cL0sJaFgQYlMT4l//puajnmPa9mkuBSIrv38G0GL5SVcLVYP6fkPCZNM264T9E16R
KPdtYcphXiQ/MWA8RJFPZdqg6SOOwHEIyaGG8f3pPL8AdFFDybcHV+EzwisMFP/QQGYLzV+he
kF+VafS7OhID4xDRL34yRY7/Qmc/rmBuQTxBbsdD06aVPg/eQVs37EOXq+940YEIuFrnJtzrI
ZNXVztAoD9ET+NYvbTE1H9OuOx9PTM8X5V2PEgYTxguYKLJIQ98F5IPhSGV132N1OE6rV93RI
jCjYPUvzTyrvz8oj0QBVXOHWtIGDX+x4MMwJJvXv2ZmR3pQ2ZMH11A5pt3UXItQcxZxYiCDxU
7lZL2NSbiqpn5ZGxybQe4ENzsVOFK10M2V8z2NHZaSr9IwakDZrzt6EaEnpnJo4pKbvtpPcNq
RkZyfgTTAAEPJoyQZcmqDftH/RBHQ6WqVrDlt7g6lBgE2S3gDqJziKEhmb1udAuDNUF9FRKZw
AYPSANaJ/2gxWmg2JskLIdlWS+x9jWDRv/gwWFbS+cOEWUEzXG/l6r7yVYrGa2k3XD+GvWWPe
x8GU1HiBN1gSDF38JqeZiuqbc3kwFh4+PshKcJ3EE5+RESm/I8J1C1+mk6TtnbW+LcwlzZmOR
y35/JnrtMWckMKPihu3QDdx4oS5YW8wrJKxl5FQy8QUmm/02s9cEWWGzVjQ9OOqYQN3IqkNqk
K71GvXA
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2015 02:59:02 -0000
> 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
|
