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
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 80DF61174
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jun 2018 11:04:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com
[209.85.215.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D890604
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jun 2018 11:04:31 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id y20-v6so23811277lfy.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 09 Jun 2018 04:04:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=jONLnOE+xgNDoCG6rY5ZuLisfsHj5PQhVkQv8WkQoOY=;
b=DJ5itZ1Kys9KgciHLMDW2z82Nr7gS1rVgHBEQhpfYreaDyTr98qinIRi7XaPZP9JOG
ZfiQOUGFTN+zZKISxf0+TAqtXBJ7e2cMpIar1g3M8+vUX4B5JANcqIbHS1BPmWL9C5z9
2uazEJoNs3BhV7nJxi6dLrkqBbV1jEMC3UdGul4XFxWnrj2CsgB1P9oAiuYKmYQGy3Bv
HYNLOaJ+ornyxwjhOR3N0kAKonU7/ao0csQjL6mxrUj0PcoxoTMsKrofwJchLGJab6kD
XdrkxM4oOae+RCevVGkVLXFlpzqkol/S/NT+U7vbdX8wHX9KP0uIEQqlGACn5dln/F8A
qF1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=jONLnOE+xgNDoCG6rY5ZuLisfsHj5PQhVkQv8WkQoOY=;
b=ArTM+WrzlAU3qT0N2D1WyNUlK00c3bDQBvQOCpDXQdAdebQC6AiiVWPoiYRJK5py5x
31mw8ytUkC0NRR8U3YR1/fX2HAIBanPF8LUPkWcL3EJnFOZH4Kycpl0pHnFWti8KMR2A
AdNxkMbfVzZmKp03iLA8Tlv5MSh7cPrsp6bKz+RQrBdQGPrC7l7QtE3BlXPdZ06FL/Wg
6yGwFJVbI5iv+zaLEI6xm71Awco9Rz9epX17umUjsfdYW4E61A8PjZS9954rdY5JLqg+
CCBTyYQjYhqpwgQa/9sWV8fXOTPvRzex0MgLJlmEUDxaSVxUrHkYOgGwKG7QzS/jtcNx
1vFg==
X-Gm-Message-State: APt69E2cgdqjryduwAVrNrkWBMnpArbO8ZB4XMlq0ccsrErHQdcD4crg
lVMyMKR1CWU5eYXV0oXpLTsEAdXuFXWMidQmkyxutlgd
X-Google-Smtp-Source: ADUXVKLoV1T3gVRWKLIJ7oFwU/dTO7dSMiU7RvaNEqrM6vDKIXkKZ0uiPb1TZPjjh2CCGPKGxdveOPZOlUqiB0sHTRU=
X-Received: by 2002:a19:e544:: with SMTP id
c65-v6mr6296876lfh.134.1528542270419;
Sat, 09 Jun 2018 04:04:30 -0700 (PDT)
MIME-Version: 1.0
References: <20180607171311.6qdjohfuuy3ufriv@petertodd.org>
<CAHUJnBB7UL3mH6SixP_M4yooMVP3DgZa+5hiQOmF=AiqfdpfOg@mail.gmail.com>
<20180607222028.zbva4vrv64dzrmxy@petertodd.org>
<CAHUJnBCj8wnjP1=jobfpg7jkfjkX9iSBLeeAOyQCpobh6-AhUA@mail.gmail.com>
In-Reply-To: <CAHUJnBCj8wnjP1=jobfpg7jkfjkX9iSBLeeAOyQCpobh6-AhUA@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Sat, 9 Jun 2018 13:03:53 +0200
Message-ID: <CAKzdR-paqYgOxToikaVD=0GMsCjHBaynX3WgB-CN6Sn7B7kRXw@mail.gmail.com>
To: bram@chia.net, bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000d757e056e337b00"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 09 Jun 2018 14:58:55 +0000
Subject: Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion
proofs without a soft fork
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 09 Jun 2018 11:04:33 -0000
--0000000000000d757e056e337b00
Content-Type: text/plain; charset="UTF-8"
Hi Peter,
We reported this as CVE-2017-12842, although it may have been known by
developers before us.
There are hundreds of SPV wallets out there, without even considering other
more sensitive systems relying on SPV proofs.
As I said we, at RSK, discovered this problem in 2017. For RSK it's very
important this is fixed because our SPV bridge uses SPV proofs.
I urge all people participating in this mailing list and the rest of the
Bitcoin community to work on this issue for the security and clean-design
of Bitcoin.
My suggestion is to use in the version bits 4 bits indicating the tree
depth (-1), as a soft-fork, so
00=1 depth,
0F = 16 depth (maximum 64K transactions). Very clean.
The other option is to ban transaction with size lower or equal to 64.
Best regards,
Sergio.
On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> So are you saying that if fully validating nodes wish to prune they can
> maintain the ability to validate old transactions by cacheing the number of
> transactions in each previous block?
>
> On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:
>> > Are you proposing a soft fork to include the number of transactions in a
>> > block in the block headers to compensate for the broken Merkle format?
>> That
>> > sounds like a good idea.
>> >
>> > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > > It's well known that the Bitcoin merkle tree algorithm fails to
>> distinguish
>> > > between inner nodes and 64 byte transactions, as both txs and inner
>> nodes
>> > > are
>> > > hashed the same way. This potentially poses a problem for tx inclusion
>> > > proofs,
>> > > as a miner could (with ~60 bits of brute forcing) create a
>> transaction that
>> > > committed to a transaction that was not in fact in the blockchain.
>> > >
>> > > Since odd-numbered inner/leaf nodes are concatenated with themselves
>> and
>> > > hashed
>> > > twice, the depth of all leaves (txs) in the tree is fixed.
>> > >
>> > > It occured to me that if the depth of the merkle tree is known, this
>> > > vulnerability can be trivially avoided by simply comparing the length
>> of
>> > > the
>> > > merkle path to that known depth. For pruned nodes, if the depth is
>> saved
>> > > prior
>> > > to pruning the block contents itself, this would allow for completely
>> safe
>> > > verification of tx inclusion proofs, without a soft-fork; storing this
>> ^^^^^^^^^^^^^^^^^^^
>>
>> Re-read my post: I specifically said you do not need a soft-fork to
>> implement
>> this. In fact, I think you can argue that this is an accidental feature,
>> not a
>> bug, as it further encourages the use of safe full verifiaction rather
>> than
>> unsafe lite clients.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000000d757e056e337b00
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Peter,<div>We reported this as CVE-2017-12842, although=
it may have been known by developers before us.=C2=A0</div><div>There are=
=C2=A0hundreds of SPV wallets out there, without even considering other mor=
e sensitive systems relying on SPV proofs.=C2=A0</div><div>As I said we, at=
RSK, discovered this problem in 2017. For RSK it's very important this=
is fixed because our SPV bridge uses SPV proofs.</div><div>I urge all peop=
le participating in this mailing list and the rest of the Bitcoin community=
to work on this issue for the security and clean-design of Bitcoin.</div><=
div><br></div><div>My suggestion is to use in the version bits 4 bits indic=
ating the tree depth (-1), as a soft-fork, so=C2=A0</div><div>00=3D1 depth,=
=C2=A0</div><div>0F =3D 16 depth (maximum 64K transactions).=20
<span style=3D"background-color:rgb(255,255,255);text-decoration-style:init=
ial;text-decoration-color:initial;float:none;display:inline">Very clean.</s=
pan></div><div>=C2=A0</div><div>The other option is to ban transaction with=
size lower or equal to 64.=C2=A0</div><div><br></div><div>Best regards,</d=
iv><div>=C2=A0Sergio.</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr">On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">So are you saying that if fully validating nodes wish to prune th=
ey can maintain the ability to validate old transactions by cacheing the nu=
mber of transactions in each previous block?</div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd=
<span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_bla=
nk">pete@petertodd.org</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span>On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:<br>
> Are you proposing a soft fork to include the number of transactions in=
a<br>
> block in the block headers to compensate for the broken Merkle format?=
That<br>
> sounds like a good idea.<br>
> <br>
> On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> <br>
> > It's well known that the Bitcoin merkle tree algorithm fails =
to distinguish<br>
> > between inner nodes and 64 byte transactions, as both txs and inn=
er nodes<br>
> > are<br>
> > hashed the same way. This potentially poses a problem for tx incl=
usion<br>
> > proofs,<br>
> > as a miner could (with ~60 bits of brute forcing) create a transa=
ction that<br>
> > committed to a transaction that was not in fact in the blockchain=
.<br>
> ><br>
> > Since odd-numbered inner/leaf nodes are concatenated with themsel=
ves and<br>
> > hashed<br>
> > twice, the depth of all leaves (txs) in the tree is fixed.<br>
> ><br>
> > It occured to me that if the depth of the merkle tree is known, t=
his<br>
> > vulnerability can be trivially avoided by simply comparing the le=
ngth of<br>
> > the<br>
> > merkle path to that known depth. For pruned nodes, if the depth i=
s saved<br>
> > prior<br>
> > to pruning the block contents itself, this would allow for comple=
tely safe<br>
> > verification of tx inclusion proofs, without a soft-fork; storing=
this<br>
</span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0^^^^^^^^^^^^^^^^^^^<br>
<br>
Re-read my post: I specifically said you do not need a soft-fork to impleme=
nt<br>
this. In fact, I think you can argue that this is an accidental feature, no=
t a<br>
bug, as it further encourages the use of safe full verifiaction rather than=
<br>
unsafe lite clients.<br>
<div class=3D"m_-1263791027191071155HOEnZb"><div class=3D"m_-12637910271910=
71155h5"><br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000000d757e056e337b00--
|
