Let's first introduce some terminology, because "key path only" could mean different things. Say:
- A raw taproot output is one where the output key (the one in the
scriptPubKey) is exactly equal to P, the wallet's public key.
- A noscript taproot output is one where the output key is P + hashTapTweak(P)⋅G, with P the wallet key (also called the internal public key).
- A tree taproot output is one where the output key is P + hashTapTweak(P || m)⋅G, where m is the Merkle root of a known Merkle tree.
- An OP_FALSE taproot output is a tree taproot output, where m = hashTapLeaf(0xc0 || Script(OP_FALSE)), i.e. Taproot outputs whose script tree consists of solely an OP_FALSE script.
(I don't mean to introduce these as general terms as I feel they're far too bike-sheddable, they're just the terms I'm going to use in this answer).
All 4 of the above can be spent using the key path, because the party computing the output, if they know the private key to P, can also compute the private key to the output key. Raw, noscript, and OP_FALSE taproot outputs cannot be spent using any script path. For noscript and OP_FALSE outputs it is also possible to prove to third parties that said output cannot be spent using a script path, by revealing P.
If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path.
This text in BIP341 suggests always using noscript taproot outputs whenever no script path spending is desired.
Does this only apply to key path spends that are more complicated than a simple single key - e.g., only where the "taproot output key is an aggregate of keys"? Or is it a suggestion that an output with only a key path spend be avoided altogether?
It applies always, for any scenario where no script path spending is desired. The reasons for this differ though:
- In some cases, it is actually a security concern. As mentioned in footnote 23 of the BIP, when using the MSDL-pop key aggregation algorithm naively, a malicious cosigner might be able to sneak in a script path without the other cosigners being able. There are many ways that this risk can be mitigated, but explicitly performing a BIP341 key tweak without script paths (so using the noscript or OP_FALSE mechanism) is an obvious one. Using raw may actually be insecure in this case.
- In some cases, it may just be desirable to be able to prove that no script paths exist, even though the risk from the previous bulletpoint doesn't exist (e.g. the output was constructed by a single party only, or MuSig was used). So in this case using raw wouldn't be insecure, but it doesn't permit proving that it isn't. Both noscript and OP_FALSE are provable (just reveal P plus which mechanism was chosen to the third party, and they can recompute the output).
- In case just a single participant exists, or MuSig is used, or some other precaution is taken, and no need for proving the lack of script paths to third parties is envisioned, there is no strict reason for not using raw. However, it is still useful to aim for standardizing a single method for computing output keys, in order to minimize the number of combinations to implement/test, as well as avoiding the need to convey exactly in which scenarios which one should be used. BIP341 therefore picks one method, namely noscript. It could have picked OP_FALSE just as well, but I personally find it somewhat cleaner to strictly separate "no scripts" from "1 or more scripts" (even if the latter is just an unspendable one).
That said, this text in BIP341 is just a suggestion, and there may be reasons for picking raw:
- You really care about performance, and the overhead of performing a key tweak is too much. For example, when computing vanity addresses, it may be desirable to forego the tweaking (leaving in the middle whether that's a use case to encourage or not...).
- You're using a key aggregation algorithm that somehow can't deal with tweaking at signing time (e.g. you're using a FROST signing library that doesn't support BIP341 tweaking). This does mean you need to understand the risks related to parties sneaking in script paths though, which may mean convincing yourself that this possibility is harmless for your use case, or take other cryptographic precautions (e.g. related to how the participant keys are generated) to avoid them.
P.S. this answer which says " ... It is generally important to be able to prove that the internal public key that you choose is a point with an unknown private key ... seems to be related to but I'm not quite sure...
That's about the opposite case, where one wants a taproot output that is only spendable through the script path spend, and may want to be able to prove so.
