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 <a...@erisian.com.au> 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, < > michaelfolk...@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. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
