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"
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot
	addresses
Precedence: list

--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">&gt; a new human-readable-prefix for length prefixed bitco=
in witness programs.=C2=A0 &quot;btc1&quot; 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&#39;Connor via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; 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 &quot;btc1&quot; 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 &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; 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 &gt;=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--