From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gsanders87@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 83B6CC58 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 7 Nov 2019 22:45:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83EB6196 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 7 Nov 2019 22:45:16 +0000 (UTC) Received: by mail-ed1-f46.google.com with SMTP id p59so3407183edp.7 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 07 Nov 2019 14:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HarCHFfmMHUsFUBpylHQ+LNpOw4X0BHtFdnjaEmnCJk=; b=X1lUYRszxSVfCqdkf2kdJf+2+noma6IjjW7IX+wyJv8mAeBTyfModYWlkrIran13/7 yqy7I3Z+ON2Cb7ZHzB+T9mLTW/eIEBbPg7YweMxXNcmcRvILPcfqICOgan2ll3mNTd5B Va2Tr1JJ9CYY4dhFcB3o9LAib3sxqOyseJNPQcLXwFZYFM/e34coBlws06/alj5Byhys admr0eN14cmXb41DBWHOavlqFAv+IAzt6fEne8PFE4S978u/WhQfclkWcIDUbOVA8tgA SOF0/VpQyHdiR63QLUQZ0GepkyRNZGyw/vnpleOl64kUPayC0GxPCGnivS2KfrRhOJyi FJPA== 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=HarCHFfmMHUsFUBpylHQ+LNpOw4X0BHtFdnjaEmnCJk=; b=n+jRVsTTtuDYmiB/mGgaXQa1S9Im9xQGlTzBxzzPqy2wF63IIy6cvosvcPB+LmnfX0 245+ur/QerPMJCf8OJpI173flFwqFLDNxYTVJvxYoaezxHAIIxFTN2F3ryZ6Dh21AgdU TcbQO2HHgoTNyrjnfHZluRuuFphLh2Z0t4UJ6SdAlBYxaQTRQvKNw37ubjd5cbpqv/eB k0XbQIQwHaOmgPm8YxKrplTazCaIXGb1r9LuabELisLNFdwwIpoa1Q4jSckVZUHrM3Cq Gi7LAg3fPNS41Juqak5czz1zBXoxAYv3zsOBMm7izHesh3DNQUlaD+G+M92909HxrRNI qitQ== X-Gm-Message-State: APjAAAUO7/KiBhG4OLyhVrhpH8UZAypbGmqv3kten+JogsNAzysTYey2 0S3C06u2oLQ0Zss1lZrO0L6hu9YOMrOslCD/KyuV/A== X-Google-Smtp-Source: APXvYqzO3xPxQ0sV/7LNanTXsI4RgPx5ZRrVowr9U4PReP1nu6Kn7kSgxh+XyqM7dVlMJuZXtrxjEOuF0iC9/VGT4cA= X-Received: by 2002:a50:de0b:: with SMTP id z11mr6714129edk.33.1573166714622; Thu, 07 Nov 2019 14:45:14 -0800 (PST) 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" X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, 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 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: Thu, 07 Nov 2019 22:45:18 -0000 --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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">= bitcoin-dev@lists.linuxfoundation.org</a>> 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 "p", inserting or erasing "= q"s right<br> before that "p" 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'm sorry it wasn'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 "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">= 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--