Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-11 🗒️ Summary of this message: A bug in ...
📅 Original date posted:2023-02-11
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated, but signing the entire tapbranch instead of the tapleaf can fix it.
📝 Original message: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 <aj at erisian.com.au> wrote:
> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev at 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 at 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 at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230211/40833a03/attachment.html>;
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated, but signing the entire tapbranch instead of the tapleaf can fix it.
📝 Original message: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 <aj at erisian.com.au> wrote:
> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev at 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 at 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 at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230211/40833a03/attachment.html>;