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:
>>> >
>>> > <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
>>>
>>
>>
Is this something that should be fixed in bip118 signatures then?
Cheers,
aj
--
Sent from my phone.