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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 40342A7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Nov 2019 00:41:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75E15710
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Nov 2019 00:41:56 +0000 (UTC)
Received: from [IPv6:2620:6e:a000:1000:dc76:997a:6e6b:8675] (unknown
[IPv6:2620:6e:a000:1000:dc76:997a:6e6b:8675])
by mail.as397444.net (Postfix) with ESMTPSA id ABE26FE1D2;
Fri, 8 Nov 2019 00:41:54 +0000 (UTC)
Content-Type: multipart/alternative;
boundary=Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 7 Nov 2019 19:41:54 -0500
Message-Id: <701F6185-EB2C-4EB1-AAAA-1133879CF541@mattcorallo.com>
References: <CAB3F3DsbPyqUutBNbVcHME0kGWsbTzTtb5tWV+zRERHwpibXBw@mail.gmail.com>
In-Reply-To: <CAB3F3DsbPyqUutBNbVcHME0kGWsbTzTtb5tWV+zRERHwpibXBw@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17B84)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot
addresses
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: Fri, 08 Nov 2019 00:41:57 -0000
--Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Given the issue is in the address format, not the consensus/standardness lay=
er, it does seem somewhat strange to jump to addressing it with a consensus/=
standardness fix. Maybe the ship has sailed, but for the sake of considering=
all our options, we could also redefine bech32 to not allow such addresses.=
Matt
>> On Nov 7, 2019, at 17:47, Greg Sanders via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
> =EF=BB=BF
> Could the softer touch of just making them non-standard apply as a future p=
reparation for an accepted softfork? Relaxations could easily be done later i=
f desired.
>=20
>>> On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>> Hello all,
>>=20
>> A while ago it was discovered that bech32 has a mutation weakness (see
>> https://github.com/sipa/bech32/issues/51 for details). Specifically,
>> when a bech32 string ends with a "p", inserting or erasing "q"s right
>> before that "p" does not invalidate it. While insertion/erasure
>> robustness was not an explicit goal (BCH codes in general only have
>> guarantees about substitution errors), this is very much not by
>> design, and this specific issue could have been made much less
>> impactful with a slightly different approach. I'm sorry it wasn't
>> caught earlier.
>>=20
>> This has little effect on the security of P2WPKH/P2WSH addresses, as
>> those are only valid (per BIP173) for specific lengths (42 and 62
>> characters respectively). Inserting 20 consecutive "p"s in a typo
>> seems highly improbable.
>>=20
>> I'm making this post because this property may unfortunately influence
>> design decisions around bip-taproot, as was brought up in the review
>> session (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Oct=
ober/017427.html)
>> past tuesday. In the current draft, witness v1 outputs of length other
>> than 32 remain unencumbered, which means that for now such an
>> insertion or erasure would result in an output that can be spent by
>> anyone. If that is considered unacceptable, it could be prevented by
>> for example outlawing v1 witness outputs of length 31 and 33.
>>=20
>> Thoughts?
>>=20
>> Cheers,
>>=20
>> --=20
>> Pieter
>> _______________________________________________
>> 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
--Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><div dir=3D"ltr">Given the=
issue is in the address format, not the consensus/standardness layer, it do=
es seem somewhat strange to jump to addressing it with a consensus/standardn=
ess fix. Maybe the ship has sailed, but for the sake of considering all our o=
ptions, we could also redefine bech32 to not allow such addresses.</div><div=
dir=3D"ltr"><br></div><div dir=3D"ltr">Matt</div><div dir=3D"ltr"><br><bloc=
kquote type=3D"cite">On Nov 7, 2019, at 17:47, Greg Sanders via bitcoin-dev &=
lt;bitcoin-dev@lists.linuxfoundation.org> wrote:<br><br></blockquote></di=
v><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">Coul=
d the softer touch of just making them non-standard apply as a future prepar=
ation for an accepted softfork? Relaxations could easily be done later if de=
sired.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br=
>
<br>
A while ago it was discovered that bech32 has a mutation weakness (see<br>
<a href=3D"https://github.com/sipa/bech32/issues/51" rel=3D"noreferrer noref=
errer" target=3D"_blank">https://github.com/sipa/bech32/issues/51</a> for de=
tails). Specifically,<br>
when a bech32 string ends with a "p", inserting or erasing "q"s right<br>
before that "p" does not invalidate it. While insertion/erasure<br>
robustness was not an explicit goal (BCH codes in general only have<br>
guarantees about substitution errors), this is very much not by<br>
design, and this specific issue could have been made much less<br>
impactful with a slightly different approach. I'm sorry it wasn't<br>
caught earlier.<br>
<br>
This has little effect on the security of P2WPKH/P2WSH addresses, as<br>
those are only valid (per BIP173) for specific lengths (42 and 62<br>
characters respectively). Inserting 20 consecutive "p"s in a typo<br>
seems highly improbable.<br>
<br>
I'm making this post because this property may unfortunately influence<br>
design decisions around bip-taproot, as was brought up in the review<br>
session (<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2019-October/017427.html" rel=3D"noreferrer noreferrer" target=3D"_blank">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427.ht=
ml</a>)<br>
past tuesday. In the current draft, witness v1 outputs of length other<br>
than 32 remain unencumbered, which means that for now such an<br>
insertion or erasure would result in an output that can be spent by<br>
anyone. If that is considered unacceptable, it could be prevented by<br>
for example outlawing v1 witness outputs of length 31 and 33.<br>
<br>
Thoughts?<br>
<br>
Cheers,<br>
<br>
-- <br>
Pieter<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" r=
el=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></div></body></html>=
--Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E--
|
