MIME-Version: 1.0
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
In-Reply-To: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 7 Nov 2019 17:45:02 -0500
Message-ID: <CAB3F3DsbPyqUutBNbVcHME0kGWsbTzTtb5tWV+zRERHwpibXBw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000032982a0596c96bb6"
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot
	addresses
Precedence: list

--00000000000032982a0596c96bb6
Content-Type: text/plain; charset="UTF-8"

Could the softer touch of just making them non-standard apply as a future
preparation for an accepted softfork? Relaxations could easily be done
later if desired.

On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello all,
>
> 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.
>
> 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.
>
> 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-October/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.
>
> Thoughts?
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">Could the softer touch of just making them non-standard a=
pply as a future preparation for an accepted softfork? Relaxations could ea=
sily be done later if desired.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille vi=
a bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote c=
lass=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 nore=
ferrer" target=3D"_blank">https://github.com/sipa/bech32/issues/51</a> for =
details). Specifically,<br>
when a bech32 string ends with a &quot;p&quot;, inserting or erasing &quot;=
q&quot;s right<br>
before that &quot;p&quot; does not invalidate it. While insertion/erasure<b=
r>
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&#39;m sorry it wasn&#39;t<b=
r>
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 &quot;p&quot;s in a typo=
<br>
seems highly improbable.<br>
<br>
I&#39;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">=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427=
.html</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" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000032982a0596c96bb6--