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
|
Return-Path: <roconnor@blockstream.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 46D62C0733
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 20:56:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 3C7BC8AD8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 20:56:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id pN7otkDqEYTb
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 20:56:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f51.google.com (mail-io1-f51.google.com
[209.85.166.51])
by hemlock.osuosl.org (Postfix) with ESMTPS id 6DB678AD8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 20:56:24 +0000 (UTC)
Received: by mail-io1-f51.google.com with SMTP id l1so3757672ioh.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 13:56:24 -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;
bh=vCf7AAu90dVKsw+By64V7NyyKwuxhy4ydWYXNH9gsOs=;
b=VpA/OnCzMfxBCKi52Sj6SIo6MRKNRNE8EGgNNkQ06lL5sFK1bWybxdvVWLxnfhNTi+
fCVhlDQX/G61hryZ2c8/jQxLmixQ4kopESz9J/qt0npRF9aEBhNrOgzHQhZ+ryEYlWyV
DEYd+PFeuySkkZVVQDHNI7bs78OzTFnzhnYCdg0IV7Te9RREdWULaVW1UxSaEVAbhci5
LgIgy1PS+wfQ9W+46gGZwFlZSGBup5fxfsBDBYRE6+1pXJ2BhTxdyjJ5gHkEbEMRxqjZ
uOlQzuoBx58mcJLVOyjMPuWQDS+/uZiBkSAIy4CnbtOqG5B+KSpzVtkGY88OPBLgvPhu
FmsA==
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=vCf7AAu90dVKsw+By64V7NyyKwuxhy4ydWYXNH9gsOs=;
b=tmJWZ49YAZl03OBWZRWngRfAcuZQk8hpxmZRht/CTCjgzLbVaFMw+nFWCyD7gt1vmG
2Nzp+lTFcSJFisZzu9uNPxoQfqL+TXaeVqrRJY5dSob0zC5FQezidKNOvL67JC953meo
B0TQER5YAoO93M27iOxW/PG4/LFpLTtDUXsMwKmelYdTgyoyQcSce4dyEuEiNh2OJLxc
djuAYorCu+91SPsPkJ4wx/mXQIO2MdJJ5OmuMnLtKKBoP+CT7hDBfrXO5CwN1+LIw1na
9pxREVO7wI/fVWcJbws0yhXUnrsIytEFDfRLMHeG0qiiWGyvOj1cC+gl/ZgmKZ0zqNV+
twqw==
X-Gm-Message-State: AOAM533H0DcCB5RPGR1++Xk4V6QDmb2dy6Io8MxSVU1Iikk5b9PixGDF
WtMcqGPTaFq2a+RMzZfu9EQKgNHFjfs+/Xkji2feNg==
X-Google-Smtp-Source: ABdhPJwkbOab4JWLtWmvl6dWh9qXZzUZtDAxkryubWxWSpGgslqsCQUAIprMZJdjgKo5pxRivvBAqw7q6DigBnBFyoE=
X-Received: by 2002:a6b:ee02:: with SMTP id i2mr1206400ioh.110.1594846583680;
Wed, 15 Jul 2020 13:56:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
<20191108021541.n3jk54vucplryrbl@ganymede>
<CAPg+sBgus6HgYPVbXaAx51nO2ArsR3-6=obe2AwkO8kh11fB6Q@mail.gmail.com>
<611b4e5b-e7cf-adc7-31e1-b5ff24b6574b@mattcorallo.com>
<CAHGSxGv_BQAAkdcxsqVsjphqaoE=Xm05jXhdBnGw+m+vRxeQYQ@mail.gmail.com>
<2sU6YozN9nn30cofkAMhffgjDLZwjG3mvF0nBgOsVQQEY9ROmP72GuHWjnBlF_qa8eeQPU8bxleZqcvRGJgS-uJ2xWYmAm9HjrFWWx_9o8k=@protonmail.com>
<CAPg+sBio_8vT9NNp39rz7m+omfaRs0Mf6JkET1=caoVwvziJSA@mail.gmail.com>
In-Reply-To: <CAPg+sBio_8vT9NNp39rz7m+omfaRs0Mf6JkET1=caoVwvziJSA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 15 Jul 2020 16:56:12 -0400
Message-ID: <CAMZUoKn4OmyGOMBH==2Fx2N7GYbw2RbYK98pxu_pD5QTmDw9KQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000178e5a05aa81282e"
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot
addresses
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, 15 Jul 2020 20:56:25 -0000
--000000000000178e5a05aa81282e
Content-Type: text/plain; charset="UTF-8"
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> That brings me to Matt's point: there is no need to do this right now. We
> can simply amend BIP173 to only permit length 20 and length 32 (and only
> length 20 for v0, if you like; but they're so far apart that permitting
> both shouldn't hurt), for now. Introducing the "new" address format (the
> one using an improved checksum algorithm) only needs to be there in time
> for when a non-32-byte-witness-program would come in sight.
>
As a prerequisite to taproot activation, I was looking into amending BIP173
as stated above. However after reviewing
https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
it seems that insertions of 5 characters or more is "safe" in the sense
that there is low probability of creating a valid checksum by doing so
randomly.
This means we could safely allow witness programs of lengths *20*, 23, 26,
29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses of
length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also support a
set of shorter addresses, but given the lack of entropy in such short
addresses, it is hard to believe that such witness programs could be used
to secure anything. I'm not sure what the motivation for allowing such
short witness programs was, but I'm somewhat inclined to exclude them from
the segwit address format.
Given that we would only be able to support one of 39 or 40 byte witness
programs, it is sensible to choose to allow 40 byte witness programs to be
addressable. This is the maximum witness program size allowed by BIP 141.
So my proposal would be to amend BIP173 in such a way to restrict "bc" and
"tb" segwit address formats to require witness programs be of size *20*,
23, 26, 29, *32*, 36, or 40. Witness programs of other sizes (between 2
and 40) would, of course, still be legal in accordance with BIP 141;
however they would be unaddressable by using this "bc" and "tb" prefix.
Another address format would be needed to support other witness sizes,
should the need ever arise.
--
Russell O'Connor
--000000000000178e5a05aa81282e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><br><div dir=3D"auto">=
That brings me to Matt's point: there is no need to do this right now. =
We can simply amend BIP173 to only permit length 20 and length 32 (and only=
length 20 for v0, if you like; but they're so far apart that permittin=
g both shouldn't hurt), for now. Introducing the "new" addres=
s format (the one using an improved checksum algorithm) only needs to be th=
ere in time for when a non-32-byte-witness-program would come in sight.</di=
v></div></blockquote><div><br></div><div>As a prerequisite to taproot activ=
ation, I was looking into amending BIP173 as stated above.=C2=A0 However af=
ter reviewing <a href=3D"https://gist.github.com/sipa/a9845b37c1b298a7301c3=
3a04090b2eb#detection-of-insertion-errors" target=3D"_blank">https://gist.g=
ithub.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-erro=
rs</a> it seems that insertions of 5 characters or more is "safe"=
in the sense that there is low probability of creating a valid checksum by=
doing so randomly.</div><div><br></div><div>This means we could safely all=
ow witness programs of lengths <b>20</b>, 23, 26, 29, <b>32</b>, 36, and 40=
(or 39).=C2=A0 These correspond to Bech32 addresses of length <b>42</b>, 4=
7, 52, 57, <b>62</b>, 68, and 74 (or 73).=C2=A0 We could also support a set=
of shorter addresses, but given the lack of entropy in such short addresse=
s, it is hard to believe that such witness programs could be used to secure=
anything.=C2=A0 I'm not sure what the motivation for allowing such sho=
rt witness programs was, but I'm somewhat inclined to exclude them from=
the segwit address format.<br></div><div><br></div><div>Given that we woul=
d only be able to support one of 39 or 40 byte witness programs, it is sens=
ible to choose to allow 40 byte witness programs to be addressable.=C2=A0 T=
his is the maximum witness program size allowed by BIP 141.</div><div><br><=
/div><div>So my proposal would be to amend BIP173 in such a way to restrict=
"bc" and "tb" segwit address formats to require witnes=
s programs be of size <b>20</b>, 23, 26, 29, <b>32</b>, 36, or 40.=C2=A0 Wi=
tness programs of other sizes (between 2 and 40) would, of course, still be=
legal in accordance with BIP 141; however they would be unaddressable by u=
sing this "bc" and "tb" prefix.=C2=A0 Another address f=
ormat would be needed to support other witness sizes, should the need ever =
arise.<br></div><div><br></div><div>-- <br></div><div>Russell O'Connor<=
br></div></div></div>
--000000000000178e5a05aa81282e--
|
