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
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 83B6CC58
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Nov 2019 22:45:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com
[209.85.208.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83EB6196
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Nov 2019 22:45:16 +0000 (UTC)
Received: by mail-ed1-f46.google.com with SMTP id p59so3407183edp.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Nov 2019 14:45:16 -0800 (PST)
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;
bh=HarCHFfmMHUsFUBpylHQ+LNpOw4X0BHtFdnjaEmnCJk=;
b=X1lUYRszxSVfCqdkf2kdJf+2+noma6IjjW7IX+wyJv8mAeBTyfModYWlkrIran13/7
yqy7I3Z+ON2Cb7ZHzB+T9mLTW/eIEBbPg7YweMxXNcmcRvILPcfqICOgan2ll3mNTd5B
Va2Tr1JJ9CYY4dhFcB3o9LAib3sxqOyseJNPQcLXwFZYFM/e34coBlws06/alj5Byhys
admr0eN14cmXb41DBWHOavlqFAv+IAzt6fEne8PFE4S978u/WhQfclkWcIDUbOVA8tgA
SOF0/VpQyHdiR63QLUQZ0GepkyRNZGyw/vnpleOl64kUPayC0GxPCGnivS2KfrRhOJyi
FJPA==
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;
bh=HarCHFfmMHUsFUBpylHQ+LNpOw4X0BHtFdnjaEmnCJk=;
b=n+jRVsTTtuDYmiB/mGgaXQa1S9Im9xQGlTzBxzzPqy2wF63IIy6cvosvcPB+LmnfX0
245+ur/QerPMJCf8OJpI173flFwqFLDNxYTVJvxYoaezxHAIIxFTN2F3ryZ6Dh21AgdU
TcbQO2HHgoTNyrjnfHZluRuuFphLh2Z0t4UJ6SdAlBYxaQTRQvKNw37ubjd5cbpqv/eB
k0XbQIQwHaOmgPm8YxKrplTazCaIXGb1r9LuabELisLNFdwwIpoa1Q4jSckVZUHrM3Cq
Gi7LAg3fPNS41Juqak5czz1zBXoxAYv3zsOBMm7izHesh3DNQUlaD+G+M92909HxrRNI
qitQ==
X-Gm-Message-State: APjAAAUO7/KiBhG4OLyhVrhpH8UZAypbGmqv3kten+JogsNAzysTYey2
0S3C06u2oLQ0Zss1lZrO0L6hu9YOMrOslCD/KyuV/A==
X-Google-Smtp-Source: APXvYqzO3xPxQ0sV/7LNanTXsI4RgPx5ZRrVowr9U4PReP1nu6Kn7kSgxh+XyqM7dVlMJuZXtrxjEOuF0iC9/VGT4cA=
X-Received: by 2002:a50:de0b:: with SMTP id z11mr6714129edk.33.1573166714622;
Thu, 07 Nov 2019 14:45:14 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
In-Reply-To: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 7 Nov 2019 17:45:02 -0500
Message-ID: <CAB3F3DsbPyqUutBNbVcHME0kGWsbTzTtb5tWV+zRERHwpibXBw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000032982a0596c96bb6"
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B,
FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=no 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: Thu, 07 Nov 2019 22:45:18 -0000
--00000000000032982a0596c96bb6
Content-Type: text/plain; charset="UTF-8"
Could the softer touch of just making them non-standard apply as a future
preparation for an accepted softfork? Relaxations could easily be done
later if desired.
On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> 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.
>
> 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.
>
> 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-October/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.
>
> Thoughts?
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000032982a0596c96bb6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Could the softer touch of just making them non-standard a=
pply as a future preparation for an accepted softfork? Relaxations could ea=
sily be done later if desired.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille vi=
a bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote c=
lass=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 nore=
ferrer" target=3D"_blank">https://github.com/sipa/bech32/issues/51</a> for =
details). 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<b=
r>
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<b=
r>
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">=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427=
.html</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" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000032982a0596c96bb6--
|
