From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Michael Folkson <michaelfolkson@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
Date: Wed, 8 Feb 2023 14:00:48 +0000 [thread overview]
Message-ID: <Y+OrEDooHlijDpJV@camus> (raw)
In-Reply-To: <VWZ9Dc2gIe0Y02yY3qSbjQTEPqwCm6YAtRzfNrIANBXCEJzr73SdxZT4LwBKDyriDfmDZyTlkKWtoZmVIUbYqqZUAeTMDLHUNFCBwR6hitQ=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
On Wed, Feb 08, 2023 at 09:34:57AM +0000, Michael Folkson 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].
>
I'm actually not certain what Russell's referring to, but if it's indeed
possible to construct TapTrees where the "same" leafhash appears multiple
times at different heights, that's something unintended and which we
could've fixed by changing the Merkle structure. I don't even think
there would've been an efficiency tradeoff.
So I think it's totally reasonable to call such a thing a "bug".
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-02-08 14:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 2:49 Yuval Kogman
2023-02-07 4:38 ` Lloyd Fournier
2023-02-07 9:36 ` Nadav Ivgi
2023-02-07 12:50 ` Peter Todd
2023-02-07 13:46 ` Andrew Poelstra
2023-02-07 18:10 ` Andrew Poelstra
2023-02-07 18:35 ` Russell O'Connor
2023-02-07 19:04 ` Peter Todd
2023-02-08 9:34 ` Michael Folkson
2023-02-08 14:00 ` Andrew Poelstra [this message]
2023-02-08 14:04 ` Russell O'Connor
2023-02-11 5:14 ` Anthony Towns
2023-02-11 14:40 ` Russell O'Connor
2023-02-12 6:47 ` Anthony Towns
2023-02-07 18:12 ` Peter Todd
2023-02-08 0:56 ` Antoine Riard
2023-02-10 19:35 ` Yuval Kogman
2023-02-15 3:33 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+OrEDooHlijDpJV@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox