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 &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--