📅 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>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 23:19:29
in reply to nevent1q…7gx4
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 23:19:29Event JSON
{
"id": "8b60fe6b4de6748c143867632cea5ced99266667092841f2efeaae718d255e6d",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686179969,
"kind": 1,
"tags": [
[
"e",
"1cb271826c48de88a6304ac8ffedd6340167a6ad4b82c11ba779c915dfc4192e",
"",
"root"
],
[
"e",
"b18703e776fb86102b9700e163e640eec075450969f2da7db743fa9a749f66c0",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2023-02-11\n🗒️ 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.\n📝 Original message:Yes. If you would otherwise sign the tapleaf, then I would recommend also\nsigning the entire tapbranch.\n\n\n\nOn Sat, Feb 11, 2023 at 12:15 AM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003eThe fix for the bug is to sign the entire tapbranch instead of the\n\u003e tapleaf.\n\u003e \u003e\n\u003e \u003eOn Wed., Feb. 8, 2023, 04:35 Michael Folkson, \u003c\n\u003e michaelfolkson at protonmail.com\u003e\n\u003e \u003ewrote:\n\u003e \u003e\n\u003e \u003e\u003e Hi Andrew\n\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e There is a bug in Taproot that allows the same Tapleaf to be repeated\n\u003e \u003e\u003e multiple times in the same Taproot, potentially at different Taplevels\n\u003e \u003e\u003e incurring different Tapfee rates.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e The countermeasure is that you should always know the entire Taptree\n\u003e \u003e\u003e when interacting with someone's Tapspend.\n\u003e \u003e\u003e\n\u003e \u003e\u003e I wouldn't say it is a \"bug\" unless there is a remedy for the bug that\n\u003e \u003e\u003e wasn't (and retrospectively should have been) included in the Taproot\n\u003e \u003e\u003e design. In retrospect and assuming you could redesign the Taproot\n\u003e consensus\n\u003e \u003e\u003e rules again today would you prevent spending from a valid P2TR address\n\u003e if a\n\u003e \u003e\u003e repeated Tapleaf hash was used to prove that a spending path was\n\u003e embedded\n\u003e \u003e\u003e in a Taproot tree? That's the only thing I can think of to attempt to\n\u003e \u003e\u003e remedy this \"bug\" and it would only be a partial protection as proving a\n\u003e \u003e\u003e spending path exists within a Taproot tree only requires a subset of the\n\u003e \u003e\u003e Tapleaf hashes.\n\u003e \u003e\u003e\n\u003e \u003e\u003e I only point this out because there seems to be a push to find \"bugs\"\n\u003e and\n\u003e \u003e\u003e \"accidental blowups\" in the Taproot design currently. No problem with\n\u003e this\n\u003e \u003e\u003e if there are any, they should definitely be highlighted and discussed if\n\u003e \u003e\u003e they do exist. The nearest to a possible inferior design decision thus\n\u003e far\n\u003e \u003e\u003e that I'm aware of is x-only pubkeys in BIP340 [0].\n\u003e \u003e\u003e\n\u003e \u003e\u003e Thanks\n\u003e \u003e\u003e Michael\n\u003e \u003e\u003e\n\u003e \u003e\u003e [0]:\n\u003e \u003e\u003e\n\u003e https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340\n\u003e \u003e\u003e\n\u003e \u003e\u003e --\n\u003e \u003e\u003e Michael Folkson\n\u003e \u003e\u003e Email: michaelfolkson at protonmail.com\n\u003e \u003e\u003e Keybase: michaelfolkson\n\u003e \u003e\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e \u003e\u003e\n\u003e \u003e\u003e ------- Original Message -------\n\u003e \u003e\u003e On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via\n\u003e bitcoin-dev \u003c\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e There is a bug in Taproot that allows the same Tapleaf to be repeated\n\u003e \u003e\u003e multiple times in the same Taproot, potentially at different Taplevels\n\u003e \u003e\u003e incurring different Tapfee rates.\n\u003e \u003e\u003e\n\u003e \u003e\u003e The countermeasure is that you should always know the entire Taptree\n\u003e when\n\u003e \u003e\u003e interacting with someone's Tapspend.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev \u003c\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Some people highlighted some minor problems with my last email:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via\n\u003e bitcoin-dev\n\u003e \u003e\u003e\u003e wrote:\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e \u003e \u003csnip\u003e\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e \u003e [1] https://bitcoin.sipa.be/miniscript/\n\u003e \u003e\u003e\u003e \u003e [2] In Taproot, if you want to prevent signatures migrating to\n\u003e another\n\u003e \u003e\u003e\u003e \u003e branch or within a branch, you can use the CODESEPARATOR opcode\n\u003e \u003e\u003e\u003e \u003e which was redisegned in Taproot for exactly this purpose... we\n\u003e \u003e\u003e\u003e \u003e really did about witness malleation in its design!\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e In Taproot the tapleaf hash is always covered by the signature (though\n\u003e \u003e\u003e\u003e not in some ANYONECANPAY proposals) so you can never migrate signatures\n\u003e \u003e\u003e\u003e between tapbranches.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e I had thought this was the case, but then I re-confused myself by\n\u003e \u003e\u003e\u003e reading BIP 341 .... which has much of the sighash specified, but not\n\u003e \u003e\u003e\u003e all of it! The tapleaf hash is added in BIP 342.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e \u003e If you want to prevent signatures from moving around *within* a\n\u003e \u003e\u003e\u003e \u003e branch,\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e And this sentence I just meant to delete :)\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e --\n\u003e \u003e\u003e\u003e Andrew Poelstra\n\u003e \u003e\u003e\u003e Director of Research, Blockstream\n\u003e \u003e\u003e\u003e Email: apoelstra at wpsoftware.net\n\u003e \u003e\u003e\u003e Web: https://www.wpsoftware.net/andrew\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e The sun is always shining in space\n\u003e \u003e\u003e\u003e -Justin Lewis-Webster\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e _______________________________________________\n\u003e \u003e\u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e\n\u003e Is this something that should be fixed in bip118 signatures then?\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e --\n\u003e Sent from my phone.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230211/40833a03/attachment.html\u003e",
"sig": "c8ce08179ce9cd7e05302d3babaf73164e2c12df96ce800983ccfb92499973f107537ec77973a8c5eabfddcb974dbfcdea3fc93cb9c126b77176b7558ce50d2c"
}