path: root/64/d6a7662ec4fb40555558fdf67275ba18d7c2d3

Return-Path: <roconnor@blockstream.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 42636C0733
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jul 2020 21:11:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 3191989536
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jul 2020 21:11:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3x5y5emCrsvf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jul 2020 21:11:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com
 [209.85.166.41])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 347B1892A0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jul 2020 21:11:23 +0000 (UTC)
Received: by mail-io1-f41.google.com with SMTP id v8so3824764iox.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jul 2020 14:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=0aSOR9w7wvER196U4iDaJg2wH6t/0elh+Pu/mb2kBQA=;
 b=m862lFKk5pW7FsM1ElphBQqYGypLQaQ9fsr9O6+BKaeU0AZcSJe4a7xV4YzoPtVFFC
 kDlvz00xJn58jbMGncwBa3XOtLZP3gy86RK/xEwJFwBfBWKdccbUspsLyZ9nU7ciC8+s
 0W+sdyZkdgzgS1TxGjlDKu0EfUMIjtpL/GzjFuG6cK71yGd60JMtCzau6Hrv1W9lC1Pv
 DhVb3XvlkF0DtdCF+UBVGDLcl5Kev3jPNDSP8O00/xand871dUQDGhwNj/3I1K9R57IV
 ASGEPGFF0X8DFxG4ronXIJuO8pLqUguXpDifwisEeaXAqiB9JTfZTcFju97aTjLbdBM4
 QJHg==
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:cc;
 bh=0aSOR9w7wvER196U4iDaJg2wH6t/0elh+Pu/mb2kBQA=;
 b=AMEMVf8w7zxv4UdgW6YIsOANTVflovAhQOmAIpRsIldIFCbZWalwrk/SZlAnktIZ/U
 +3BkR3t7j7LuGShRFqpR+6wqn8RQGWafnLzRYEwShRrOTr4f67uQSPXXbfa9jCatdUJB
 WZ29bi5FRirtUPNQ7u2GNXJwY+8vwRILNBd5GKiq85WQmY1yk2dxRBf5yiY3c+7q5ZNB
 0ONy5plgJDQIncuQ+XUu1kxtGxKmD9E4qyn6HRiGT0pWhuixFGIh16efBYxNeSC8ubWO
 xVfoHClZoiTBEbwU1b4OCMdNI8ZNTlZbL2/WLWJA+miAaDNyLYhH7rj17Dq7ySgbxEBr
 7dYQ==
X-Gm-Message-State: AOAM5305TCiXUbcsIeLAe2xcg7GnLVYLENHCfjfQS6ewkCFPoQGZbnwo
 Ip/ViZ6atLXRIM2k5NDn8lW0okejrFaeTZLElaDhiw==
X-Google-Smtp-Source: ABdhPJzxjs4Mzg5+5o3VzstAyfXvq4vgrYzzw7PzAwIAuD254uWAkgFmF3nkuvk3SiaZRPzm7Jejq1IVl4BMKscZvDQ=
X-Received: by 2002:a5d:8c8f:: with SMTP id g15mr1239018ion.206.1594847482342; 
 Wed, 15 Jul 2020 14:11:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
 <20191108021541.n3jk54vucplryrbl@ganymede>
 <CAPg+sBgus6HgYPVbXaAx51nO2ArsR3-6=obe2AwkO8kh11fB6Q@mail.gmail.com>
 <611b4e5b-e7cf-adc7-31e1-b5ff24b6574b@mattcorallo.com>
 <CAHGSxGv_BQAAkdcxsqVsjphqaoE=Xm05jXhdBnGw+m+vRxeQYQ@mail.gmail.com>
 <2sU6YozN9nn30cofkAMhffgjDLZwjG3mvF0nBgOsVQQEY9ROmP72GuHWjnBlF_qa8eeQPU8bxleZqcvRGJgS-uJ2xWYmAm9HjrFWWx_9o8k=@protonmail.com>
 <CAPg+sBio_8vT9NNp39rz7m+omfaRs0Mf6JkET1=caoVwvziJSA@mail.gmail.com>
 <CAMZUoKn4OmyGOMBH==2Fx2N7GYbw2RbYK98pxu_pD5QTmDw9KQ@mail.gmail.com>
 <CAB3F3Dv4evEZ_b7Z3Vc+wFCvD8UMOvJdFGyOAajrHpEUqz+g=g@mail.gmail.com>
In-Reply-To: <CAB3F3Dv4evEZ_b7Z3Vc+wFCvD8UMOvJdFGyOAajrHpEUqz+g=g@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 15 Jul 2020 17:11:11 -0400
Message-ID: <CAMZUoK=kjUrU_oPKVQ2QMufiXPwZBBgis01MpgyUP2nCZnp28Q@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a808e705aa815d70"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot
	addresses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Wed, 15 Jul 2020 21:11:24 -0000

--000000000000a808e705aa815d70
Content-Type: text/plain; charset="UTF-8"

The bold values are the witness program lengths and address lengths of the
segwit v0 programs (BIP-141), which clearly need to be covered in my
proposed amendment.  32 bytes is also the proposed witness program length
for segwit v1 that would correspond to a taproot (BIP-341) program.

On Wed, Jul 15, 2020 at 5:05 PM Greg Sanders <gsanders87@gmail.com> wrote:

> Can you make it clear what the bold vs not-bold numbers mean?
>
> On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> That brings me to Matt's point: there is no need to do this right now.
>>> We can simply amend BIP173 to only permit length 20 and length 32 (and only
>>> length 20 for v0, if you like; but they're so far apart that permitting
>>> both shouldn't hurt), for now. Introducing the "new" address format (the
>>> one using an improved checksum algorithm) only needs to be there in time
>>> for when a non-32-byte-witness-program would come in sight.
>>>
>>
>> As a prerequisite to taproot activation, I was looking into amending
>> BIP173 as stated above.  However after reviewing
>> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
>> it seems that insertions of 5 characters or more is "safe" in the sense
>> that there is low probability of creating a valid checksum by doing so
>> randomly.
>>
>> This means we could safely allow witness programs of lengths *20*, 23,
>> 26, 29, *32*, 36, and 40 (or 39).  These correspond to Bech32 addresses
>> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73).  We could also
>> support a set of shorter addresses, but given the lack of entropy in such
>> short addresses, it is hard to believe that such witness programs could be
>> used to secure anything.  I'm not sure what the motivation for allowing
>> such short witness programs was, but I'm somewhat inclined to exclude them
>> from the segwit address format.
>>
>> Given that we would only be able to support one of 39 or 40 byte witness
>> programs, it is sensible to choose to allow 40 byte witness programs to be
>> addressable.  This is the maximum witness program size allowed by BIP 141.
>>
>> So my proposal would be to amend BIP173 in such a way to restrict "bc"
>> and "tb" segwit address formats to require witness programs be of size
>> *20*, 23, 26, 29, *32*, 36, or 40.  Witness programs of other sizes
>> (between 2 and 40) would, of course, still be legal in accordance with BIP
>> 141; however they would be unaddressable by using this "bc" and "tb"
>> prefix.  Another address format would be needed to support other witness
>> sizes, should the need ever arise.
>>
>> --
>> Russell O'Connor
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--000000000000a808e705aa815d70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The bold values are the witness program lengths and addres=
s lengths of the segwit v0 programs (BIP-141), which clearly need to be cov=
ered in my proposed amendment.=C2=A0 32 bytes is also the proposed witness =
program length for segwit v1 that would correspond to a taproot (BIP-341) p=
rogram.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Wed, Jul 15, 2020 at 5:05 PM Greg Sanders &lt;<a href=3D"mail=
to:gsanders87@gmail.com">gsanders87@gmail.com</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Can you make =
it clear what the bold vs not-bold numbers mean?</div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 15, 2020 at 4:5=
6 PM Russell O&#39;Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><br><div dir=
=3D"auto">That brings me to Matt&#39;s point: there is no need to do this r=
ight now. We can simply amend BIP173 to only permit length 20 and length 32=
 (and only length 20 for v0, if you like; but they&#39;re so far apart that=
 permitting both shouldn&#39;t hurt), for now. Introducing the &quot;new&qu=
ot; address format (the one using an improved checksum algorithm) only need=
s to be there in time for when a non-32-byte-witness-program would come in =
sight.</div></div></blockquote><div><br></div><div>As a prerequisite to tap=
root activation, I was looking into amending BIP173 as stated above.=C2=A0 =
However after reviewing <a href=3D"https://gist.github.com/sipa/a9845b37c1b=
298a7301c33a04090b2eb#detection-of-insertion-errors" target=3D"_blank">http=
s://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-inse=
rtion-errors</a> it seems that insertions of 5 characters or more is &quot;=
safe&quot; in the sense that there is low probability of creating a valid c=
hecksum by doing so randomly.</div><div><br></div><div>This means we could =
safely allow witness programs of lengths <b>20</b>, 23, 26, 29, <b>32</b>, =
36, and 40 (or 39).=C2=A0 These correspond to Bech32 addresses of length <b=
>42</b>, 47, 52, 57, <b>62</b>, 68, and 74 (or 73).=C2=A0 We could also sup=
port a set of shorter addresses, but given the lack of entropy in such shor=
t addresses, it is hard to believe that such witness programs could be used=
 to secure anything.=C2=A0 I&#39;m not sure what the motivation for allowin=
g such short witness programs was, but I&#39;m somewhat inclined to exclude=
 them from the segwit address format.<br></div><div><br></div><div>Given th=
at we would only be able to support one of 39 or 40 byte witness programs, =
it is sensible to choose to allow 40 byte witness programs to be addressabl=
e.=C2=A0 This is the maximum witness program size allowed by BIP 141.</div>=
<div><br></div><div>So my proposal would be to amend BIP173 in such a way t=
o restrict &quot;bc&quot; and &quot;tb&quot; segwit address formats to requ=
ire witness programs be of size <b>20</b>, 23, 26, 29, <b>32</b>, 36, or 40=
.=C2=A0 Witness programs of other sizes (between 2 and 40) would, of course=
, still be legal in accordance with BIP 141; however they would be unaddres=
sable by using this &quot;bc&quot; and &quot;tb&quot; prefix.=C2=A0 Another=
 address format would be needed to support other witness sizes, should the =
need ever arise.<br></div><div><br></div><div>-- <br></div><div>Russell O&#=
39;Connor<br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000a808e705aa815d70--