path: root/e7/7e200285c3dfa87973dfd42e32b83e215ec203

Return-Path: <roconnor@blockstream.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B53AEC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 14:04:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 82D0460C06
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 14:04:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 82D0460C06
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com
 header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=EH4A08Yx
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id s_5EpKlqH22v
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 14:04:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F1290610EE
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com
 [IPv6:2607:f8b0:4864:20::42c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id F1290610EE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 14:04:29 +0000 (UTC)
Received: by mail-pf1-x42c.google.com with SMTP id b1so2533005pft.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 08 Feb 2023 06:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=RCJ31bSosX4RnlPdjVK96qn+3OcDqRndPtmiO/HUqVk=;
 b=EH4A08Yxoo/+Il9puDyVGLU2eJ4sMSORKuVVAgrLxbhDAcOSwlzbLHRqR3pZfBuEWJ
 ubGK7VoDfasvwsvT82gDn4eails4xtZ3lxbPPIZbNfu7WJYd+jtWAQbRaS178CE6cls2
 b9pAs365wSl7HFhSL+0l0SHRI5NdX/qW0qPE3hOYnhfEtfSepesQi8sTxXjs+yi3X3LQ
 hEGtjTENLNEmiPfT90du5N0z0Yp1wn+8lGe+ft/5m6CAztFsmPJrot+sFYacodNdK7Kh
 btyYXwYJArcIrl6MSH6IkhnIbOFzGgO9vxHSWDu0wpDxecPLNIYEl8fmRBw7L8gTg4Sa
 rSfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=RCJ31bSosX4RnlPdjVK96qn+3OcDqRndPtmiO/HUqVk=;
 b=3qVVerIrHeQVIlVzUY6AY3PIVFTw6iV5y8ED/NgRCOx9+QqLu/v59qG+VcwYHJfT/r
 AU68ONrrH2IHMHnINsdG6WErt0l9BULRn9aEHSgCmBF5wszPqxi41OYkFlAH8RX9a+AQ
 euynWAF8kTM90dUhc0Odg/g7MS7VQfRtJrtTAa88WYLWbxeNVAE6ijoxB+VB+MBMtiZb
 8dEF55ERum/vuw/lmErsjLNeAieNiHdtmF193JWbYJxxwqPtIjI/gWTQYU1fCWEc29tM
 fJG9ypUfgXN56pYrosRT4JdN+5FijwuJ+FcGe/pTxCGxrTWRu6eTcKZQXLAbQSGoTXWI
 A7dQ==
X-Gm-Message-State: AO0yUKUeiHQ+JpwX3D1pcQVEpmUgdbb0FFN6RJzOZdKLy0GLtl97CXie
 hMSNhdHhILkN+YGhNhLK2JxJV675UACdRQsTskRqmQrTUUxFsw==
X-Google-Smtp-Source: AK7set9PunsbpgE7giinSSnAtdRtAnZTfaaccXbB/MXFXf8/Fe3pFUsPMyg9I6XW3rdCTI52piVUNA6+2elP61kyPvI=
X-Received: by 2002:aa7:962f:0:b0:5a8:17a6:c573 with SMTP id
 r15-20020aa7962f000000b005a817a6c573mr810442pfg.25.1675865069246; Wed, 08 Feb
 2023 06:04:29 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
 <Y+JWLsc80gxL4kpG@camus> <Y+KUAlsPc8ohPecb@camus>
 <CAMZUoK=u2114uv0Uc0u_RVMBv-cq-gJiNxiyOk_T_xxTYO0Ghw@mail.gmail.com>
 <VWZ9Dc2gIe0Y02yY3qSbjQTEPqwCm6YAtRzfNrIANBXCEJzr73SdxZT4LwBKDyriDfmDZyTlkKWtoZmVIUbYqqZUAeTMDLHUNFCBwR6hitQ=@protonmail.com>
In-Reply-To: <VWZ9Dc2gIe0Y02yY3qSbjQTEPqwCm6YAtRzfNrIANBXCEJzr73SdxZT4LwBKDyriDfmDZyTlkKWtoZmVIUbYqqZUAeTMDLHUNFCBwR6hitQ=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 8 Feb 2023 09:04:16 -0500
Message-ID: <CAMZUoKkGCEZ+8zW_8WfE4=q2x+gcC4vR06gxTW3XwgpH5WGXSw@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000024f1cd05f430be64"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty
 protocols with Taproot inputs
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, 08 Feb 2023 14:04:31 -0000

--00000000000024f1cd05f430be64
Content-Type: text/plain; charset="UTF-8"

The fix for the bug is to sign the entire tapbranch instead of the tapleaf.

On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <michaelfolkson@protonmail.com>
wrote:

> Hi Andrew
>
> > There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
> >
> > The countermeasure is that you should always know the entire Taptree
> when interacting with someone's Tapspend.
>
> I wouldn't say it is a "bug" unless there is a remedy for the bug that
> wasn't (and retrospectively should have been) included in the Taproot
> design. In retrospect and assuming you could redesign the Taproot consensus
> rules again today would you prevent spending from a valid P2TR address if a
> repeated Tapleaf hash was used to prove that a spending path was embedded
> in a Taproot tree? That's the only thing I can think of to attempt to
> remedy this "bug" and it would only be a partial protection as proving a
> spending path exists within a Taproot tree only requires a subset of the
> Tapleaf hashes.
>
> I only point this out because there seems to be a push to find "bugs" and
> "accidental blowups" in the Taproot design currently. No problem with this
> if there are any, they should definitely be highlighted and discussed if
> they do exist. The nearest to a possible inferior design decision thus far
> that I'm aware of is x-only pubkeys in BIP340 [0].
>
> Thanks
> Michael
>
> [0]:
> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree when
> interacting with someone's Tapspend.
>
>
> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
>> wrote:
>> >
>> > <snip>
>> >
>> > [1] https://bitcoin.sipa.be/miniscript/
>> > [2] In Taproot, if you want to prevent signatures migrating to another
>> > branch or within a branch, you can use the CODESEPARATOR opcode
>> > which was redisegned in Taproot for exactly this purpose... we
>> > really did about witness malleation in its design!
>>
>> In Taproot the tapleaf hash is always covered by the signature (though
>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>> between tapbranches.
>>
>> I had thought this was the case, but then I re-confused myself by
>> reading BIP 341 .... which has much of the sighash specified, but not
>> all of it! The tapleaf hash is added in BIP 342.
>>
>> >
>> > If you want to prevent signatures from moving around *within* a
>> > branch,
>> >
>>
>> And this sentence I just meant to delete :)
>>
>>
>> --
>> Andrew Poelstra
>> Director of Research, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

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

<div dir=3D"auto"><div>The fix for the bug is to sign the entire tapbranch =
instead of the tapleaf.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Wed., Feb. 8, 2023, 04:35 Michael Folkson, &lt;<a h=
ref=3D"mailto:michaelfolkson@protonmail.com">michaelfolkson@protonmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"font-f=
amily:Arial;font-size:14px"><span style=3D"line-height:1.5;font-family:syst=
em-ui,sans-serif">Hi Andrew</span></div><div style=3D"font-family:Arial;fon=
t-size:14px"><span style=3D"line-height:1.5;font-family:system-ui,sans-seri=
f"><br></span></div><div style=3D"font-family:Arial;font-size:14px"><span s=
tyle=3D"line-height:1.5;font-family:system-ui,sans-serif">&gt; There is a b=
ug in Taproot that allows the same Tapleaf to be repeated multiple times in=
 the same Taproot, potentially at different Taplevels incurring different T=
apfee rates.</span><div style=3D"line-height:1.5;font-family:system-ui,sans=
-serif">&gt;</div><span style=3D"line-height:1.5;font-family:system-ui,sans=
-serif">&gt; The countermeasure is that you should always know the entire T=
aptree when interacting with someone&#39;s Tapspend.</span><br></div><div s=
tyle=3D"font-family:Arial;font-size:14px"><span style=3D"line-height:1.5;fo=
nt-family:system-ui,sans-serif"><br></span></div><div style=3D"font-size:14=
px">I wouldn&#39;t say it is a &quot;bug&quot; unless there is a remedy for=
 the bug that wasn&#39;t (and retrospectively should have been) included in=
 the Taproot design. In retrospect and assuming you could redesign the Tapr=
oot consensus rules again today would you prevent spending from a valid P2T=
R address if a repeated Tapleaf hash was used to prove that a spending path=
 was embedded in a Taproot tree? That&#39;s the only thing I can think of t=
o attempt to remedy this &quot;bug&quot; and it would only be a partial pro=
tection as proving a spending path exists within a Taproot tree only requir=
es a subset of the Tapleaf hashes.</div><div style=3D"font-size:14px"><br><=
/div><div style=3D"font-size:14px">I only point this out because there seem=
s to be a push to find &quot;bugs&quot; and &quot;accidental blowups&quot; =
in the Taproot design currently. No problem with this if there are any, the=
y should definitely be highlighted and discussed if they do exist. The near=
est to a possible inferior design decision thus far that I&#39;m aware of i=
s x-only pubkeys in BIP340 [0].=C2=A0</div><div style=3D"font-size:14px"><b=
r></div><div style=3D"font-size:14px">Thanks</div><div style=3D"font-size:1=
4px">Michael</div><div style=3D"font-size:14px"><br></div><div style=3D"fon=
t-size:14px">[0]:=C2=A0<span><a rel=3D"noreferrer nofollow noopener norefer=
rer" href=3D"https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-=
ruffing-musig2/#a-retrospective-look-at-bip340" target=3D"_blank">https://b=
tctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retr=
ospective-look-at-bip340</a></span></div><div style=3D"font-family:Arial;fo=
nt-size:14px"><br></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:&#39;SFMono-Regular&#39;,Consolas,&#39;Liberation Mono&#39;,Menlo,=
monospace,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<b=
r>Email: michaelfolkson at </span></span></span><a href=3D"http://protonmai=
l.com/" style=3D"line-height:normal;text-decoration:underline;font-family:&=
#39;SFMono-Regular&#39;,Consolas,&#39;Liberation Mono&#39;,Menlo,monospace,=
monospace;font-size:14px;font-style:normal;font-weight:400;letter-spacing:n=
ormal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing=
:0px" rel=3D"noopener noreferrer noreferrer" target=3D"_blank">protonmail.c=
om</a><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;=
letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-w=
rap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:i=
nline"><span style=3D"font-family:&#39;SFMono-Regular&#39;,Consolas,&#39;Li=
beration Mono&#39;,Menlo,monospace,monospace"><span style=3D"font-size:14px=
"> </span></span></span><br></div><div style=3D"font-family:arial;font-size=
:14px"><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400=
;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-=
wrap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:=
inline"><span style=3D"font-family:&#39;SFMono-Regular&#39;,Consolas,&#39;L=
iberation Mono&#39;,Menlo,monospace,monospace"><span style=3D"font-size:14p=
x">Keybase: michaelfolkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 =
214C FEE3</span></span></span><br></div>
    </div>
   =20
            <div>
       =20
            </div>
</div>
<div style=3D"font-family:Arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Tuesday, February 7th, 2023 at 18:35, Russell O&#39;Connor via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>There is a bug in Taproot that allows the=
 same Tapleaf to be repeated multiple times in the same Taproot, potentiall=
y at different Taplevels incurring different Tapfee rates.</div><div><br></=
div><div>The countermeasure is that you should always know the entire Taptr=
ee when interacting with someone&#39;s Tapspend.<br></div><div dir=3D"ltr">=
<br></div><br><div class=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"l=
tr">On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer nofo=
llow noopener noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_q=
uote"><br>
Some people highlighted some minor problems with my last email:<br>
<br>
On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev w=
rote:<br>
&gt; <br>
&gt; &lt;snip&gt; <br>
&gt; <br>
&gt; [1] <a rel=3D"noreferrer nofollow noopener noreferrer" href=3D"https:/=
/bitcoin.sipa.be/miniscript/" target=3D"_blank">https://bitcoin.sipa.be/min=
iscript/</a><br>
&gt; [2] In Taproot, if you want to prevent signatures migrating to another=
<br>
&gt;     branch or within a branch, you can use the CODESEPARATOR opcode<br=
>
&gt;     which was redisegned in Taproot for exactly this purpose... we<br>
&gt;     really did about witness malleation in its design!<br>
<br>
In Taproot the tapleaf hash is always covered by the signature (though<br>
not in some ANYONECANPAY proposals) so you can never migrate signatures<br>
between tapbranches.<br>
<br>
I had thought this was the case, but then I re-confused myself by<br>
reading BIP 341 .... which has much of the sighash specified, but not<br>
all of it! The tapleaf hash is added in BIP 342.<br>
<br>
&gt; <br>
&gt;     If you want to prevent signatures from moving around *within* a<br=
>
&gt;     branch,<br>
&gt;<br>
<br>
And this sentence I just meant to delete :)<br>
<br>
<br>
-- <br>
Andrew Poelstra<br>
Director of Research, Blockstream<br>
Email: apoelstra at <a rel=3D"noreferrer nofollow noopener noreferrer" href=
=3D"http://wpsoftware.net" target=3D"_blank">wpsoftware.net</a><br>
Web:   <a rel=3D"noreferrer nofollow noopener noreferrer" href=3D"https://w=
ww.wpsoftware.net/andrew" target=3D"_blank">https://www.wpsoftware.net/andr=
ew</a><br>
<br>
The sun is always shining in space<br>
    -Justin Lewis-Webster<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
nofollow noopener noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a><br>
<a rel=3D"noreferrer nofollow noopener noreferrer" href=3D"https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://l=
ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

        </blockquote><br>
    </div></blockquote></div></div></div>

--00000000000024f1cd05f430be64--