From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 83B6CC58 for ; 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 ; Thu, 7 Nov 2019 22:45:16 +0000 (UTC) Received: by mail-ed1-f46.google.com with SMTP id p59so3407183edp.7 for ; 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: In-Reply-To: From: Greg Sanders Date: Thu, 7 Nov 2019 17:45:02 -0500 Message-ID: To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille vi= a 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<= br> 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.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000032982a0596c96bb6--