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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B39A1BAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 21:01:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
[209.85.213.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB1B51C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 21:01:10 +0000 (UTC)
Received: by igxx6 with SMTP id x6so707611igx.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 14:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=tmH3lZqfgeXRk3yglITZNwoDhp8oYlgyFB0jyhEjxQ0=;
b=bg+rZ5wGFLiLwxeHGHS49iaI2SNLGSkvXp8mgUXrRTOuKjRacggAsL7zHQHX1HGeTz
3RKhcMBnk2WtW6Rz8g4gDeKoKcdBBajCn7/6ws3ce0WY2hJiLfwB4jAZXyeZtGEwiTV6
+kcOm8wBK33K/R5Aol9O19wcNc3hAX+DGeNn8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=tmH3lZqfgeXRk3yglITZNwoDhp8oYlgyFB0jyhEjxQ0=;
b=Yo/Y/6vu2Xje1leoGq3FOTDuMA3wn5g5DF83oZRtZMZd3nZ31OpDVUZuZ5gprxIVXY
KzoFBNr2nHC4adXXacSESkCW9VP4tG3qhlcaFUUOvrOTBqmonqMTYrBVKxujDJ0eZyAs
TZA/4POjgEmd3oMUknK8rOIIoTTz6BXVExcfPb/yh+lUfTWUKVFtd4MdzB5m3VetEO1O
zD97Eaab5Oslidx4rkVMtFFKm+50HO5AHCF/AOPKAcEKy4x+KPJ1QibaeM6BxafHHQi6
7DkhguRf+mERlkHP5NxM3cxdNsdxMRaeFRqH7Q+9KwyVRSbrQxI1KEVEp7IGuth7v10D
mtFQ==
X-Gm-Message-State: ALoCoQkQRfVYBkVxHDM5IhMqvrBcPOo1/zg+ciw5sV4oOtUTd0+oXkRxM1IorAsUv1bUieQIPJ5R
MIME-Version: 1.0
X-Received: by 10.50.66.146 with SMTP id f18mr32367085igt.83.1443646870198;
Wed, 30 Sep 2015 14:01:10 -0700 (PDT)
Received: by 10.50.123.166 with HTTP; Wed, 30 Sep 2015 14:01:09 -0700 (PDT)
In-Reply-To: <CAAS2fgR_-x4kUkiMTCi+YdpV-6MXaEp+b2ZzrVc9Dqt3rnfAyA@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
<CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
<CAAS2fgR_-x4kUkiMTCi+YdpV-6MXaEp+b2ZzrVc9Dqt3rnfAyA@mail.gmail.com>
Date: Wed, 30 Sep 2015 23:01:09 +0200
Message-ID: <CA+w+GKQChBBnXNj0hz5i-D=NqQBpQDReD6fNkONRaQhWaxLTVA@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdc09f6e14ada0520fd3ae6
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Wed, 30 Sep 2015 21:01:12 -0000
--047d7bdc09f6e14ada0520fd3ae6
Content-Type: text/plain; charset=UTF-8
tl;dr Nothing I have read here has changed my mind. There is still no
consensus to deploy CLTV in this way.
> Yes, your article contained numerous factual and logical inaccuracies
> which I corrected
>
I responded to your response several times. It was not convincing, and I do
not think you corrected factual inaccuracies. I mean, you said yourself you
once used the correct terminology of forwards compatibility but stopped
only because the term "backwards compatibility" is more common. But that's
not a good reason to use a term with the opposite meaning and is certainly
not a factual correction!
> Yes, because what 101 does is not a hard-fork from the perspective of
> BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV;
I coined the term SPV so I know exactly what it means, and bitcoinj
implements it, as does BreadWallet (the other big SPV implementation).
Yes, SPV wallets will follow the mining hashpower instead of doing a hard
reject for bigger blocks, because they deliberately check a subset of the
rules: block size is not and never has been one of them. Indeed it's not
even included in the protocol messages. Users have no expectation that SPV
wallets would check that, as it's never been claimed they do.
On the other hand, full nodes all claim they run scripts. Users expect that
and may be relying on it. The unstated assumption here is that the nodes
run them correctly. A soft fork breaks this assumption.
I'm going to ignore the rest of the stuff you wrote about "design decisions
to lack security" or "cheaply avoidable lack of validation". When you have
sat down and written an SPV implementation by yourself, then shipped it to
a couple of million users, you might have better insight into basic
engineering costs. Until then, I find your criticisms of code you think was
missing due to "stonewalling" and so on to be seriously lacking real world
experience.
Yes, a hypothetical full node could fork on the version bits. I would be
quite happy with the version number in the header being an enforced
consensus rule: it'd make hard forks easier to trigger. But it hasn't been
done that way, and wishing away the behaviour of existing software in the
field is no good. Luckily, for introducing a new opcode, the same effect
can be achieved by using a non-allocated opcode number.
> For many changes, including CLTV the actual soft fork change is by far
> the most natural way of implementing the change itself.
This is subjective. I'd say picking an entirely new opcode number is most
natural.
The rest of your argument boils down to "people don't have to upgrade if
they don't want to", which is addressed in the article I wrote already, and
multiple responses on this thread. Yes, they do, otherwise they aren't
getting the security level they were before.
> Could [P2SH] have been done as a hard-fork? Likely not: you would have
> prevented it.
What? This is nonsensical. P2SH was added to the full verification code
quite quickly, but it didn't matter much because nobody uses bitcoinj for
mining. The docs explicitly tell people, in fact, not to mine on top of
bitcoinj:
https://bitcoinj.github.io/full-verification
So no, bitcoinj+P2SH was irrelevant from a fork type perspective. It just
had no effect at all. This entire section of your message is completely
wrong.
The code that did take longer was for wallet support. And the reason it
came later was resource prioritisation: there were more important issues to
resolve. Like I said - write the amount of code I've written, unpaid in
your evenings and weekends, and then you can criticise bitcoinj for lacking
features.
75% is a fine activation threshold. By definition if support is at 75% then
bigger blocks is "winning", but if support fell, then the SPV wallets would
just reorg back onto the 1mb-blocks chain.
Re: demonstrated track record. They "work" only if you ignore the actual
problems that have resulted. P2SH-invalid blocks were being mined for weeks
after the flag day. That's not good no matter how you slice it: even if you
didn't hear about any fraud resulting, it is still risk that can be avoided.
--047d7bdc09f6e14ada0520fd3ae6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>tl;dr Nothing I have read here has changed my mind. There is still no cons=
ensus to deploy CLTV in this way.=C2=A0</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex">Yes, your article contained numerous factual and logical inaccuracies<b=
r>
which I corrected<br></blockquote><div><br></div><div>I responded to your r=
esponse several times. It was not convincing, and I do not think you correc=
ted factual inaccuracies. I mean, you said yourself you once used the corre=
ct terminology of forwards compatibility but stopped only because the term =
"backwards compatibility" is more common. But that's not a go=
od reason to use a term with the opposite meaning and is certainly not a fa=
ctual correction!</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Yes, because w=
hat 101 does is not a hard-fork from the perspective of<br>
BitcoinJ clients. Please do not conflate BitcoinJ with all of SPV;</blockqu=
ote><div><br></div><div>I coined the term SPV so I know exactly what it mea=
ns, and bitcoinj implements it, as does BreadWallet (the other big SPV impl=
ementation).</div><div><br></div><div>Yes, SPV wallets will follow the mini=
ng hashpower instead of doing a hard reject for bigger blocks, because they=
deliberately check a subset of the rules: block size is not and never has =
been one of them. Indeed it's not even included in the protocol message=
s. Users have no expectation that SPV wallets would check that, as it's=
never been claimed they do.</div><div><br></div><div>On the other hand, fu=
ll nodes all claim they run scripts. Users expect that and may be relying o=
n it. The unstated assumption here is that the nodes run them correctly. A =
soft fork breaks this assumption.</div><div><br></div><div>I'm going to=
ignore the rest of the stuff you wrote about "design decisions to lac=
k security" or "cheaply avoidable lack of validation". When =
you have sat down and written an SPV implementation by yourself, then shipp=
ed it to a couple of million users, you might have better insight into basi=
c engineering costs. Until then, I find your criticisms of code you think w=
as missing due to "stonewalling" and so on to be seriously lackin=
g real world experience.</div><div><br></div><div>Yes, a hypothetical full =
node could fork on the version bits. I would be quite happy with the versio=
n number in the header being an enforced consensus rule: it'd make hard=
forks easier to trigger. But it hasn't been done that way, and wishing=
away the behaviour of existing software in the field is no good. Luckily, =
for introducing a new opcode, the same effect can be achieved by using a no=
n-allocated opcode number.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For many =
changes, including CLTV the actual soft fork change is by far<br>
the most natural way of implementing the change itself. </blockquote><div><=
br></div><div>This is subjective. I'd say picking an entirely new opcod=
e number is most natural.</div><div><br></div><div>The rest of your argumen=
t boils down to "people don't have to upgrade if they don't wa=
nt to", which is addressed in the article I wrote already, and multipl=
e responses on this thread. Yes, they do, otherwise they aren't getting=
the security level they were before.=C2=A0</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex">Could [P2SH] have been done as a hard-fork?=C2=A0 Likely not: you=
=C2=A0would have prevented it. </blockquote><div><br></div><div>What? This =
is nonsensical. P2SH was added to the full verification code quite quickly,=
but it didn't matter much because nobody uses bitcoinj for mining. The=
docs explicitly tell people, in fact, not to mine on top of bitcoinj:</div=
><div><br></div><div><a href=3D"https://bitcoinj.github.io/full-verificatio=
n">https://bitcoinj.github.io/full-verification</a></div><div><br></div><di=
v><div>So no, bitcoinj+P2SH was irrelevant from a fork type perspective. It=
just had no effect at all. This entire section of your message is complete=
ly wrong.</div></div><div><br></div><div>The code that did take longer was =
for wallet support. And the reason it came later was resource prioritisatio=
n: there were more important issues to resolve. Like I said - write the amo=
unt of code I've written, unpaid in your evenings and weekends, and the=
n you can criticise bitcoinj for lacking features.</div><div><br></div><div=
>75% is a fine activation threshold. By definition if support is at 75% the=
n bigger blocks is "winning", but if support fell, then the SPV w=
allets would just reorg back onto the 1mb-blocks chain.</div><div><br></div=
><div>Re: demonstrated track record. They "work" only if you igno=
re the actual problems that have resulted. P2SH-invalid blocks were being m=
ined for weeks after the flag day. That's not good no matter how you sl=
ice it: even if you didn't hear about any fraud resulting, it is still =
risk that can be avoided.</div></div></div></div>
--047d7bdc09f6e14ada0520fd3ae6--
|
