diff options
author | Russell O'Connor <roconnor@blockstream.com> | 2023-02-08 09:04:16 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2023-02-08 14:04:31 +0000 |
commit | d403cd578b3975cad28be2cd6862eebfea4307da (patch) | |
tree | c7a213fa77a3efd806af0f88e9aec92eb843c1d2 | |
parent | 2a40e77d4b6831a29158521775c6ee0bbf42156b (diff) | |
download | pi-bitcoindev-d403cd578b3975cad28be2cd6862eebfea4307da.tar.gz pi-bitcoindev-d403cd578b3975cad28be2cd6862eebfea4307da.zip |
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
-rw-r--r-- | e7/7e200285c3dfa87973dfd42e32b83e215ec203 | 359 |
1 files changed, 359 insertions, 0 deletions
diff --git a/e7/7e200285c3dfa87973dfd42e32b83e215ec203 b/e7/7e200285c3dfa87973dfd42e32b83e215ec203 new file mode 100644 index 000000000..08d5ac3f3 --- /dev/null +++ b/e7/7e200285c3dfa87973dfd42e32b83e215ec203 @@ -0,0 +1,359 @@ +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, <<a h= +ref=3D"mailto:michaelfolkson@protonmail.com">michaelfolkson@protonmail.com<= +/a>> 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">> 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">></div><span style=3D"line-height:1.5;font-family:system-ui,sans= +-serif">> The countermeasure is that you should always know the entire T= +aptree when interacting with someone'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'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 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's the only thing I can think of t= +o attempt to remedy this "bug" 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 "bugs" and "accidental blowups" = +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'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:'SFMono-Regular',Consolas,'Liberation Mono',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',Consolas,'Liberation Mono',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:'SFMono-Regular',Consolas,'Li= +beration Mono',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:'SFMono-Regular',Consolas,'L= +iberation Mono',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'Connor via b= +itcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar= +get=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>= +> 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'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 <<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>> 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> +> <br> +> <snip> <br> +> <br> +> [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> +> [2] In Taproot, if you want to prevent signatures migrating to another= +<br> +> branch or within a branch, you can use the CODESEPARATOR opcode<br= +> +> which was redisegned in Taproot for exactly this purpose... we<br> +> 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> +> <br> +> If you want to prevent signatures from moving around *within* a<br= +> +> branch,<br> +><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-- + |