<p>Both are valid public keys just that in the first case the uncompressed public key is not represented in a valid hexadecimal format. If you look closely, your <code>Qy</code> has 63 hexadecimal digits (so there is a 'half-byte'). Although hashing can be done in bit boundaries, most standard implementations out there do not support it.  Just try to concatenate '0' at the start of the Qy to get <code>Qy = 0691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3</code> so that you get a full byte. So now your uncompressed public key is <code>04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA0691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3</code>, which would hash to P2PKH address: <code>17Y1XJiC72f2kyJnzwBdkaPQEGgaD1aroR</code></p>

CC BY-SA 4.0
2019-07-15T12:18:42.557Z
Excellent! Thanks for your prompt answer.
Robert
CC BY-SA 4.0
2019-07-15T12:13:03.267Z
2019-07-15T12:13:03.267Z
Ugam Kamat
<p>First, some background. </p>

<p><strong>1</strong>. There are some coordinates <code>x,y</code> satisfying <code>y^2(mod p)=x^3+7(mod p)</code> on the Secp256k1 curve that <em>do not</em> correspond to a valid Bitcoin <strong>uncompressed</strong> publicKey of the form <code>04[x,y]</code>.</p>

<p>We can prove <strong>1</strong> using the <code>random_point()</code> function in Sage with unknown generator under<code>E=EllipticCurve(GF(modi), [0,7])</code>. If we get <em>lucky</em>, after a few trials Sage returns a point such as Q.</p>

<pre><code>   Q=E.random_point()

   Q
   (B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA : 
    691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3 : 1)
</code></pre>

<p>Now we have:</p>

<pre><code>   Qx=B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA
   Qy=691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3
</code></pre>

<p>We verify that <code>Qy^2(mod p) = Qx^3+7 (mod p)</code> is satisfied so we confirm that Q is a point on the Secp256k1 curve. </p>

<p>Next, we try to validate Q as an <strong>uncompressed</strong> Bitcoin publicKey:</p>

<pre><code>04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3
</code></pre>

<p>We get: <code>Q is not a valid publicKey</code>. </p>

<p>Yet, checking the validity of the <em>mirrored</em> point -Q, returns a valid publicKey:</p>

<pre><code>   -Qx=B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA
   -Qy=F96E55BBAFDDEDA6EECD5590D8A7D4870668966721CAA3B11A69F24EA53F598C
</code></pre>

<p>Valid publicKey for -Q: </p>

<pre><code>04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DAF96E55BBAFDDEDA6EECD5590D8A7D4870668966721CAA3B11A69F24EA53F598C
</code></pre>

<p>Valid publicKey for -Q (hashed):</p>

<p><code>1A2gaiiKy91Pmx8EUcbT4Hd6JFZ3sQvUhM</code></p>

<p>Question:</p>

<p>Why not every [x,y] coordinate on the Secp256k1 curve corresponds to a valid <strong>uncompressed</strong> publicKey?</p>

<p><strong>Note:</strong> </p>

<p>In this question, by <em>validity</em> I mean a set of EC coordinates (x,y) that can be hashed into a bitcoin <strong>uncompressed</strong> address. I am specifying <strong>uncompressed</strong> for obvious reasons. My question is detailed enough I hope to show that it's not referring to compressed Bitcoin addresses.  </p>

<public-key><secp256k1>
Why not every [x,y] coordinate on the Secp256k1 curve corresponds to a valid uncompressed publicKey?
Robert
# Why not every [x,y] coordinate on the Secp256k1 curve corresponds to a valid uncompressed publicKey?

(Asked by: username_0 on 2019-07-15)

First, some background. 
1. There are some coordinates x,y satisfying y^2(mod p)=x^3+7(mod p) on the Secp256k1 curve that do not correspond to a valid Bitcoin uncompressed publicKey of the form 04[x,y].
We can prove 1 using the random_point() function in Sage with unknown generator underE=EllipticCurve(GF(modi), [0,7]). If we get lucky, after a few trials Sage returns a point such as Q.
   Q=E.random_point()

   Q
   (B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA : 
    691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3 : 1)

Now we have:
   Qx=B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA
   Qy=691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3

We verify that Qy^2(mod p) = Qx^3+7 (mod p) is satisfied so we confirm that Q is a point on the Secp256k1 curve. 
Next, we try to validate Q as an uncompressed Bitcoin publicKey:
04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3

We get: Q is not a valid publicKey. 
Yet, checking the validity of the mirrored point -Q, returns a valid publicKey:
   -Qx=B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA
   -Qy=F96E55BBAFDDEDA6EECD5590D8A7D4870668966721CAA3B11A69F24EA53F598C

Valid publicKey for -Q: 
04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DAF96E55BBAFDDEDA6EECD5590D8A7D4870668966721CAA3B11A69F24EA53F598C

Valid publicKey for -Q (hashed):
1A2gaiiKy91Pmx8EUcbT4Hd6JFZ3sQvUhM
Question:
Why not every [x,y] coordinate on the Secp256k1 curve corresponds to a valid uncompressed publicKey?
Note: 
In this question, by validity I mean a set of EC coordinates (x,y) that can be hashed into a bitcoin uncompressed address. I am specifying uncompressed for obvious reasons. My question is detailed enough I hope to show that it's not referring to compressed Bitcoin addresses.

**Tags:** public-key, secp256k1


---

## 1 answers

### Answer by username_1 on 2019-07-15. Score: 3 | Accepted answer

Both are valid public keys just that in the first case the uncompressed public key is not represented in a valid hexadecimal format. If you look closely, your `Qy` has 63 hexadecimal digits (so there is a 'half-byte'). Although hashing can be done in bit boundaries, most standard implementations out there do not support it. Just try to concatenate '0' at the start of the Qy to get `Qy = 0691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3` so that you get a full byte. So now your uncompressed public key is `04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA0691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3`, which would hash to P2PKH address: `17Y1XJiC72f2kyJnzwBdkaPQEGgaD1aroR`

> **Comments:**
> **username_0**: Excellent! Thanks for your prompt answer.  

---

