From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B53AEC002B for ; 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 ; 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 ; 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 ; Wed, 8 Feb 2023 14:04:29 +0000 (UTC) Received: by mail-pf1-x42c.google.com with SMTP id b1so2533005pft.1 for ; 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: In-Reply-To: From: "Russell O'Connor" Date: Wed, 8 Feb 2023 09:04:16 -0500 Message-ID: To: Michael Folkson Content-Type: multipart/alternative; boundary="00000000000024f1cd05f430be64" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, 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: >> > >> > >> > >> > [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
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<= /a>> wrote:



<= /div>
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
Thanks
Michael


--
Michael FolksonEmail: michaelfolkson at protonmail.c= om
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 = 214C FEE3
=20
=20

------- Original Message -------
On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via b= itcoin-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, potentiall= y at different Taplevels incurring different Tapfee rates.

The countermeasure is that you should always know the entire Taptr= ee when interacting with someone's Tapspend.
=

On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.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 w= rote:
>
> <snip>
>
> [1] https://bitcoin.sipa.be/min= iscript/
> [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/andr= ew

The sun is always shining in space
-Justin Lewis-Webster

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoun= dation.org
https://l= ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--00000000000024f1cd05f430be64--