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 >> > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
