taproot – BIP-341: Ought to key-path-only P2TR be eschewed altogether?

Let’s first introduce some terminology, as a result of “key path solely” might imply various things. Say:

• A uncooked taproot output is one the place the output key (the one within the scriptPubKey) is strictly equal to P, the pockets’s public key.
• A noscript taproot output is one the place the output key’s P + hash_TapTweak(P)⋅G, with P the pockets key (additionally referred to as the inside public key).
• A tree taproot output is one the place the output key’s P + hash_TapTweak(P || m)⋅G, the place m is the Merkle root of a identified Merkle tree.
  • An OP_FALSE taproot output is a tree taproot output, the place m = hash_TapLeaf(0xc0 || Script(OP_FALSE)), i.e. Taproot outputs whose script tree consists of solely an OP_FALSE script.

(I do not imply to introduce these as normal phrases as I really feel they’re far too bike-sheddable, they’re simply the phrases I’ll use on this reply).

All 4 of the above may be spent utilizing the important thing path, as a result of the social gathering computing the output, in the event that they know the non-public key to P, also can compute the non-public key to the output key. Uncooked, noscript, and OP_FALSE taproot outputs can’t be spent utilizing any script path. For noscript and OP_FALSE outputs additionally it is attainable to show to 3rd events that mentioned output can’t be spent utilizing a script path, by revealing P.

If the spending situations don’t require a script path, the output key ought to decide to an unspendable script path as an alternative of getting no script path.

This textual content in BIP341 suggests at all times utilizing noscript taproot outputs at any time when no script path spending is desired.

Does this solely apply to key path spends which can be extra sophisticated than a easy single key – e.g., solely the place the “taproot output key’s an combination of keys”? Or is it a suggestion that an output with solely a key path spend be prevented altogether?

It applies at all times, for any situation the place no script path spending is desired. The explanations for this differ although:

• In some circumstances, it’s really a safety concern. As talked about in footnote 23 of the BIP, when utilizing the MSDL-pop key aggregation algorithm naively, a malicious cosigner may have the ability to sneak in a script path with out the opposite cosigners having the ability. There are lots of ways in which this threat may be mitigated, however explicitly performing a BIP341 key tweak with out script paths (so utilizing the noscript or OP_FALSE mechanism) is an apparent one. Utilizing uncooked may very well be insecure on this case.
• In some circumstances, it could simply be fascinating to have the ability to show that no script paths exist, despite the fact that the chance from the earlier bulletpoint does not exist (e.g. the output was constructed by a single social gathering solely, or MuSig was used). So on this case utilizing uncooked would not be insecure, but it surely does not allow proving that it’s not. Each noscript and OP_FALSE are provable (simply reveal P plus which mechanism was chosen to the third social gathering, and so they can recompute the output).
• In case only a single participant exists, or MuSig is used, or another precaution is taken, and no want for proving the shortage of script paths to 3rd events is envisioned, there isn’t any strict cause for not utilizing uncooked. Nonetheless, it’s nonetheless helpful to intention for standardizing a single methodology for computing output keys, as a way to decrease the variety of combos to implement/check, in addition to avoiding the necessity to convey precisely during which eventualities which one ought to be used. BIP341 due to this fact picks one methodology, particularly noscript. It might have picked OP_FALSE simply as nicely, however I personally discover it considerably cleaner to strictly separate “no scripts” from “1 or extra scripts” (even when the latter is simply an unspendable one).

That mentioned, this textual content in BIP341 is only a suggestion, and there could also be causes for choosing uncooked:

• You actually care about efficiency, and the overhead of performing a key tweak is an excessive amount of. For instance, when computing self-importance addresses, it could be fascinating to forego the tweaking (leaving within the center whether or not that is a use case to encourage or not…).
• You are utilizing a key aggregation algorithm that one way or the other cannot cope with tweaking at signing time (e.g. you are utilizing a FROST signing library that does not help BIP341 tweaking). This does imply it is advisable perceive the dangers associated to events sneaking in script paths although, which can imply convincing your self that this chance is innocent to your use case, or take different cryptographic precautions (e.g. associated to how the participant keys are generated) to keep away from them.

P.S. this reply which says ” … It’s typically vital to have the ability to show that the interior public key that you simply select is a degree with an unknown non-public key … appears to be associated to however I am not fairly positive…

That is in regards to the reverse case, the place one desires a taproot output that’s solely spendable via the script path spend, and might want to have the ability to show so.