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: <roconnor@blockstream.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4A671C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 May 2020 15:16:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 37AEC86AD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 May 2020 15:16:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CjcShpZQ262r
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 May 2020 15:15:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com
[209.85.166.53])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 5ABBB86AC9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 May 2020 15:15:59 +0000 (UTC)
Received: by mail-io1-f53.google.com with SMTP id y5so3513728iob.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 May 2020 08:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=3WRnRN9gV4bVyCh4mD84l3zuywiD7vyyFYhDAwy8xuI=;
b=JQuhLZJP01Xt/xjKM+ZPUjEQWsdvdccfcPiZrJDHq68957Pr27fgsXP01LiueC02o0
1oTIg2qzaED0YncYdbV7UPS0sV44T2XFx0bzQUaScnBfjMFIaxlYTK75t3rfujQzp6gc
6YS+H+Ry4D+zTzoiY0HJf0S5RwxROTyDJ/WhrVKlf72VCOsuMswyKW4uZhYm7hG//2QA
oEyWLboiZdgbbv2QkneHE0Zak2PwEPGox5MUP4nT7buD7zNIIc2YTkpDNa2OtReQceYz
no1/WrHsEbVV4dJm9Dl/M50oUSkDO6UrFkGNyA3SGOvhfiaLcp7VeEyAcdP1LtnrgcPs
wUzg==
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=3WRnRN9gV4bVyCh4mD84l3zuywiD7vyyFYhDAwy8xuI=;
b=mekxzqyvO+G0TgL1ydufZsh4sOrv/pKoj1NgorZxKzoYCUm+6pBV7wEoSaJftEib91
wq/4MLIqBBm7mcYWCJxKu2+s8ToZ012KOqVueMat5Vg28bJzO3Z98df5oU5600QLkqQb
AWY+zr/dsK6d8fwil6UjznOeAQzEmQ1xFRjN2e+cmcB7aiPgKpDy29/khzpPIheRE3p1
byFNiGpZnyXJnT4aYP+/Rnoiu8vw4MhLU5/SVz76C30U0ZihWwbzy7SVuncTfJNfuA/Z
3YzckHivhxIIQj91AvvYjeVNrY6trliqdCPXTxriNKApDpANOjwZhkyxUr2zsYh3FcJ2
WKOQ==
X-Gm-Message-State: AOAM532ZN9OXjfzo1P/yTNNxEauilBm1Fnf8KvZuxysODuZkeTZ2qya7
u1/BCmPnwUK6UetuKJcxkEMMabpvtYz2sG9h4Lt3UQ==
X-Google-Smtp-Source: ABdhPJzmqOeQaazBo5Qd3zBdaBSVacy9i19VsBTrtMKnDMhoncv6jDNZ3nc9r43UaCbEAlLqrb/IcXS1EvTzcr0BvdE=
X-Received: by 2002:a05:6602:2e0e:: with SMTP id
o14mr21342231iow.164.1590592558589;
Wed, 27 May 2020 08:15:58 -0700 (PDT)
MIME-Version: 1.0
References: <aa916637-befa-795a-caa1-e5ad50ce63c8@electrum.org>
<CAB3F3DuGi_Uc0cf5eGvE9ej2d1RS8CVkf7xGBjR4uRf8jAmQhA@mail.gmail.com>
<CAB3F3DtCgdWOPpTdr-cMcnRO1RE2isEAavGZSOTvtSi-0_x64w@mail.gmail.com>
<Ptq11JJF3B5h2X94dQdis8lFf7PSm_Hg9F2uITk4MhGcXULr3eiuF3GF71fEVZpcsNZ_s_nrRCXcUmxthQQq4vPQERQpUbCNYErVA9yuNNc=@protonmail.com>
In-Reply-To: <Ptq11JJF3B5h2X94dQdis8lFf7PSm_Hg9F2uITk4MhGcXULr3eiuF3GF71fEVZpcsNZ_s_nrRCXcUmxthQQq4vPQERQpUbCNYErVA9yuNNc=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 27 May 2020 11:15:47 -0400
Message-ID: <CAMZUoKkA+=-r-OkDWP_GpN2xCsPpTfJnetzSmXtEzD8ZjH8OxA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000070093105a6a2b0fa"
Cc: Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Wed, 27 May 2020 15:16:01 -0000
--00000000000070093105a6a2b0fa
Content-Type: text/plain; charset="UTF-8"
I don't believe that 60 bytes is a problem here. SHA256 padding includes a
length value of the original message data. Thus a padded non-64 byte
transaction can never be the same as any padded 64-byte value, and
therefore after applying the SHA256 compression function the resulting
hashes cannot be identical (unless SHA256 itself is broken).
P.S. SHA256 also includes 10* padding, which also suffices to ensure
messages of different lengths have different padding.
On Sat, May 23, 2020 at 8:52 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning Thomas,
>
> > So I think the question to ask would be "why can't we just make sure
> it's not 64?"
>
> If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it
> may still be possible to mount CVE-2017-12842 attack with 32-bits of work.
> Of course some other details will be changed from the standard SHA-256 in
> mounting this attack, but from my poor understanding it seems safer to just
> avoid the area around length 64.
>
> It *might* be safe to accept 65-byte or larger (but do not believe me, I
> only play a cryptographer on the Internet), but that does not help your
> specific application, which uses 60 byte tx.
>
> Regards,
> ZmnSCPxj
>
> >
> > On Sat, May 23, 2020 at 11:24 AM Greg Sanders <gsanders87@gmail.com>
> wrote:
> >
> > > AFAIU the number was picked to protect against CVE-2017-12842
> covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 which
> updated the text to explicitly mention this fact.
> > >
> > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >
> > > > Hello list,
> > > >
> > > > I have been trying to CPFP a transaction using OP_RETURN, because the
> > > > remaining output value would have been lower than the dust threshold.
> > > >
> > > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> > > > single p2wsh input.
> > > >
> > > > The result is a 60 bytes transaction (without witness), that gets
> > > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE,
> which
> > > > is equal to 82 bytes.
> > > >
> > > > Why is that value so high? Would it make sense to lower it to 60?
> > > >
> > > > Thomas
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000070093105a6a2b0fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>I don't believe t=
hat 60 bytes is a problem here.=C2=A0=20
SHA256 padding includes a length value of the original message data. Thus a=
padded non-64 byte transaction can never be the same as any padded 64-byte=
value, and therefore after applying the SHA256 compression function the re=
sulting hashes cannot be identical (unless SHA256 itself is broken).</div><=
div><br></div><div>P.S. SHA256 also includes 10* padding, which also suffic=
es to ensure messages of different lengths have different padding.<br></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Sat, May 23, 2020 at 8:52 PM ZmnSCPxj via bitcoin-dev <<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Good morning Thomas,<br>
<br>
> So I think the question to ask would be "why can't we just ma=
ke sure it's not 64?"<br>
<br>
If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may=
still be possible to mount CVE-2017-12842 attack with 32-bits of work.<br>
Of course some other details will be changed from the standard SHA-256 in m=
ounting this attack, but from my poor understanding it seems safer to just =
avoid the area around length 64.<br>
<br>
It *might* be safe to accept 65-byte or larger (but do not believe me, I on=
ly play a cryptographer on the Internet), but that does not help your speci=
fic application, which uses 60 byte tx.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
><br>
> On Sat, May 23, 2020 at 11:24 AM Greg Sanders <<a href=3D"mailto:gs=
anders87@gmail.com" target=3D"_blank">gsanders87@gmail.com</a>> wrote:<b=
r>
><br>
> > AFAIU the number was picked to protect against=C2=A0CVE-2017-1284=
2 covertly. See:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/16=
885" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoi=
n/pull/16885</a>=C2=A0which updated the text to explicitly mention this fac=
t.<br>
> ><br>
> > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev =
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> ><br>
> > > Hello list,<br>
> > ><br>
> > > I have been trying to CPFP a transaction using OP_RETURN, be=
cause the<br>
> > > remaining output value would have been lower than the dust t=
hreshold.<br>
> > ><br>
> > > The scriptPubkey of the output was OP_RETURN + OP_0, and the=
re was a<br>
> > > single p2wsh input.<br>
> > ><br>
> > > The result is a 60 bytes transaction (without witness), that=
gets<br>
> > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS=
_SIZE, which<br>
> > > is equal to 82 bytes.<br>
> > ><br>
> > > Why is that value so high? Would it make sense to lower it t=
o 60?<br>
> > ><br>
> > > Thomas<br>
> > > _______________________________________________<br>
> > > bitcoin-dev mailing list<br>
> > > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> > > <a href=3D"https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<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></div>
--00000000000070093105a6a2b0fa--
|
