Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-08 🗒️ Summary of this message: Bug in Taproot ...
📅 Original date posted:2023-02-08
🗒️ Summary of this message: Bug in Taproot allows repeated Tapleaf at different Taplevels, fixed by signing entire Tapbranch instead of Tapleaf.
📝 Original message: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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/d4adc425/attachment-0001.html>;
🗒️ Summary of this message: Bug in Taproot allows repeated Tapleaf at different Taplevels, fixed by signing entire Tapbranch instead of Tapleaf.
📝 Original message: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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/d4adc425/attachment-0001.html>;