<blockquote>
<ol>
<li>What is the way to get the public key from the corresponding private key in Schnorr?</li>
</ol>
</blockquote>
<p>Multiply the private key with the generator G (like for ECDSA) and then throw away the Y coordinate.</p>
<p>Given the depth your questions go, I would recommend you to just read the relevant BIPs. In particular, BIP340 has a <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#user-content-Public_Key_Generation" rel="nofollow noreferrer">section</a> on public key generation.</p>
<blockquote>
<ol start="2">
<li>What does that obtained value represent? Also point of the elliptic curve? If so, I assume its X coo, so how do we know corresponding Y coo?</li>
</ol>
</blockquote>
<p>Yes, a point on the elliptic curve, of which you only know the X coordinate. Internally in the BIP340 scheme it is treated as the point with given X coordinate and even Y coordinate, but at a more high-level you can also think of the public key as representing &quot;either&quot; of the points.</p>
<p>Given the curve equation <em>y<sup>2</sup> = x<sup>3</sup> + 7</em>, the corresponding Y coordinates for a given X coordinate can be computed as <em>Y = ±√(X<sup>3</sup> + 7) mod p</em>. Note that this is a <a href="https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm" rel="nofollow noreferrer">modular square root</a> modulo the field size <em>p = 2<sup>256</sup>-2<sup>32</sup>-977</em>. For the specific value <em>p</em> for secp256k1, this is equivalent to <em>±(x<sup>3</sup> + 7)<sup>(p+1)/4</sup></em>.</p>
<p>This is not specific to BIP340 public keys. Even for ECDSA, typically public keys are represented in the so-called compressed format, consisting of <em>sign_byte + [32-byte big endian X coordinate]</em>, where the <em>sign_byte</em> is 0x02 if the Y coordinate is even, and 0x03 if the Y coordinate is odd. Reconstructing the full point also requires a modular square root for this format.</p>
<blockquote>
<ol start="3">
<li>Does Schnorr (BIP340) also support a classic key tweaking like ECDSA, where we add some value to the public key and then add the same value to the private key and we would produce a valid signature?</li>
</ol>
</blockquote>
<p>Yes, <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">Taproot</a> even critically relies on this tweaking operation for representing script paths: in order to spend a Taproot output with point <em>Q</em> as a script, an internal public key <em>P</em> needs to be revealed together with a script (Merkle root) <em>m</em> such that <em>Q = P + H(P || m)G</em>. Since the Y coordinate of <em>Q</em> is not part of the output, it also needs to be revealed at spending time.</p>
<blockquote>
<p>Does this mean that the number of possible points, i.e. the private key-public key pairs, is 2 times smaller than in the case of ECDSA since we only use even Ys?</p>
</blockquote>
<p>Yes, but note that this is not a <a href="https://bitcoin.stackexchange.com/questions/90118/why-is-no-security-lost-by-using-32-byte-public-keys-in-schnorr-signatures-inste/90120#90120">reduction in security</a> (not even a negligible one).</p>

CC BY-SA 4.0
2023-11-11T19:08:06.270Z
Thanks. Everything clear expect this tweaking. It confuses me that we only take the even Y coordinate. I wrote a question related to that. I hope you can help me. https://bitcoin.stackexchange.com/questions/120434/how-does-tweaking-in-schnorr-digital-signature-scheme-work-and-what-is-not-good
LeaBit
CC BY-SA 4.0
2023-11-11T17:50:26.330Z
2023-11-11T18:09:41.180Z
2023-11-11T18:09:41.180Z
Pieter Wuille
<p>In the scheme described in BIP 340, private and public keys are generated in the same way as for ECDSA in Bitcoin, with an additional step - use only the X coordinate, and assume that the Y coordinate is even.</p>
<p>BIP 340 continues to use the secp256k1 elliptic curve, so private keys are still just an integer, and public keys are points on that curve. As such, any elliptic curve operations that are independent of signing and verifying still work.</p>

CC BY-SA 4.0
2023-11-11T17:24:31.157Z
Does this mean that the number of possible points, i.e. the private key-public key pairs, is 2 times smaller than in the case of ECDSA since we only use even Ys?
LeaBit
CC BY-SA 4.0
2023-11-11T16:59:22.400Z
2023-11-11T17:07:53.480Z
2023-11-11T17:07:53.480Z
Ava Chow
<p>In ECDSA, the public key is the result of multiplying the private key (some random 256-bit value) with a generic point (G). So the public key would be one of the points (X,Y) of the elliptic curve secp256k1. In this case, the public key represents two 32-byte values (encoded as 65 bytes or 33 bytes in compressed form). However, as I see, with Schnorr the public key is just 32 bytes long (not even 33 where one byte would define whether Y is odd or even), so some other process is used.</p>
<ol>
<li>What is the way to get the public key from the corresponding private key in Schnor?</li>
<li>What does that obtained value represent? Also point of the elliptic curve? If so, I assume its X coo, so how do we know corresponding Y coo?</li>
<li>Does Schnorr (BIP340) also support a classic key tweaking like ECDSA, where we add some value to the public key and then add the same value to the private key and we would produce a valid signature?</li>
</ol>

<taproot><schnorr-signatures><x-only-pubkeys>
How to get x-only public key from the private key, and what does the obtained value represent?
LeaBit
# How to get x-only public key from the private key, and what does the obtained value represent?

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

In ECDSA, the public key is the result of multiplying the private key (some random 256-bit value) with a generic point (G). So the public key would be one of the points (X,Y) of the elliptic curve secp256k1. In this case, the public key represents two 32-byte values (encoded as 65 bytes or 33 bytes in compressed form). However, as I see, with Schnorr the public key is just 32 bytes long (not even 33 where one byte would define whether Y is odd or even), so some other process is used.

1. What is the way to get the public key from the corresponding private key in Schnor?
2. What does that obtained value represent? Also point of the elliptic curve? If so, I assume its X coo, so how do we know corresponding Y coo?
3. Does Schnorr (BIP340) also support a classic key tweaking like ECDSA, where we add some value to the public key and then add the same value to the private key and we would produce a valid signature?

**Tags:** taproot, schnorr-signatures, x-only-pubkeys


---

## 2 answers

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

> 1. What is the way to get the public key from the corresponding private key in Schnorr?

Multiply the private key with the generator G (like for ECDSA) and then throw away the Y coordinate.

Given the depth your questions go, I would recommend you to just read the relevant BIPs. In particular, BIP340 has a [section](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#user-content-Public_Key_Generation) on public key generation.

> 2. What does that obtained value represent? Also point of the elliptic curve? If so, I assume its X coo, so how do we know corresponding Y coo?

Yes, a point on the elliptic curve, of which you only know the X coordinate. Internally in the BIP340 scheme it is treated as the point with given X coordinate and even Y coordinate, but at a more high-level you can also think of the public key as representing "either" of the points.

Given the curve equation *y2 = x3 + 7*, the corresponding Y coordinates for a given X coordinate can be computed as *Y = ±√(X3 + 7) mod p*. Note that this is a [modular square root](https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm) modulo the field size *p = 2256-232-977*. For the specific value *p* for secp256k1, this is equivalent to *±(x3 + 7)(p+1)/4*.

This is not specific to BIP340 public keys. Even for ECDSA, typically public keys are represented in the so-called compressed format, consisting of *sign\_byte + [32-byte big endian X coordinate]*, where the *sign\_byte* is 0x02 if the Y coordinate is even, and 0x03 if the Y coordinate is odd. Reconstructing the full point also requires a modular square root for this format.

> 3. Does Schnorr (BIP340) also support a classic key tweaking like ECDSA, where we add some value to the public key and then add the same value to the private key and we would produce a valid signature?

Yes, [Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) even critically relies on this tweaking operation for representing script paths: in order to spend a Taproot output with point *Q* as a script, an internal public key *P* needs to be revealed together with a script (Merkle root) *m* such that *Q = P + H(P || m)G*. Since the Y coordinate of *Q* is not part of the output, it also needs to be revealed at spending time.

> Does this mean that the number of possible points, i.e. the private key-public key pairs, is 2 times smaller than in the case of ECDSA since we only use even Ys?

Yes, but note that this is not a [reduction in security](https://bitcoin.stackexchange.com/questions/90118/why-is-no-security-lost-by-using-32-byte-public-keys-in-schnorr-signatures-inste/90120#90120) (not even a negligible one).

> **Comments:**
> **username_0**: Thanks. Everything clear expect this tweaking. It confuses me that we only take the even Y coordinate. I wrote a question related to that. I hope you can help me. https://bitcoin.stackexchange.com/questions/120434/how-does-tweaking-in-schnorr-digital-signature-scheme-work-and-what-is-not-good  

---

### Answer by username_2 on 2023-11-11. Score: 1

In the scheme described in BIP 340, private and public keys are generated in the same way as for ECDSA in Bitcoin, with an additional step - use only the X coordinate, and assume that the Y coordinate is even.

BIP 340 continues to use the secp256k1 elliptic curve, so private keys are still just an integer, and public keys are points on that curve. As such, any elliptic curve operations that are independent of signing and verifying still work.

> **Comments:**
> **username_0**: Does this mean that the number of possible points, i.e. the private key-public key pairs, is 2 times smaller than in the case of ECDSA since we only use even Ys?  

---

