path: root/f6/1758bffa74d7cfe2d8f2b3c3224e371964a69e

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A1CBAC8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 13:04:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com
	[209.85.166.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D386FEC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 13:04:05 +0000 (UTC)
Received: by mail-io1-f50.google.com with SMTP id j13so6309678ioe.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 08 Nov 2019 05:04:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream.io; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=+Lvj0e0F6eQ/6GBX7vb453YGJ8lPH3nN/taBPqvvpzw=;
	b=rFSgXMB9PFE1uzRsgARKrT2KRr2LjLoGb/Lz8s9Xle32b1t1zaHjutA33Lyw45ArlQ
	h8uu43v9+gTWWJ/o0kuyKp5Bmp9szX3nDzBuC5XY3lN8gpQsJn87C0OsoYi2N9nLbBGG
	hQlzqE+TGUHvAarsfetyrDLTQaLdXuIkmQuto=
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=+Lvj0e0F6eQ/6GBX7vb453YGJ8lPH3nN/taBPqvvpzw=;
	b=ipWNfRQHAEQDQU2nk+1TsComMaZpqVUMBfYicSg6ScJHs2uBDyZ7gaSlDDm4Rg3R8/
	+3V27nVBUpjN/j1DqjE65Dr5G2H5SU9vkuLYDFrJh6Zgs+PBD4fdnJVoELUmOIpehFyW
	qgvfn5dJHZscLMvY0xBQUO6Z4w/jyCU1se2r7632HpQQb+riDW1CgkboGe/ey+IJhGdd
	OTnyL1JTPx17WsFwSEjI8FRJL1xZHPgPF4QKc/dDd25jHFMfZf3mNRkZ8sSh9x+/ub8t
	qVCdinYWBE4D9mKEOTc4beBsSa7gJBeOo8nmj6BOr4exZ9zxwElfL1V4D8jh5wP5vlHO
	bAYQ==
X-Gm-Message-State: APjAAAXlApLLo0juEmWOTzoQStHzAoM5CTT0ZkUN6zuHlsVpoQ8PM2KQ
	Ot8ziyhSpjbmJiRe7/6l+rI4azPqnUvIWbrNshAWvngZ
X-Google-Smtp-Source: APXvYqzNz1A/MosWVqMPWtw34o1zKDI4feKfqE/DvDU/pPoLiQf+aBNZc4+ZxBFDafSi6l1ZfYlOWNZoSEvQqJt5iWY=
X-Received: by 2002:a5e:d813:: with SMTP id l19mr9790206iok.74.1573218244647; 
	Fri, 08 Nov 2019 05:04:04 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
	<sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com>
In-Reply-To: <sZtrFEIbPoH5v6IpNboec9kgSui-E8QLHllL3u3TgB42iRU3zkzi6cJuGTqUp1-9MMp0kURGuMRCmBv9AC6e9RPmMZpGVSAr0-HSRfyfhzM=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 8 Nov 2019 08:03:52 -0500
Message-ID: <CAMZUoK=QFPAzZzxFOA6ZYez_dwCTi_OxYup19w32suDvBdXJoQ@mail.gmail.com>
To: ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a081360596d56a4e"
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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
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.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:04:06 -0000

--000000000000a081360596d56a4e
Content-Type: text/plain; charset="UTF-8"

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
>

--000000000000a081360596d56a4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I do like the idea of length prefixing the witness pr=
ogram.=C2=A0 I will note that the 1 byte witness version is really more lik=
e a 1 character witness version.=C2=A0 There are 17 different segwit versio=
ns and there are 32 characters in the bech32 alphabet.=C2=A0 That leaves 15=
 unused characters that we can use for assigning new meanings too.</div><di=
v><br></div><div>That said, it is probably most sensible to define a new hu=
man-readable-prefix for length prefixed bitcoin witness programs.=C2=A0 &qu=
ot;btc1&quot; anyone?<br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-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 rgb(2=
04,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>

--000000000000a081360596d56a4e--