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 31EB0C002B for ; Sat, 11 Feb 2023 14:40:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0CCD160A65 for ; Sat, 11 Feb 2023 14:40:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0CCD160A65 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=4nWQuI1+ 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 m64Ldmf1IDuL for ; Sat, 11 Feb 2023 14:40:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 64127607FE Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by smtp3.osuosl.org (Postfix) with ESMTPS id 64127607FE for ; Sat, 11 Feb 2023 14:40:50 +0000 (UTC) Received: by mail-pj1-x102c.google.com with SMTP id d2so8108189pjd.5 for ; Sat, 11 Feb 2023 06:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=k1X9tqw8ZVByp/bLohl/a7IMqwnBRtXPL+1+8cB7L7M=; b=4nWQuI1+rdcVw7dXR+ushi2mXHQhs0cIldVTdWekHr6Tzq3cW6oPmPvh9eSYlpTpg7 inicIS6agTURifZDrhpE/S/JL/xCyy/G2BnMWngyLKTjA47Njbeqmhcjm/ImLDZPHcxb lcNkyupEdnXjoZTi1iYNCzQWkW1bZvN8+sG2IpZWybr/O/+aZFA2//5jK7IO0/cu7O9d dHjy1jTFnfodyLQ3O6/jekS1FJuqXyJcwtGIrbhZWQU/TNGhnVakhTkLu8kEa516I5nx 9ykxiXEUchTOM9fBsfBoFBL6em+V4VOU3TPER9xxMKvQHohjArjf1llxJ/nmDDGoe2Ix crpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=k1X9tqw8ZVByp/bLohl/a7IMqwnBRtXPL+1+8cB7L7M=; b=vp3qBcz3uNr0O+HCBm85UzM4/XdTaBAOBKe/gIEB9TyvmbSPVmL/OVsHqahZ5vHO2t PafabzP9vl42x+5Bj2V8NgozWtvusO86LV6KDt1JzvO6JYfcZCvbAg4GHEJC0uDyUUzE flmzzOHRfnxD/3QaFg1aYDAatKEhiPBRcwM9hqNwei8fAqX8/Dm7ItYRjNdJqf3BopiI 71z9R0xlJxcYZrMhiOo2ltRD60W2cwH2BcLcSd3WY6nhL3mi0P2dCSwzHKLKTyJXi3uX YZVwMzYUjR0v99vAMlv6J5dvCSM5nu/CtzVZUidjWUQ0PFKmoZfBWt86gq6A9l2SmtbM NYSA== X-Gm-Message-State: AO0yUKUgFLoMe/IZDhmrazceBUYIJkr4cwkqgGkUqRTenpMrKQJ31mJa 35SWVIBwa6M6LWVl3wA2LSE2Y/elXoyZ7Ay7byOuNi8eFX5OhA== X-Google-Smtp-Source: AK7set/OBMVfmIq+oPnsmAlvyb3/G2Y6UA1A7FhTmP9IqsfXO1WU3ehl7TrsBetgNgtcQSfdpwNHH5sZO516/puuASo= X-Received: by 2002:a17:90a:194:b0:233:c20c:7d67 with SMTP id 20-20020a17090a019400b00233c20c7d67mr545171pjc.37.1676126449610; Sat, 11 Feb 2023 06:40:49 -0800 (PST) MIME-Version: 1.0 References: <6C1009F7-A90A-4B7D-8ED3-C0E9399873B6@erisian.com.au> In-Reply-To: <6C1009F7-A90A-4B7D-8ED3-C0E9399873B6@erisian.com.au> From: "Russell O'Connor" Date: Sat, 11 Feb 2023 09:40:38 -0500 Message-ID: To: Anthony Towns , "Russell O'Connor via bitcoin-dev" Content-Type: multipart/alternative; boundary="000000000000a0d2d805f46d994f" 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: Sat, 11 Feb 2023 14:40:52 -0000 --000000000000a0d2d805f46d994f Content-Type: text/plain; charset="UTF-8" Yes. If you would otherwise sign the tapleaf, then I would recommend also signing the entire tapbranch. On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns wrote: > On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >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: > >>> > > >>> > > >>> > > >>> > [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 > >>> > >> > >> > > Is this something that should be fixed in bip118 signatures then? > > Cheers, > aj > -- > Sent from my phone. > --000000000000a0d2d805f46d994f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes.=C2=A0 If you would otherwise sign the tapleaf, t= hen I would recommend also signing the entire tapbranch.



On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns <aj@erisian.com.au> wrote:
On 9 February 2023 12:04:16 = am AEST, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
>The fix for the bug is to sign the entire tapbranch instead of the tapl= eaf.
>
>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 Taple= vels
>> 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 remed= y 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 add= ress if a
>> repeated Tapleaf hash was used to prove that a spending path was e= mbedded
>> in a Taproot tree? That's the only thing I can think of to att= empt to
>> remedy this "bug" and it would only be a partial protect= ion 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 &qu= ot;bugs" and
>> "accidental blowups" in the Taproot design currently. No= problem with this
>> if there are any, they should definitely be highlighted and discus= sed 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 repea= ted
>> multiple times in the same Taproot, potentially at different Taple= vels
>> 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.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 migrati= ng 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 s= ignatures
>>> 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 *wit= hin* 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.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>

Is this something that should be fixed in bip118 signatures then?

Cheers,
aj
--
Sent from my phone.
--000000000000a0d2d805f46d994f--