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
|
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 BC7E021FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 16:46:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F28571A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 16:46:29 +0000 (UTC)
Received: by igcrk20 with SMTP id rk20so65305281igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 09:46:29 -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=wQulGXg33u3wE9rm1fIfQyThOidetb5lJFmMtcVGmCc=;
b=nSYQBLDIvkKzXYuRSYLqHk1MdzjLAYye1X42PwsuTeCbAsAGmqWiNFPv13RHK81TUN
U5i4GI7q1d8jttv7lr2bIupnlDTPJ6arh1GcavAxsXI6b5p10qpfYuncxCUqaFMw5jtC
nguYwHP+8ScA1zuEeJjPULzan0rylKXqBIDUQ=
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=wQulGXg33u3wE9rm1fIfQyThOidetb5lJFmMtcVGmCc=;
b=YdWXr5FCfcxdSJ7t3iXWyMl4cVEnB4lcts1ww3yKcwtr+xakDMmZF/HRhdizeGW1hV
jRHG/xFXGkslHaWOss2uAZ3CjZSYpuC/1ws7OyfhcXS2cXdtnx47aDYWUIeoCiJ0vlbz
sNNc2OGmzqHQUYyOxX9me6Nk5x+Rk7pE1M/uutc9yIE1b7+jiDHXRM/ATSSaWSbc3e/H
CF2A23sCHFXbAyj2Qdly2P12hkr9ONTKh70hknpdZ0SzgnViSmozHBUhK2qgd0Y58Clk
PKLn4Z3GlrtbnPU0rpRiIvsb5z+TEC0YZQrObHpmJ5m9T6hKyRKNjZpC9YTOUbwcDkGQ
gEQg==
X-Gm-Message-State: ALoCoQnvMXD3+wF5g8VKbT4id5h/ej43vvJeV/ElJ9mLj0+aFY/pBX2hotomxozEj3LWsuzfmyRb
MIME-Version: 1.0
X-Received: by 10.50.111.231 with SMTP id il7mr9016025igb.34.1444063588842;
Mon, 05 Oct 2015 09:46:28 -0700 (PDT)
Received: by 10.50.123.166 with HTTP; Mon, 5 Oct 2015 09:46:28 -0700 (PDT)
In-Reply-To: <CABm2gDpgpRg9U5ToNM98pQgz8VRwT8o817zrpJgOj06PwySk_Q@mail.gmail.com>
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
<BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
<CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
<CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
<CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com>
<CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
<CA+w+GKS-AZGBSwuN1dgEs6wa-R=jHE0fmfmQ0TL9Cw9b6L71UQ@mail.gmail.com>
<CABm2gDpgpRg9U5ToNM98pQgz8VRwT8o817zrpJgOj06PwySk_Q@mail.gmail.com>
Date: Mon, 5 Oct 2015 18:46:28 +0200
Message-ID: <CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=047d7b4142c83f363605215e411f
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: Mon, 05 Oct 2015 16:46:30 -0000
--047d7b4142c83f363605215e411f
Content-Type: text/plain; charset=UTF-8
>
> As Greg explained to you repeatedly, a softfork won't cause a
> non-upgraded full node to start accepting blocks that create more
> subsidy than is valid.
>
It was an example. Adam Back's extension blocks proposal would, in fact,
allow for a soft forking change that creates more subsidy than is valid (or
does anything else) by hiding one block inside another.
Anyway, I think you got my point.
> That's very different security from an SPV node, and as Greg
> also explained, SPV nodes could be much more secure than bitcoinj
> nodes (they could, for example, validate the coinbase transaction of
> every block).
>
I'm pretty sure Gregory did not use such an example because it's dead
wrong. You cannot verify the size of a coinbase without being a fully
verifying node because you need to know the fees in the block, and
calculating that requires access to the entire UTXO set.
This sort of thing is why I get annoyed when people lecture me about SPV
wallets and the things they "should" do. None of you guys has built one. I
keep seeing wild statements about theoretical unicorn wallets that nobody
has even designed, and how all existing wallets are crappy and insecure
because they don't meet your ever shifting goal posts.
To everyone making such statements I say: go away and build an SPV wallet
of your own from scratch. Then you will understand the engineering
tradeoffs involved much better, and be in a much better position to debate
what they should or should not be doing.
And bear in mind if it weren't for the work myself and a few others did on
SPV wallets, everyone would be using web wallets instead. Then you'd all
just complain about that instead.
> Can you give an example of an attack in which a non-upgraded full node
> wallet is defrauded with BIP65 but could not with the hardfork
> alternative (that nobody seems to be willing to implement)?
>
Making it a hard fork instead is changing one line of code (ignoring the
code to set up the flag day, which can be based on the code for BIP101). If
it comes down to it, then I'll do the work to change that one line. But
obviously I'd need to see agreement from the maintainers that such a pull
req would be merged first.
The example is this: find someone that accepts 1-block confirmed
transactions in return for something valuable. There are plenty of them out
there. Once the soft fork starts, send a P2SH transaction that defines a
new output controlled by OP_CLTV. It will be incorporated into the UTXO set
by all miners because it's opaque (p2sh).
Now send a transaction that pays the merchant, and make it spend your
OP_CLTV output with an invalid script. New nodes will reject it as a rule
violator. Old nodes won't. So at some point an old miner will create a
block containing your invalid transaction, the merchant will think they got
paid, they'll give you the stuff and the fraud is done.
> Please, don't assume 0 confirmation transactions or similar
> unreasonable assumptions (ie see section 11 "Calculations" of the
> Bitcoin whitepaper).
>
This is just embarrassing - do any of you guys at Blockstream actually use
Bitcoin in the real world? Virtually all payments that aren't moving money
into/out of exchange wallets are 0-confirm in reality. I described a
1-confirm attack above, but really ... come on.
--047d7b4142c83f363605215e411f
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"><blo=
ckquote 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;paddi=
ng-left:1ex">As Greg explained to you repeatedly, a softfork won't caus=
e a<br>
non-upgraded full node to start accepting blocks that create more<br>
subsidy than is valid.<br></blockquote><div><br></div><div>It was an exampl=
e. Adam Back's extension blocks proposal would, in fact, allow for a so=
ft forking change that creates more subsidy than is valid (or does anything=
else) by hiding one block inside another.</div><div><br></div><div>Anyway,=
I think you got my point.</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">That'=
s very different security from an SPV node, and as Greg also=C2=A0explained=
, SPV nodes could be much more secure than bitcoinj nodes=C2=A0(they could,=
for example, validate the coinbase transaction of every=C2=A0block).<br></=
blockquote><div><br></div><div>I'm pretty sure Gregory did not use such=
an example because it's dead wrong. You cannot verify the size of a co=
inbase without being a fully verifying node because you need to know the fe=
es in the block, and calculating that requires access to the entire UTXO se=
t.</div><div><br></div><div>This sort of thing is why I get annoyed when pe=
ople lecture me about SPV wallets and the things they "should" do=
. None of you guys has built one. I keep seeing wild statements about theor=
etical unicorn wallets that nobody has even designed, and how all existing =
wallets are crappy and insecure because they don't meet your ever shift=
ing goal posts.</div><div><br></div><div>To everyone making such statements=
I say: go away and build an SPV wallet of your own from scratch. Then you =
will understand the engineering tradeoffs involved much better, and be in a=
much better position to debate what they should or should not be doing.<br=
></div><div><br></div><div>And bear in mind if it weren't for the work =
myself and a few others did on SPV wallets, everyone would be using web wal=
lets instead. Then you'd all just complain about that instead.<br></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">Can you give an example of an attack in =
which a non-upgraded full node<br>
wallet is defrauded with BIP65 but could not with the hardfork<br>
alternative (that nobody seems to be willing to implement)?<br></blockquote=
><div><br></div><div>Making it a hard fork instead is changing one line of =
code (ignoring the code to set up the flag day, which can be based on the c=
ode for BIP101). If it comes down to it, then I'll do the work to chang=
e that one line. But obviously I'd need to see agreement from the maint=
ainers that such a pull req would be merged first.</div><div><br></div><div=
>The example is this: find someone that accepts 1-block confirmed transacti=
ons in return for something valuable. There are plenty of them out there. O=
nce the soft fork starts, send a P2SH transaction that defines a new output=
controlled by OP_CLTV. It will be incorporated into the UTXO set by all mi=
ners because it's opaque (p2sh).</div><div><br></div><div>Now send a tr=
ansaction that pays the merchant, and make it spend your OP_CLTV output wit=
h an invalid script. New nodes will reject it as a rule violator. Old nodes=
won't. So at some point an old miner will create a block containing yo=
ur invalid transaction, the merchant will think they got paid, they'll =
give you the stuff and the fraud is done.</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">
Please, don't assume 0 confirmation transactions or similar<br>
unreasonable assumptions (ie see section 11 "Calculations" of the=
<br>
Bitcoin whitepaper).<br>
</blockquote></div><br></div><div class=3D"gmail_extra">This is just embarr=
assing - do any of you guys at Blockstream actually use Bitcoin in the real=
world? Virtually all payments that aren't moving money into/out of exc=
hange wallets are 0-confirm in reality. I described a 1-confirm attack abov=
e, but really ... come on.</div></div>
--047d7b4142c83f363605215e411f--
|
