path: root/8d/85f06ea43384d6b3b0d8295f90c8c7ac2f4167

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4ADB7C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Feb 2023 05:15:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1440A40239
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Feb 2023 05:15:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1440A40239
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BK-AOG8KQjuZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Feb 2023 05:15:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B9BDB400C8
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp2.osuosl.org (Postfix) with ESMTPS id B9BDB400C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Feb 2023 05:15:06 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=[127.0.0.1])
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1pQiE1-0004XV-8W; Sat, 11 Feb 2023 15:15:01 +1000
Date: Sat, 11 Feb 2023 15:14:55 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
 Michael Folkson <michaelfolkson@protonmail.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAMZUoKkGCEZ+8zW_8WfE4=q2x+gcC4vR06gxTW3XwgpH5WGXSw@mail.gmail.com>
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>
 <CAMZUoKkGCEZ+8zW_8WfE4=q2x+gcC4vR06gxTW3XwgpH5WGXSw@mail.gmail.com>
Message-ID: <6C1009F7-A90A-4B7D-8ED3-C0E9399873B6@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Sat, 11 Feb 2023 05:15:08 -0000

On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <bitc=
oin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>The fix for the bug is to sign the entire tapbranch instead of the taplea=
f=2E
>
>On Wed=2E, Feb=2E 8, 2023, 04:35 Michael Folkson, <michaelfolkson@protonm=
ail=2Ecom>
>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=2E
>> >
>> > The countermeasure is that you should always know the entire Taptree
>> when interacting with someone's Tapspend=2E
>>
>> 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=2E In retrospect and assuming you could redesign the Taproot con=
sensus
>> 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 embedd=
ed
>> 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 th=
e
>> Tapleaf hashes=2E
>>
>> I only point this out because there seems to be a push to find "bugs" a=
nd
>> "accidental blowups" in the Taproot design currently=2E No problem with=
 this
>> if there are any, they should definitely be highlighted and discussed i=
f
>> they do exist=2E The nearest to a possible inferior design decision thu=
s far
>> that I'm aware of is x-only pubkeys in BIP340 [0]=2E
>>
>> Thanks
>> Michael
>>
>> [0]:
>> https://btctranscripts=2Ecom/london-bitcoin-devs/2022-08-11-tim-ruffing=
-musig2/#a-retrospective-look-at-bip340
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail=2Ecom
>> 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-d=
ev <
>> bitcoin-dev@lists=2Elinuxfoundation=2Eorg> 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=2E
>>
>> The countermeasure is that you should always know the entire Taptree wh=
en
>> interacting with someone's Tapspend=2E
>>
>>
>> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
>> bitcoin-dev@lists=2Elinuxfoundation=2Eorg> 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=2Esipa=2Ebe/miniscript/
>>> > [2] In Taproot, if you want to prevent signatures migrating to anoth=
er
>>> > branch or within a branch, you can use the CODESEPARATOR opcode
>>> > which was redisegned in Taproot for exactly this purpose=2E=2E=2E 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 signature=
s
>>> between tapbranches=2E
>>>
>>> I had thought this was the case, but then I re-confused myself by
>>> reading BIP 341 =2E=2E=2E=2E which has much of the sighash specified, =
but not
>>> all of it! The tapleaf hash is added in BIP 342=2E
>>>
>>> >
>>> > 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=2Enet
>>> Web: https://www=2Ewpsoftware=2Enet/andrew
>>>
>>> The sun is always shining in space
>>> -Justin Lewis-Webster
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>>> https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
>>>
>>
>>

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

Cheers,
aj
--=20
Sent from my phone=2E