From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 40342A7A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 00:41:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75E15710
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 00:41:56 +0000 (UTC)
Received: from [IPv6:2620:6e:a000:1000:dc76:997a:6e6b:8675] (unknown
	[IPv6:2620:6e:a000:1000:dc76:997a:6e6b:8675])
	by mail.as397444.net (Postfix) with ESMTPSA id ABE26FE1D2;
	Fri,  8 Nov 2019 00:41:54 +0000 (UTC)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 7 Nov 2019 19:41:54 -0500
Message-Id: <701F6185-EB2C-4EB1-AAAA-1133879CF541@mattcorallo.com>
References: <CAB3F3DsbPyqUutBNbVcHME0kGWsbTzTtb5tWV+zRERHwpibXBw@mail.gmail.com>
In-Reply-To: <CAB3F3DsbPyqUutBNbVcHME0kGWsbTzTtb5tWV+zRERHwpibXBw@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17B84)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MIME_QP_LONG_LINE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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 00:41:57 -0000


--Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Given the issue is in the address format, not the consensus/standardness lay=
er, it does seem somewhat strange to jump to addressing it with a consensus/=
standardness fix. Maybe the ship has sailed, but for the sake of considering=
 all our options, we could also redefine bech32 to not allow such addresses.=


Matt

>> On Nov 7, 2019, at 17:47, Greg Sanders via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
> =EF=BB=BF
> Could the softer touch of just making them non-standard apply as a future p=
reparation for an accepted softfork? Relaxations could easily be done later i=
f desired.
>=20
>>> On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>> Hello all,
>>=20
>> A while ago it was discovered that bech32 has a mutation weakness (see
>> https://github.com/sipa/bech32/issues/51 for details). Specifically,
>> when a bech32 string ends with a "p", inserting or erasing "q"s right
>> before that "p" does not invalidate it. While insertion/erasure
>> robustness was not an explicit goal (BCH codes in general only have
>> guarantees about substitution errors), this is very much not by
>> design, and this specific issue could have been made much less
>> impactful with a slightly different approach. I'm sorry it wasn't
>> caught earlier.
>>=20
>> This has little effect on the security of P2WPKH/P2WSH addresses, as
>> those are only valid (per BIP173) for specific lengths (42 and 62
>> characters respectively). Inserting 20 consecutive "p"s in a typo
>> seems highly improbable.
>>=20
>> I'm making this post because this property may unfortunately influence
>> design decisions around bip-taproot, as was brought up in the review
>> session (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Oct=
ober/017427.html)
>> past tuesday. In the current draft, witness v1 outputs of length other
>> than 32 remain unencumbered, which means that for now such an
>> insertion or erasure would result in an output that can be spent by
>> anyone. If that is considered unacceptable, it could be prevented by
>> for example outlawing v1 witness outputs of length 31 and 33.
>>=20
>> Thoughts?
>>=20
>> Cheers,
>>=20
>> --=20
>> Pieter
>> _______________________________________________
>> 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

--Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><div dir=3D"ltr">Given the=
 issue is in the address format, not the consensus/standardness layer, it do=
es seem somewhat strange to jump to addressing it with a consensus/standardn=
ess fix. Maybe the ship has sailed, but for the sake of considering all our o=
ptions, we could also redefine bech32 to not allow such addresses.</div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">Matt</div><div dir=3D"ltr"><br><bloc=
kquote type=3D"cite">On Nov 7, 2019, at 17:47, Greg Sanders via bitcoin-dev &=
lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<br><br></blockquote></di=
v><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">Coul=
d the softer touch of just making them non-standard apply as a future prepar=
ation for an accepted softfork? Relaxations could easily be done later if de=
sired.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br=
>
<br>
A while ago it was discovered that bech32 has a mutation weakness (see<br>
<a href=3D"https://github.com/sipa/bech32/issues/51" rel=3D"noreferrer noref=
errer" target=3D"_blank">https://github.com/sipa/bech32/issues/51</a> for de=
tails). Specifically,<br>
when a bech32 string ends with a "p", inserting or erasing "q"s right<br>
before that "p" does not invalidate it. While insertion/erasure<br>
robustness was not an explicit goal (BCH codes in general only have<br>
guarantees about substitution errors), this is very much not by<br>
design, and this specific issue could have been made much less<br>
impactful with a slightly different approach. I'm sorry it wasn't<br>
caught earlier.<br>
<br>
This has little effect on the security of P2WPKH/P2WSH addresses, as<br>
those are only valid (per BIP173) for specific lengths (42 and 62<br>
characters respectively). Inserting 20 consecutive "p"s in a typo<br>
seems highly improbable.<br>
<br>
I'm making this post because this property may unfortunately influence<br>
design decisions around bip-taproot, as was brought up in the review<br>
session (<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2019-October/017427.html" rel=3D"noreferrer noreferrer" target=3D"_blank">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427.ht=
ml</a>)<br>
past tuesday. In the current draft, witness v1 outputs of length other<br>
than 32 remain unencumbered, which means that for now such an<br>
insertion or erasure would result in an output that can be spent by<br>
anyone. If that is considered unacceptable, it could be prevented by<br>
for example outlawing v1 witness outputs of length 31 and 33.<br>
<br>
Thoughts?<br>
<br>
Cheers,<br>
<br>
-- <br>
Pieter<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" r=
el=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></div></body></html>=

--Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E--