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
|
Return-Path: <gsanders87@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4B53DC0733
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 21:05:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 29C9E22264
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 21:05:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3FakWz7YoScB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 21:05:35 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com
[209.85.221.51])
by silver.osuosl.org (Postfix) with ESMTPS id 511672201C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 21:05:35 +0000 (UTC)
Received: by mail-wr1-f51.google.com with SMTP id a6so4387029wrm.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2020 14:05:35 -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=uOvXHKvK2e7atAvjmx66cskkx2Islae6HVEDCW+YCTc=;
b=TxMD+Q4C883dsmTCly1HuR+kWLLB0CpozX2xUc+OLTIsESPzAk1zF2jTXS9/g9XhyX
0SqsWtm1RIaFi135y40bt9EFt8He8bWcJU/4CVOcd+m93VYTOMnSy6cJdV7G59S1B/6B
Ex2LJwd1yf3FF+YSMMowOCZSSNA0QYkbTT0dBClEaX3/dCD+EZVUEdAiTEsqGogyJZ/y
oDFQ4YWB8xNvkpIJLc4X2c/DFBGCSkQa0bJfeFtwcoOx03c5xSdfPK5jTMdggvZxLoHP
H9Hm/VIszqBnKSVbzYW27HRZ15vknba3dAiQ5adeWls4wZmzOBqDb03NWbpk55tH8FxO
h27g==
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=uOvXHKvK2e7atAvjmx66cskkx2Islae6HVEDCW+YCTc=;
b=Jp4l8QiemC11qYOSTlzT8l8b0BPzYiH51dB0pgNk65JLREiKvZs5Swis9NFthlaEjw
Xuw0UOizrH7TaP99N5RTiPYD4/Fgwjiqaw9nXYUFdtn+OIocs3u+F4z5FbQGO7XxxdJQ
W75M37xMrSygiisOV/HTk25aMDCF9lSdjUmeljdEhk1bCxepbENBIz8Axl6qDa3V9R/b
PDtd18dccGx4/F1NTiHBUEImFvUk4apH/zi7rfK+mcFQPBWLxITE+/OFM1Mu4EJ1BJeb
JnnzIwDu1L6av0kuavU77TnH8ofLfIWDkbP117T4Xn0g3rRNazWoQfPmmdHd7/87+Cit
SbdQ==
X-Gm-Message-State: AOAM533fm98ru1hnA7rznXlcqww0cA5V0QM42j1diVFn3CF7XfpGMmM8
NI9DzWYbR58m/UyFlSqYqhbIdo2Y6IvXz4+CRq4=
X-Google-Smtp-Source: ABdhPJy2wqEzyGoNxUg38fhksmNPOeWm9bodSausJFHtij2aimRGq8TbTUPwyV9s+PxzZEQeQ1FOEkUeRoAAvXKSof0=
X-Received: by 2002:adf:e4d0:: with SMTP id v16mr1384146wrm.193.1594847133641;
Wed, 15 Jul 2020 14:05:33 -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>
<CAMZUoKn4OmyGOMBH==2Fx2N7GYbw2RbYK98pxu_pD5QTmDw9KQ@mail.gmail.com>
In-Reply-To: <CAMZUoKn4OmyGOMBH==2Fx2N7GYbw2RbYK98pxu_pD5QTmDw9KQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 15 Jul 2020 17:05:22 -0400
Message-ID: <CAB3F3Dv4evEZ_b7Z3Vc+wFCvD8UMOvJdFGyOAajrHpEUqz+g=g@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000df2fdc05aa81484f"
Cc: Pieter Wuille <pieter.wuille@gmail.com>
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 21:05:37 -0000
--000000000000df2fdc05aa81484f
Content-Type: text/plain; charset="UTF-8"
Can you make it clear what the bold vs not-bold numbers mean?
On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000df2fdc05aa81484f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Can you make it clear what the bold vs not-bold numbers me=
an?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><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 vi=
a bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><b=
r><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 permitting both shouldn't hurt), for now. Introducing the &q=
uot;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 woul=
d come in sight.</div></div></blockquote><div><br></div><div>As a prerequis=
ite to taproot activation, I was looking into amending BIP173 as stated abo=
ve.=C2=A0 However after reviewing <a href=3D"https://gist.github.com/sipa/a=
9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors" target=3D"_b=
lank">https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detecti=
on-of-insertion-errors</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 allow 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>, 47, 52, 57, <b>62</b>, 68, and 74 (or 73).=C2=A0 We coul=
d 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 cou=
ld be used to secure anything.=C2=A0 I'm not sure what the motivation f=
or allowing such short witness programs was, but I'm somewhat inclined =
to exclude them from the segwit address format.<br></div><div><br></div><di=
v>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.=C2=A0 This is the maximum witness program size allowed by BIP =
141.</div><div><br></div><div>So my proposal would be to amend BIP173 in su=
ch a way to restrict "bc" and "tb" segwit address forma=
ts to require witness programs be of size <b>20</b>, 23, 26, 29, <b>32</b>,=
36, or 40.=C2=A0 Witness programs of other sizes (between 2 and 40) would,=
of course, still be legal in accordance with BIP 141; however they would b=
e unaddressable by using this "bc" and "tb" prefix.=C2=
=A0 Another address format 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>
_______________________________________________<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>
--000000000000df2fdc05aa81484f--
|
