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 40342A7A for ; 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 ; 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 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: In-Reply-To: To: Greg Sanders , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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.

Matt

On Nov 7, 2019, at 17:47, Greg Sanders via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:

=EF=BB=BF
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.

On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.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 de= tails). 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 (ht= tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427.ht= ml)
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
_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-7011B442-0553-4393-B996-81225F7D5C4E--