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
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 021621908
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Oct 2015 15:46:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 74C8B16F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Oct 2015 15:46:12 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
(may be forged)) (authenticated bits=0)
by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t97Fk4IY006127
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Wed, 7 Oct 2015 08:46:04 -0700
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
In-Reply-To: <20151007150014.GA21849@navy>
Date: Wed, 7 Oct 2015 08:46:08 -0700
Message-Id: <A763EBF7-4FA5-4FE4-9595-01317B264B0A@toom.im>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
<20151007150014.GA21849@navy>
To: Anthony Towns <aj@erisian.com.au>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVaBqEdbeWz+GANRkuSTCttkkTIyMNK461uP9bH3QLNChXfjZjCVk0fMd3PSODmza3Rw5icbkjzNsooQ9QJyEnK3
X-Sonic-ID: C;2vY8hApt5RGKHuK7sH9FTg== M;Khe9hApt5RGKHuK7sH9FTg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@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, 07 Oct 2015 15:46:13 -0000
--Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D
Content-Type: multipart/alternative;
boundary="Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E"
--Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> *But* a soft fork that only forbids transactions that would previously
> not have been mined anyway should be the best of both worlds, as it
> automatically reduces the liklihood of old miners building newly =
invalid
> blocks to a vanishingly small probability; which means that upgraded
> bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*
> continuing to work fine during the upgrade.
I agree with pretty much everything you wrote except the above =
paragraph.
An attacker can create a transaction that would be valid if it were an =
OP_NOP, but not valid if it were any more restrictive transaction. For =
example, an attacker might send 1 BTC to an address with . An old node =
would consider that OP_CLTV to be OP_NOP, so no signature is necessary =
for old nodes. Then the attacker buys something from a merchant running =
old node code or an SPV client, and spends the 1 BTC in that address in =
a way that is invalid according to OP_CLTV but valid according to =
OP_NOP, and includes a hefty fee. A miner on the old version includes =
this transaction into a block, thereby making the block invalid =
according to the new rules, and rejected by new-client miners. The =
merchant sees the 1-conf, and maybe even 2-conf, rejoices, and ships. =
The attacker then has until the OP_CLTV matures to double-spend the coin =
with new nodes using a valid signature.
Basically, it's trivial to create transactions that exploit the =
difference in validation rules as long as miners are still on the old =
version to mine them. Transactions can be created that are guaranteed to =
be orphaned and trivially double-spendable. Attackers never have to risk =
actual losses. This can be done as long as miners continue to mine =
old-version blocks, regardless of their frequency.
Those of you who know Script better than me: would this be an example of =
a transaction that would be spendable with a valid sig XOR with (far =
future date OR old code)?
OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIGVERIFY =
OP_PUSHDATA <locktime far in the future> OP_CLTV
--Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Oct 7, 2015, at 8:00 AM, Anthony =
Towns via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">*But* a soft fork that only forbids transactions that would =
previously</span><br style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">not have been mined anyway should be the best of both =
worlds, as it</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">automatically reduces the liklihood of old miners building =
newly invalid</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">blocks to a vanishingly small probability; which means that =
upgraded</span><br style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV =
clients *all*</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">continuing to work fine during the upgrade.</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"></blockquote></div><br><div>I =
agree with pretty much everything you wrote except the above =
paragraph. </div><div><br></div><div>An attacker can create a =
transaction that would be valid if it were an OP_NOP, but not valid if =
it were any more restrictive transaction. For example, an attacker might =
send 1 BTC to an address with . An old node would consider that =
OP_CLTV to be OP_NOP, so no signature is necessary for old nodes. Then =
the attacker buys something from a merchant running old node code or an =
SPV client, and spends the 1 BTC in that address in a way that is =
invalid according to OP_CLTV but valid according to OP_NOP, and includes =
a hefty fee. A miner on the old version includes this transaction into a =
block, thereby making the block invalid according to the new rules, and =
rejected by new-client miners. The merchant sees the 1-conf, and maybe =
even 2-conf, rejoices, and ships. The attacker then has until the =
OP_CLTV matures to double-spend the coin with new nodes using a valid =
signature.</div><div><br></div><div>Basically, it's trivial to create =
transactions that exploit the difference in validation rules as long as =
miners are still on the old version to mine them. Transactions can be =
created that are guaranteed to be orphaned and trivially =
double-spendable. Attackers never have to risk actual losses. This can =
be done as long as miners continue to mine old-version blocks, =
regardless of their frequency.</div><div><br></div><div>Those of you who =
know Script better than me: would this be an example of a transaction =
that would be spendable with a valid sig XOR with (far future date OR =
old code)?</div><div><br></div><div>OP_DUP OP_HASH160 <pubkeyhash> =
OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA <locktime far in the =
future> OP_CLTV</div></body></html>=
--Apple-Mail=_8E5410BB-A0B4-49AD-BD40-D7C48CFD765E--
--Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWFT5BAAoJEIEuMk4MG0P1PlkIAMlcg9QOFu92Ud6AIp4Z2+YO
Mrx2Pr3Dd+duFyg4T1bttxe+u4MT0FKx3zor6rRBh22Qy7f21q938CSdfis4gftC
NLLQUWK47TNFYRlBWK6UPlb/5vEajCiWoHoTxKqVq2nrjPxbV3VKDPe15I4MlGf1
yJmrOFTdmU5H4HGZLhJpr7qwe3r3RTC/sZbqeHe1EFJr5Efur1H3Yr5KA8qX8CrZ
GWzBtQEbn6ki8SLEqLu+aa+0NwRZmpmx4VQWPqrwq7Hr6TC5UrKK93/ucGtFyYCV
iXidPHMcRoWUNMb0VRUq6cXChaeJakBtW7iN4bJUCXa/+F2yb5OTA5wuE/5M7Hs=
=uIZA
-----END PGP SIGNATURE-----
--Apple-Mail=_10A148AF-A824-4221-8950-26C72284DD1D--
|
