<blockquote>
<p>My understanding is that the public key can start with 04 if it's uncompressed, or 02(x-coor) or 03(y-coor) if it's compressed.</p>
</blockquote>
<p>That's not exactly right. There are two encodings:</p>
<ul>
<li>Uncompressed encoding: (0x04, X coordinate, Y coordinate)</li>
<li>Compressed encoding:
<ul>
<li>(0x02, X coordinate) if Y is even</li>
<li>(0x03, X coordinate) if Y is odd</li>
</ul>
</li>
</ul>
<blockquote>
<p>What's the purpose of this?</p>
</blockquote>
<blockquote>
<p>And if this is indeed the case, why would you want a compressed public key?</p>
</blockquote>
<p>If you're asking about intent, you need to be aware that these standards for encoding aren't specific to Bitcoin. They're defined by <a href="https://www.secg.org/sec1-v2.pdf" rel="nofollow noreferrer">SEC1</a>, and adopted by many other systems. Presumably their goal for having both is:</p>
<ul>
<li>Compressed encoding is smaller, and thus desirable when space/bandwidth considerations matter more.</li>
<li>Uncompressed encoding is slightly more efficient to work with, so if space/bandwidth isn't a concern it's faster to choose this.</li>
</ul>
<p>If Bitcoin was designed today, it would probably only have compressed keys.</p>
<blockquote>
<p>Greater entropy as we can have a larger public key if it's uncompressed?</p>
</blockquote>
<blockquote>
<p>Wouldn't it be safer to use the larger one?</p>
</blockquote>
<p>No, there is a one-to-one conversion between compressed and uncompressed keys, in both direction. There is no difference in entropy (both have 256 bits of entropy) and thus equally secure.</p>

CC BY-SA 4.0
2021-04-05T17:50:33.967Z
There's five encodings if you want to parse all of the ones in the Bitcoin blockchain, though I guess that's not valid to be used today.
Claris
CC BY-SA 4.0
2021-04-05T17:53:22.187Z
You mean the hybrid encoding? Yeah, that exists too. Its reason for existence is a pure mystery to me (it has the disadvantages of both...).
Pieter Wuille
CC BY-SA 4.0
2021-04-05T17:55:30.283Z
That's the one, I'd forgotten the name, `0x05` and `0x06`. I would love to be able to find the any justification for its existence, surely someone somewhere had a use-case, surely.
Claris
CC BY-SA 4.0
2021-04-05T17:57:10.683Z
0x06 and 0x07 actually ;)
Pieter Wuille
CC BY-SA 4.0
2021-04-05T19:55:22.107Z
Right, right. What do you think `0x05` was? I'm thinking it only encodes `y`, twice.
Claris
CC BY-SA 4.0
2021-04-05T19:58:27.823Z
There is no 0x05 as far as I know. The idea I think is that the top 7 bits encode the mechanism (0 = infinity, 1 = compressed, 2 = uncompressed, 3 = hybrid), and the bottom bit encodes Y's parity (but only for compressed and hybrid modes where it matters).
Pieter Wuille
CC BY-SA 4.0
2021-04-06T02:00:14.393Z
Thank you, great explanation! Trying to wrap my head around Bitcoin addresses and this is great stuff. I read today that the private key (a 2^256 bit number) is the number of times the generative points in the elliptic curve function are computed to compute the public key -- the x and y coordinates are used at the last computed point. Is this correct?
Gary
CC BY-SA 4.0
2021-04-06T03:13:21.250Z
Yes, though "times" isn't your normal multiplication here. It's the number of times the elliptic curve group operation is applied to the generator point ("adding" it to itself).
Pieter Wuille
CC BY-SA 4.0
2021-04-05T17:38:21.670Z
2021-04-05T17:38:21.670Z
Pieter Wuille
<p>My understanding is that the public key can start with 04 if it's uncompressed, or 02 or 03 if it's compressed.</p>
<p>What's the purpose of this?</p>
<p>It appears that you'd have greater entropy if it's uncompressed.</p>
<p>And if this is indeed the case, why would you want a compressed public key?</p>
<p>Wouldn't it be safer to use the larger one?</p>

<public-key>
Bitcoin public key — why do we have a compressed and uncompressed version?
Gary
# Bitcoin public key — why do we have a compressed and uncompressed version?

(Asked by: username_0 on 2021-04-05)

My understanding is that the public key can start with 04 if it's uncompressed, or 02 or 03 if it's compressed.

What's the purpose of this?

It appears that you'd have greater entropy if it's uncompressed.

And if this is indeed the case, why would you want a compressed public key?

Wouldn't it be safer to use the larger one?

**Tags:** public-key


---

## 1 answers

### Answer by username_1 on 2021-04-05. Score: 3 | Accepted answer

> My understanding is that the public key can start with 04 if it's uncompressed, or 02(x-coor) or 03(y-coor) if it's compressed.

That's not exactly right. There are two encodings:

* Uncompressed encoding: (0x04, X coordinate, Y coordinate)
* Compressed encoding:
  + (0x02, X coordinate) if Y is even
  + (0x03, X coordinate) if Y is odd

> What's the purpose of this?

> And if this is indeed the case, why would you want a compressed public key?

If you're asking about intent, you need to be aware that these standards for encoding aren't specific to Bitcoin. They're defined by [SEC1](https://www.secg.org/sec1-v2.pdf), and adopted by many other systems. Presumably their goal for having both is:

* Compressed encoding is smaller, and thus desirable when space/bandwidth considerations matter more.
* Uncompressed encoding is slightly more efficient to work with, so if space/bandwidth isn't a concern it's faster to choose this.

If Bitcoin was designed today, it would probably only have compressed keys.

> Greater entropy as we can have a larger public key if it's uncompressed?

> Wouldn't it be safer to use the larger one?

No, there is a one-to-one conversion between compressed and uncompressed keys, in both direction. There is no difference in entropy (both have 256 bits of entropy) and thus equally secure.

> **Comments:**
> **username_2**: There's five encodings if you want to parse all of the ones in the Bitcoin blockchain, though I guess that's not valid to be used today.  
> **username_1**: You mean the hybrid encoding? Yeah, that exists too. Its reason for existence is a pure mystery to me (it has the disadvantages of both...).  
> **username_2**: That's the one, I'd forgotten the name, `0x05` and `0x06`. I would love to be able to find the any justification for its existence, surely someone somewhere had a use-case, surely.  
> **username_1**: 0x06 and 0x07 actually ;)  
> **username_2**: Right, right. What do you think `0x05` was? I'm thinking it only encodes `y`, twice.  
> **username_1**: There is no 0x05 as far as I know. The idea I think is that the top 7 bits encode the mechanism (0 = infinity, 1 = compressed, 2 = uncompressed, 3 = hybrid), and the bottom bit encodes Y's parity (but only for compressed and hybrid modes where it matters).  
> **username_0**: Thank you, great explanation! Trying to wrap my head around Bitcoin addresses and this is great stuff. I read today that the private key (a 2^256 bit number) is the number of times the generative points in the elliptic curve function are computed to compute the public key -- the x and y coordinates are used at the last computed point. Is this correct?  
> **username_1**: Yes, though "times" isn't your normal multiplication here. It's the number of times the elliptic curve group operation is applied to the generator point ("adding" it to itself).  

---

