<p>Correct on both accounts.</p>
<p>In taproot spends there can actually be up to 3 kinds of keys:</p>
<ul>
<li>The internal key (before tweaking)</li>
<li>The output key (the internal key after tweaking)</li>
<li>Script keys (inside the scripts, there can also be keys).</li>
</ul>
<p>The signature algorithm (BIP340) uses x-only public keys. It follows that whenever a signature is used, the parity of the corresponding key is ignored. This happens with:</p>
<ul>
<li>The output key (for key path spends)</li>
<li>The script keys (for script path spends)</li>
</ul>
<p>During a script path spend, there is something else going on. We don't just sign, but have to prove that the output key is a correctly tweaked version of the internal key. The revealed revealed keys are all x-only (including the internal key and script keys), but to prove the tweak, it is also necessary to reveal what the original parity of the output key was.</p>

CC BY-SA 4.0
2023-11-17T12:41:50.700Z
2023-11-17T12:41:50.700Z
Pieter Wuille
<p>I am reading materials related to the Taproot (specially, <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a>) and I know that there is two possible ways to spend the output:</p>
<ol>
<li>via key path</li>
<li>via script path</li>
</ol>
<p>I also know that the Taproot output contains only the X coordinate, while the Y coordinate is indirectly assumed to be <strong>EVEN</strong>. So, in case you want to consume the output via the key path, you need to create a signature for the <strong>(X, Yeven)</strong> point.</p>
<p>However, reading BIP341, one of the consensus rules for spending via the script path is:</p>
<pre><code>If q ≠ x(Q) or c[0] &amp; 1 ≠ y(Q) mod 2, fail.
</code></pre>
<p>From the content to the right of <code>OR</code>, it looks like the first bit (0000000<strong>0</strong>) inside first byte within control block denotes the parity (sign) of the Y coordinate (<code>0</code> - even Y, <code>1</code> - odd Y) and that we must set the correct parity, that is, indirectly, the correct (even/odd) Y coordinate in order to make valid witness.</p>
<p>It follows that although we always use an even Y coordinate when spending via the key path <strong>(regardless of whether a point with an even or odd Y coordinate is obtained after tweaking), for spending via the script path we still need to know what was that original point obtained after tweaking (that is, whether it has an even or odd Y coordinate)</strong> and to set the correct parity bit. Am I right?</p>
<p>Also, since tweaking by the consensus rules (BIP341) between underlaying key (P) and MAST root is done in a such way that the even Y coordinate of the point P is used, does it mean that if I get from the underlaying private key (not the tweaked one) a point that has an odd Y coordinate, <strong>I have to negate it first before further tweaking with the MAST root</strong>? And also from this, my private key becomes <code>-private key</code>, that is, the public key is <code>private key * (-G)</code>?</p>
<p>Thanks to all in advance.</p>

<taproot><p2tr>
Is it true that we don't care about parity with the key path, but it is not case with the script path? (Taproot)
LeaBit
# Is it true that we don't care about parity with the key path, but it is not case with the script path? (Taproot)

(Asked by: username_0 on 2023-11-17)

I am reading materials related to the Taproot (specially, [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)) and I know that there is two possible ways to spend the output:

1. via key path
2. via script path

I also know that the Taproot output contains only the X coordinate, while the Y coordinate is indirectly assumed to be **EVEN**. So, in case you want to consume the output via the key path, you need to create a signature for the **(X, Yeven)** point.

However, reading BIP341, one of the consensus rules for spending via the script path is:

```
If q ≠ x(Q) or c[0] & 1 ≠ y(Q) mod 2, fail.

```

From the content to the right of `OR`, it looks like the first bit (0000000**0**) inside first byte within control block denotes the parity (sign) of the Y coordinate (`0` - even Y, `1` - odd Y) and that we must set the correct parity, that is, indirectly, the correct (even/odd) Y coordinate in order to make valid witness.

It follows that although we always use an even Y coordinate when spending via the key path **(regardless of whether a point with an even or odd Y coordinate is obtained after tweaking), for spending via the script path we still need to know what was that original point obtained after tweaking (that is, whether it has an even or odd Y coordinate)** and to set the correct parity bit. Am I right?

Also, since tweaking by the consensus rules (BIP341) between underlaying key (P) and MAST root is done in a such way that the even Y coordinate of the point P is used, does it mean that if I get from the underlaying private key (not the tweaked one) a point that has an odd Y coordinate, **I have to negate it first before further tweaking with the MAST root**? And also from this, my private key becomes `-private key`, that is, the public key is `private key * (-G)`?

Thanks to all in advance.

**Tags:** taproot, p2tr


---

## 1 answers

### Answer by username_1 on 2023-11-17. Score: 3 | Accepted answer

Correct on both accounts.

In taproot spends there can actually be up to 3 kinds of keys:

* The internal key (before tweaking)
* The output key (the internal key after tweaking)
* Script keys (inside the scripts, there can also be keys).

The signature algorithm (BIP340) uses x-only public keys. It follows that whenever a signature is used, the parity of the corresponding key is ignored. This happens with:

* The output key (for key path spends)
* The script keys (for script path spends)

During a script path spend, there is something else going on. We don't just sign, but have to prove that the output key is a correctly tweaked version of the internal key. The revealed revealed keys are all x-only (including the internal key and script keys), but to prove the tweak, it is also necessary to reveal what the original parity of the output key was.


---

