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> 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 <<a href=3D= "mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda= tion.org</a>> 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--