<p>Let's first introduce some terminology, because &quot;key path only&quot; could mean different things. Say:</p>
<ul>
<li>A <strong>raw</strong> taproot output is one where the output key (the one in the <code>scriptPubKey</code>) is exactly equal to <em>P</em>, the wallet's public key.</li>
<li>A <strong>noscript</strong> taproot output is one where the output key is <em>P + hash<sub>TapTweak</sub>(P)⋅G</em>, with <em>P</em> the wallet key (also called the <em>internal public key</em>).</li>
<li>A tree taproot output is one where the output key is <em>P + hash<sub>TapTweak</sub>(P || m)⋅G</em>, where <em>m</em> is the Merkle root of a known Merkle tree.
<ul>
<li>An <strong>OP_FALSE</strong> taproot output is a tree taproot output, where <em>m = hash<sub>TapLeaf</sub>(0xc0 || Script(OP_FALSE))</em>, i.e. Taproot outputs whose script tree consists of solely an OP_FALSE script.</li>
</ul>
</li>
</ul>
<p>(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).</p>
<p>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 <em>P</em>, can also compute the private key to the output key. <strong>Raw</strong>, <strong>noscript</strong>, and <strong>OP_FALSE</strong> taproot outputs cannot be spent using any script path. For <strong>noscript</strong> and <strong>OP_FALSE</strong> outputs it is also possible to prove to third parties that said output <em>cannot</em> be spent using a script path, by revealing <em>P</em>.</p>
<blockquote>
<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.</p>
</blockquote>
<p>This text in BIP341 suggests always using <strong>noscript</strong> taproot outputs whenever no script path spending is desired.</p>
<blockquote>
<p>Does this only apply to key path spends that are more complicated than a simple single key - e.g., only where the &quot;taproot output key is an aggregate of keys&quot;? Or is it a suggestion that an output with only a key path spend be avoided altogether?</p>
</blockquote>
<p>It applies always, for any scenario where no script path spending is desired. The reasons for this differ though:</p>
<ul>
<li>In some cases, it is actually a security concern. As mentioned in <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-23" rel="noreferrer">footnote 23</a> 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 <strong>noscript</strong> or <strong>OP_FALSE</strong> mechanism) is an obvious one. Using <strong>raw</strong> may actually be insecure in this case.</li>
<li>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 <strong>raw</strong> wouldn't be insecure, but it doesn't permit proving that it isn't. Both <strong>noscript</strong> and <strong>OP_FALSE</strong> are provable (just reveal <em>P</em> plus which mechanism was chosen to the third party, and they can recompute the output).</li>
<li>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 <strong>raw</strong>. 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 <strong>noscript</strong>. It could have picked <strong>OP_FALSE</strong> just as well, but I personally find it somewhat cleaner to strictly separate &quot;no scripts&quot; from &quot;1 or more scripts&quot; (even if the latter is just an unspendable one).</li>
</ul>
<p>That said, this text in BIP341 is just a suggestion, and there may be reasons for picking <strong>raw</strong>:</p>
<ul>
<li>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...).</li>
<li>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.</li>
</ul>
<blockquote>
<p>P.S. <a href="https://bitcoin.stackexchange.com/a/99728/36307">this answer which says &quot; ... 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 ...</a> seems to be related to but I'm not quite sure...</p>
</blockquote>
<p>That's about the opposite case, where one wants a taproot output that is only spendable through the <em>script</em> path spend, and may want to be able to prove so.</p>

CC BY-SA 4.0
2022-06-07T21:24:51.610Z
2022-06-07T21:43:43.770Z
2022-06-07T21:43:43.770Z
Pieter Wuille
<p>Consider <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#constructing-and-spending-taproot-outputs" rel="noreferrer">BIP-341 &quot;Constructing and spending Taproot outputs&quot;</a> where it says</p>
<blockquote>
<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.</p>
</blockquote>
<p>and also the <a href="https://bitcoin.stackexchange.com/a/99326/36307">answer here</a> where Michael Folkson explains it a bit further, then:</p>
<p>Does this only apply to key path spends that are more complicated than a simple single key - e.g., only where the <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-23" rel="noreferrer">&quot;taproot output key is an aggregate of keys&quot;</a>?  Or is it a suggestion that an output with only a key path spend <em>be avoided altogether?</em></p>
<p>P.S. <a href="https://bitcoin.stackexchange.com/a/99728/36307">this answer which says &quot; ... 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 ...</a> seems to be related to but I'm not quite sure...</p>

<taproot><p2tr>
BIP-341: Should key-path-only P2TR be eschewed altogether?
davidbak
# BIP-341: Should key-path-only P2TR be eschewed altogether?

(Asked by: username_0 on 2022-06-07)

Consider [BIP-341 "Constructing and spending Taproot outputs"](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#constructing-and-spending-taproot-outputs) where it says

> 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.

and also the [answer here](https://bitcoin.stackexchange.com/a/99326/36307) where Michael Folkson explains it a bit further, then:

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"](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-23)? Or is it a suggestion that an output with only a key path spend *be avoided altogether?*

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 ...](https://bitcoin.stackexchange.com/a/99728/36307) seems to be related to but I'm not quite sure...

**Tags:** taproot, p2tr


---

## 1 answers

### Answer by username_1 on 2022-06-07. Score: 13 | Accepted answer

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](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-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 ...](https://bitcoin.stackexchange.com/a/99728/36307) 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.


---

