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
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
Return-Path: <hello@meedamian.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 00D83146B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Nov 2019 13:42:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f178.google.com (mail-il1-f178.google.com
[209.85.166.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E91B5712
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Nov 2019 13:42:25 +0000 (UTC)
Received: by mail-il1-f178.google.com with SMTP id n18so5142902ilt.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Nov 2019 05:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=meedamian.com; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=xQdx6QlIyljE3uNw6/ghqa+KQ0Ws6mdbws5UB8UwTnc=;
b=KkC1Mm81qeTHHXzqH9AAoQLImu7eifas7gccZzMorvPumYeXr8CrT0xQ7vEqLKDIXe
/4OgmMsXegIDm9TlA3bA+FIznHzs8XfBxKcMdDquvcyBjJFDbvd08PoNM9N//S6M5goa
PPT2M381MzHNZHTLgb28Rs5c2niB2HTliCAxo=
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=xQdx6QlIyljE3uNw6/ghqa+KQ0Ws6mdbws5UB8UwTnc=;
b=e6kXqVkp+TP6Bg/Tr8NaFur/dAQ8SGHrvnm4iKEeIcEjRhn3asu304S1agQFdpigSm
kgmeLNCfpvnj92t/h38PezEpbYm8kcJNwjOUtfZ7euwmqwEEIOWWJaHUcY746cLfbfjq
FyvKIehB8QpcnrAc9RTV//kzTOXUwboGUj//brAlvho3YZ5sYk6FhS6gGKsEC7PyI0c9
pfYZPmHFLAY3XI1sl6f90gRrsksjbXhNeFBJbVqVjRBKC/SELG+920B63iPFcJiKgTT4
r7RUuL72s5YY2XW9FcetLPYK90psK1bj5tNSLiZ91q1q5hJut4cFljKukbMlWbzklNPw
UTmg==
X-Gm-Message-State: APjAAAV3anmkrKRnumzWhtHMhldhjHmiqa21c5t2V46DKYKwNL5ZVKZh
RBq7iqw9udy49HmlraF+tscvOzZGmZmsfkv3PyEQv2v4IU7+odqP
X-Google-Smtp-Source: APXvYqynoCVKUOcMLr7OYCZGwP+Mle7YdJn4WxbE4SDjulk1YpIOTE4a+9WJgH6de0rOfaU2xMSnnbsmZSSjKWBAHHY=
X-Received: by 2002:a92:9cce:: with SMTP id x75mr12680246ill.31.1573220545073;
Fri, 08 Nov 2019 05:42:25 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
<sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com>
<CAMZUoK=QFPAzZzxFOA6ZYez_dwCTi_OxYup19w32suDvBdXJoQ@mail.gmail.com>
In-Reply-To: <CAMZUoK=QFPAzZzxFOA6ZYez_dwCTi_OxYup19w32suDvBdXJoQ@mail.gmail.com>
From: Damian Mee <btc@meedamian.com>
Date: Fri, 8 Nov 2019 14:42:13 +0100
Message-ID: <CANeGfAeOK3bC+NkAtYaT-6XVmi8_200rU_=Jv7OszEGdkXN85g@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000be2f110596d5f37c"
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_INVALID,
DKIM_SIGNED, DOS_RCVD_IP_TWICE_B, 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
X-Mailman-Approved-At: Fri, 08 Nov 2019 14:24:32 +0000
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 13:42:27 -0000
--000000000000be2f110596d5f37c
Content-Type: text/plain; charset="UTF-8"
> a new human-readable-prefix for length prefixed bitcoin witness
programs. "btc1" anyone?
Yes, please!
On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I do like the idea of length prefixing the witness program. I will note
> that the 1 byte witness version is really more like a 1 character witness
> version. There are 17 different segwit versions and there are 32
> characters in the bech32 alphabet. That leaves 15 unused characters that
> we can use for assigning new meanings too.
>
> That said, it is probably most sensible to define a new
> human-readable-prefix for length prefixed bitcoin witness programs. "btc1"
> anyone?
>
> On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Pieter, and all,
>>
>> Can we modify Bech32 SegWit address format for version 1 and above as
>> below?
>>
>> * The data-part values:
>> ** 1 byte: the witness version
>> + ** If the witness version is non-zero, 1 byte: the length of the
>> witness program.
>> ** A conversion of the 2-to-40-byte witness program (as defined by [
>> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141])
>> to base32:
>> *** Start with the bits of the witness program, most significant
>> bit per byte first.
>> *** Re-arrange those bits into groups of 5, and pad with zeroes at
>> the end if needed.
>> *** Translate those bits to characters using the table above.
>>
>> This retains the ability of a bech32 address to specify any valid witness
>> length and allows future version 1 addresses with lengths other than 32,
>> while closing this malleation.
>>
>> Older software being given the modified v1 address format would mis-send
>> it to the wrong witness program, however.
>>
>> Alternately we could just keep using version 0 in the address format
>> forever.
>> The requirement would be to ensure that SegWit vN (N >= 1) output witness
>> programs would have a data-part value encoded as below:
>>
>> * The data-part values:
>> ** 1 byte: legacy witness version, which must always be 0.
>> ** 1 byte: actual witness version, which must be non-zero.
>> ** 1 byte: padding length: 0 or 1.
>> ** If padding length is 1, 1 byte: padding, which must be 0.
>> ** 1 byte: witness program length.
>> ** variable: witness program.
>>
>> A writer for a v1 or later address would initially set an empty padding,
>> then compute:
>>
>> 1 // actual witness version
>> + 1 // padding length
>> + 1 // witness length
>> + witness_length
>>
>> If the above sum is 20 or 32, then the writer selects a non-zero padding
>> and inserts the padding byte so that the above sum is now 21 or 33.
>>
>> To a reader that understands only bech32 v0, such an encoding would look
>> like a SegWit v0 invalid-program-length, and be rejected.
>> A reader which understands the above protocol would, instead of rejecting
>> a SegWit v0 invalid-program-length, instead attempt to parse it as above
>> first, and consider it as SegWit v1 or higher if it was parsed correctly as
>> above.
>>
>> The above proposal is of course ridiculous and I am now currently running
>> diagnostics on my processing units to see if further glitches occur in test
>> reasoning skills.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> 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
>
--000000000000be2f110596d5f37c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> a new human-readable-prefix for length prefixed bitco=
in witness programs.=C2=A0 "btc1" anyone?<div><br></div><div>Yes,=
please!</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bit=
coin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I do like the idea o=
f length prefixing the witness program.=C2=A0 I will note that the 1 byte w=
itness version is really more like a 1 character witness version.=C2=A0 The=
re are 17 different segwit versions and there are 32 characters in the bech=
32 alphabet.=C2=A0 That leaves 15 unused characters that we can use for ass=
igning new meanings too.</div><div><br></div><div>That said, it is probably=
most sensible to define a new human-readable-prefix for length prefixed bi=
tcoin witness programs.=C2=A0 "btc1" anyone?<br></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 8, 20=
19 at 12:12 AM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">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 Pieter, and all,<br>
<br>
Can we modify Bech32 SegWit address format for version 1 and above as below=
?<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * The data-part values:<br>
=C2=A0 =C2=A0 =C2=A0 ** 1 byte: the witness version<br>
=C2=A0 =C2=A0 + ** If the witness version is non-zero, 1 byte: the length o=
f the witness program.<br>
=C2=A0 =C2=A0 =C2=A0 ** A conversion of the 2-to-40-byte witness program (a=
s defined by [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-01=
41.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco=
in/bips/blob/master/bip-0141.mediawiki</a> BIP141]) to base32:<br>
=C2=A0 =C2=A0 =C2=A0 *** Start with the bits of the witness program, most s=
ignificant bit per byte first.<br>
=C2=A0 =C2=A0 =C2=A0 *** Re-arrange those bits into groups of 5, and pad wi=
th zeroes at the end if needed.<br>
=C2=A0 =C2=A0 =C2=A0 *** Translate those bits to characters using the table=
above.<br>
<br>
This retains the ability of a bech32 address to specify any valid witness l=
ength and allows future version 1 addresses with lengths other than 32, whi=
le closing this malleation.<br>
<br>
Older software being given the modified v1 address format would mis-send it=
to the wrong witness program, however.<br>
<br>
Alternately we could just keep using version 0 in the address format foreve=
r.<br>
The requirement would be to ensure that SegWit vN (N >=3D 1) output witn=
ess programs would have a data-part value encoded as below:<br>
<br>
=C2=A0 =C2=A0 * The data-part values:<br>
=C2=A0 =C2=A0 ** 1 byte: legacy witness version, which must always be 0.<br=
>
=C2=A0 =C2=A0 ** 1 byte: actual witness version, which must be non-zero.<br=
>
=C2=A0 =C2=A0 ** 1 byte: padding length: 0 or 1.<br>
=C2=A0 =C2=A0 ** If padding length is 1, 1 byte: padding, which must be 0.<=
br>
=C2=A0 =C2=A0 ** 1 byte: witness program length.<br>
=C2=A0 =C2=A0 ** variable: witness program.<br>
<br>
A writer for a v1 or later address would initially set an empty padding, th=
en compute:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 1 // actual witness version<br>
=C2=A0 =C2=A0 + 1 // padding length<br>
=C2=A0 =C2=A0 + 1 // witness length<br>
=C2=A0 =C2=A0 + witness_length<br>
<br>
If the above sum is 20 or 32, then the writer selects a non-zero padding an=
d inserts the padding byte so that the above sum is now 21 or 33.<br>
<br>
To a reader that understands only bech32 v0, such an encoding would look li=
ke a SegWit v0 invalid-program-length, and be rejected.<br>
A reader which understands the above protocol would, instead of rejecting a=
SegWit v0 invalid-program-length, instead attempt to parse it as above fir=
st, and consider it as SegWit v1 or higher if it was parsed correctly as ab=
ove.<br>
<br>
The above proposal is of course ridiculous and I am now currently running d=
iagnostics on my processing units to see if further glitches occur in test =
reasoning skills.<br>
<br>
Regards,<br>
ZmnSCPxj<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>
_______________________________________________<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>
--000000000000be2f110596d5f37c--
|
