<p>Format (private keys):</p>

<ul>
<li>uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of
previous 33 bytes], base58 encoded</li>
<li>compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash()
previous 34 bytes], base58 encoded</li>
</ul>

<p>case 1:</p>

<ul>
<li>secret (hex):
1111111111111111111111111111111111111111111111111111111111111111</li>
<li>uncompressed:</li>
<li><ul>
<li>secret (base58): 5HwoXVkHoRM8sL2KmNRS217n1g8mPPBomrY7yehCuXC1115WWsh</li>
</ul></li>
<li><ul>
<li>pubkey (hex):
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1</li>
</ul></li>
<li><ul>
<li>address (base58): 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a</li>
</ul></li>
<li>compressed:</li>
<li><ul>
<li>secret (base58): KwntMbt59tTsj8xqpqYqRRWufyjGunvhSyeMo3NTYpFYzZbXJ5Hp</li>
</ul></li>
<li><ul>
<li>pubkey (hex):
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa</li>
</ul></li>
<li><ul>
<li>address (base58): 1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9</li>
</ul></li>
</ul>

<p>Obtained from the Bitcoin developer mailing list:</p>

<ul>
<li><a href="http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&amp;forum_name=bitcoin-development" rel="noreferrer">http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&amp;forum_name=bitcoin-development</a></li>
</ul>

CC BY-SA 3.0
2012-12-17T12:12:11.047Z
This answer is different from above where the first byte of compressed/uncompressed is (0x04 for uncompressed, 0x02/0x03 for compressed)
makerofthings7
CC BY-SA 3.0
2012-12-17T12:49:29.590Z
It appears that this answer refers to the bitcoin specific import/export format of keys, vs the usage of compressed keys itself namely in OpenSSL.  I hope this helps future readers contrast the two answers here.
makerofthings7
CC BY-SA 3.0
2015-06-15T20:38:40.717Z
The quote is quite misleading. Since it is a quote, it probably should not be edited but “4 bytes of Hash() of previous […] bytes” should have been “4 bytes of Hash(Hash()) of previous […] bytes”. Hash function is applied twice.
akater
CC BY-SA 3.0
2017-09-12T12:23:30.637Z
@Akater hash applied twice is still a hash. Since it doesn't say which function `Hash()` corresponds to, the quote is correct. I don't know which function is used, so maybe e.g. `Hash(x) = SHA256(SHA256(x))`
modular
CC BY-SA 3.0
2012-05-25T01:27:31.027Z
2017-12-19T04:08:03.247Z
2017-12-19T04:08:03.247Z
user479
<p>A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other than that a little bit of additional computation is needed before they can be used to validate a signature.</p>

<p>If you think of a public key as a point somewhere along a giant letter U, an uncompressed key is the <em>x</em> and <em>y</em> coordinates of the point. A compressed key is how high up on the U the point is along with a single bit indicating whether it's on the left or right side. As you can visualize, they both encode precisely the same thing, but the compressed form requires half as much space plus one bit. (Of course, they're really points on elliptic curve <a href="https://en.bitcoin.it/wiki/Secp256k1">secp256k1</a>, but the concept is the same.)</p>

CC BY-SA 3.0
2014-02-19T10:07:48.090Z
So, if I understand correctly, a single private key is always connected to a single public key representable in two different formats, which is connected to two addresses (from whether the compressed and uncompressed form of the key is hashed)? So somebody can send coins to either address, but to use those coins I need to use the right version of the public key (which the newer software will automatically handle and the older software won't?)
Daniel H
CC BY-SA 3.0
2014-05-13T08:21:50.433Z
I have a problem understanding it :  I have an uncompressed private key, I enter it in bitaddress.org, and I get two public addresses : one compressed and one uncompressed. 

On one I have one million dollar, on the other 0. And they both come from the same private key. How does that make sense?
Advanced
CC BY-SA 3.0
2015-05-25T20:44:25.680Z
@Advanced A single private key has a single corresponding public key. But that public key can be expressed in two forms, compressed and uncompressed. Each public key form has a corresponding Bitcoin address. Bitcoins can be sent to addresses without regard for how that address was formed.
David Schwartz
CC BY-SA 3.0
2015-11-03T18:58:43.563Z
@DavidSchwartz The link to Secp256k1 in your post has become broken. But: What an excellent explanation of how this compression is archieved!
Qqwy
CC BY-SA 3.0
2015-11-03T19:00:28.323Z
@Qqwy Thanks. I fixed the link to point to something that is at least a little relevant.
David Schwartz
CC BY-SA 3.0
2012-03-03T10:39:10.920Z
So if the older software encounters a compressed key (how would that happen? in wallet.dat? in the block chain? in a transaction broadcast?) can it handle it?
Thilo
CC BY-SA 3.0
2012-03-03T10:42:00.620Z
No, it can't. But it is always disallowed to try to read a `wallet.dat` file with an earlier version of the software. That's a permitted break. (You could still manually extract the case, uncompress them, and put them into the earlier form if you had to. But that kind of compatibility is not supported. You can't go back with a newer wallet file unless you translate the data.)
David Schwartz
CC BY-SA 3.0
2012-03-03T10:46:14.093Z
To answer your other question, only in the `wallet.dat`. Compressed keys aren't yet supported anywhere else because that would be a protocol-breaking change.
David Schwartz
CC BY-SA 3.0
2012-03-03T11:44:44.020Z
If this is only for wallet.dat, why bother about a few bytes? 31 bytes saved add up to a megabyte only if you have 33.825 keys.
Thilo
CC BY-SA 3.0
2012-03-03T17:24:46.930Z
Old clients can validate transactions with compressed public keys because Bitcoin sends public keys to OpenSSL without checking their format and OpenSSL automatically processes the public key according to the leading byte (0x04 for uncompressed, 0x02/0x03 for compressed).
theymos
CC BY-SA 3.0
2012-03-03T18:22:49.177Z
The advantage is mainly for the blockchain and the network, as transactions will be a bit smaller now. It's 33 bytes instead of 65, by the way.
Pieter Wuille
CC BY-SA 3.0
2012-03-03T10:36:45.947Z
2015-11-03T18:59:43.523Z
2015-11-03T18:59:43.523Z
David Schwartz
<p>It may help to break the fields apart.</p>

<pre>
04
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

03 [could be 02]
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
[discarded value can be computed from above value]
</pre>

<p>There is more detail omitted above. The 03 can be 02 because the
discarded value has to be derived from the preserved value and
one extra bit of info is needed. That is because there are two
roots [plus and minus] when taking a square root.</p>

CC BY-SA 3.0
2013-12-29T04:52:18.013Z
2013-12-29T04:52:18.013Z
Techno CAT
<p>a good explanation is available in <a href="https://bitcoin.stackexchange.com/questions/37373/how-can-i-test-if-a-bitcoin-address-is-compressed-or-not">How can I test if a bitcoin address is compressed or not?</a> </p>

<blockquote>
  <p>More specifically, a public key in Bitcoin is a pair integers (x,y).
  For uncompressed public keys, these integers are encoded as 256-bit
  unsigned big-endian ints, concatenated together, and then prepended
  with a single 0x04 byte. The result is 65 bytes long.</p>
  
  <p>For compressed public keys, only the x coordinate is encoded (like
  above, as 256-bit unsigned big-endian int). It turns out that the y
  coordinate can only be one of two values, one even and one odd.
  Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte
  is prepended depending on y's value (0x02 for even, 0x03 for odd). The
  result is 33 bytes long.</p>
</blockquote>

CC BY-SA 4.0
2020-07-10T07:29:46.697Z
is it 0x02 for y > 0 and 0x03 for y < 0
Cisco Mmu
CC BY-SA 4.0
2021-06-24T19:17:04.573Z
@CiscoMmu how to know if y > 0 or < 0?
J. Does
CC BY-SA 4.0
2021-06-30T11:11:49.813Z
In EC graph, you have 2 points in y coordinate (+ve and -ve) for every one point in x coordinate.
Cisco Mmu
CC BY-SA 3.0
2016-10-06T11:29:57.460Z
2016-10-06T11:29:57.460Z
Badr Bellaj
<p>The standard Bitcoin client in version 0.6 apparently introduces compressed keys.</p>

<p>What are they? Are there any drawbacks to using them? Any incompatibilities with older software? Reductions in cryptographic strength?</p>

<address><cryptography><private-key><public-key>
What is a compressed Bitcoin key?
Thilo
# What is a compressed Bitcoin key?

(Asked by: username_0 on 2012-03-03)

The standard Bitcoin client in version 0.6 apparently introduces compressed keys.

What are they? Are there any drawbacks to using them? Any incompatibilities with older software? Reductions in cryptographic strength?

**Tags:** address, cryptography, private-key, public-key


---

## 4 answers

### Answer by username_5 on 2012-03-03. Score: 67

A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other than that a little bit of additional computation is needed before they can be used to validate a signature.

If you think of a public key as a point somewhere along a giant letter U, an uncompressed key is the *x* and *y* coordinates of the point. A compressed key is how high up on the U the point is along with a single bit indicating whether it's on the left or right side. As you can visualize, they both encode precisely the same thing, but the compressed form requires half as much space plus one bit. (Of course, they're really points on elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1), but the concept is the same.)

> **Comments:**
> **username_0**: So if the older software encounters a compressed key (how would that happen? in wallet.dat? in the block chain? in a transaction broadcast?) can it handle it?  
> **username_5**: No, it can't. But it is always disallowed to try to read a `wallet.dat` file with an earlier version of the software. That's a permitted break. (You could still manually extract the case, uncompress them, and put them into the earlier form if you had to. But that kind of compatibility is not supported. You can't go back with a newer wallet file unless you translate the data.)  
> **username_5**: To answer your other question, only in the `wallet.dat`. Compressed keys aren't yet supported anywhere else because that would be a protocol-breaking change.  
> **username_0**: If this is only for wallet.dat, why bother about a few bytes? 31 bytes saved add up to a megabyte only if you have 33.825 keys.  
> **username_9**: Old clients can validate transactions with compressed public keys because Bitcoin sends public keys to OpenSSL without checking their format and OpenSSL automatically processes the public key according to the leading byte (0x04 for uncompressed, 0x02/0x03 for compressed).  
> **username_10**: The advantage is mainly for the blockchain and the network, as transactions will be a bit smaller now. It's 33 bytes instead of 65, by the way.  
> **username_6**: So, if I understand correctly, a single private key is always connected to a single public key representable in two different formats, which is connected to two addresses (from whether the compressed and uncompressed form of the key is hashed)? So somebody can send coins to either address, but to use those coins I need to use the right version of the public key (which the newer software will automatically handle and the older software won't?)  
> **username_7**: I have a problem understanding it :  I have an uncompressed private key, I enter it in bitaddress.org, and I get two public addresses : one compressed and one uncompressed.   On one I have one million dollar, on the other 0. And they both come from the same private key. How username_14 that make sense?  
> **username_5**: @username_7 A single private key has a single corresponding public key. But that public key can be expressed in two forms, compressed and uncompressed. Each public key form has a corresponding Bitcoin address. Bitcoins can be sent to addresses without regard for how that address was formed.  
> **username_8**: @username_5 The link to Secp256k1 in your post has become broken. But: What an excellent explanation of how this compression is archieved!  
> **username_5**: @username_8 Thanks. I fixed the link to point to something that is at least a little relevant.  

---

### Answer by username_1 on 2012-05-25. Score: 19

Format (private keys):

* uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of
  previous 33 bytes], base58 encoded
* compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash()
  previous 34 bytes], base58 encoded

case 1:

* secret (hex):
  1111111111111111111111111111111111111111111111111111111111111111
* uncompressed:
* + secret (base58): 5HwoXVkHoRM8sL2KmNRS217n1g8mPPBomrY7yehCuXC1115WWsh
* + pubkey (hex):
    044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1
* + address (base58): 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
* compressed:
* + secret (base58): KwntMbt59tTsj8xqpqYqRRWufyjGunvhSyeMo3NTYpFYzZbXJ5Hp
* + pubkey (hex):
    034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
* + address (base58): 1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9

Obtained from the Bitcoin developer mailing list:

* <http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development>

> **Comments:**
> **username_2**: This answer is different from above where the first byte of compressed/uncompressed is (0x04 for uncompressed, 0x02/0x03 for compressed)  
> **username_2**: It appears that this answer refers to the bitcoin specific import/export format of keys, vs the usage of compressed keys itself namely in OpenSSL.  I hope this helps future readers contrast the two answers here.  
> **username_3**: The quote is quite misleading. Since it is a quote, it probably should not be edited but “4 bytes of Hash() of previous […] bytes” should have been “4 bytes of Hash(Hash()) of previous […] bytes”. Hash function is applied twice.  
> **username_4**: @username_3 hash applied twice is still a hash. Since it doesn't say which function `Hash()` corresponds to, the quote is correct. I don't know which function is used, so maybe e.g. `Hash(x) = SHA256(SHA256(x))`  

---

### Answer by username_11 on 2013-12-29. Score: 7

It may help to break the fields apart.

```

04
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

03 [could be 02]
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
[discarded value can be computed from above value]

```

There is more detail omitted above. The 03 can be 02 because the
discarded value has to be derived from the preserved value and
one extra bit of info is needed. That is because there are two
roots [plus and minus] when taking a square root.


---

### Answer by username_12 on 2016-10-06. Score: 5

a good explanation is available in [How can I test if a bitcoin address is compressed or not?](https://bitcoin.stackexchange.com/questions/37373/how-can-i-test-if-a-bitcoin-address-is-compressed-or-not)

> More specifically, a public key in Bitcoin is a pair integers (x,y).
> For uncompressed public keys, these integers are encoded as 256-bit
> unsigned big-endian ints, concatenated together, and then prepended
> with a single 0x04 byte. The result is 65 bytes long.
>
> For compressed public keys, only the x coordinate is encoded (like
> above, as 256-bit unsigned big-endian int). It turns out that the y
> coordinate can only be one of two values, one even and one odd.
> Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte
> is prepended depending on y's value (0x02 for even, 0x03 for odd). The
> result is 33 bytes long.

> **Comments:**
> **username_13**: is it 0x02 for y > 0 and 0x03 for y < 0  
> **username_14**: @username_13 how to know if y > 0 or < 0?  
> **username_13**: In EC graph, you have 2 points in y coordinate (+ve and -ve) for every one point in x coordinate.  

---

