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">&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--