<p>The reason they exist both, is because Satoshi didn't know about compressed public keys, and it was only recently discovered that they would be possible to use without compatibility problems (support only exists as of version 0.6 of the reference client).</p>

<p>The advantage is clear: their public keys are smaller, resulting in smaller transactions on the network, saving block chain size for everyone.</p>

<p>Update: inside SegWit spends, only compressed keys can be used.</p>

CC BY-SA 3.0
2013-01-02T07:02:08.770Z
thanks for the answer, but what i really dont understand is, in terms of usability, how come when i sent to the compressed, the satoshi client recieved the transaction, and when i sent the uncompressed, it did not. also, why do sites such as blockchain.info see them as 2 different addresses. also, is it possible to determine the uncompressed from the compressed, and vice versa?
leximus prime
CC BY-SA 3.0
2013-01-02T12:15:00.207Z
The address is just the hash (in base58 encoding) of the serialized public key. Compressed public keys are a more efficient serialization, so they correspond to a different address. Given a public key, you can determine the "compressed address" and the "uncompressed address", but not from just an address. Clients can only receive coins on compressed addresses if they support compressed public keys in the first place.
Pieter Wuille
CC BY-SA 3.0
2013-11-27T02:16:11.667Z
Still, shouldn't a post-0.6.0 client recognize both the send to the compressed address, and the send to the uncompressed address, because it has the private key sufficient to spend either?
Quizzical
CC BY-SA 3.0
2013-11-27T22:01:13.883Z
What's the point? No peer can have the address for the wrong one in case you only give out one. No need to double the number of addresses checked if we know only one is ever shown.
Pieter Wuille
CC BY-SA 3.0
2014-02-14T13:46:58.193Z
Does this mean if custom software gives out the base58 address for an uncompressed address it is unspendable or that it is spendable through RPC ?
makerofthings7
CC BY-SA 3.0
2014-02-15T14:52:48.053Z
If I want you to pay to a compressed pubkey address, I'll give you a compressed pubkey address. If not, I'll give you an uncompressed one. You cannot even know, and you certainly shouldn't care.
Pieter Wuille
CC BY-SA 3.0
2018-01-01T18:15:08.790Z
Do both a compressed address and its uncompressed one have distinct balances? If then, can I spend (“make a transaction transferring”) the sum of their balances from one of them? (Related: https://bitcoin.stackexchange.com/a/67137/59572.)
Константин Ван
CC BY-SA 3.0
2018-01-01T22:06:52.007Z
Internally Bitcoin does not have a concept of "balance" anywhere. Transactions spend specific explicit outputs of previous transactions. So if you received two payments - whether to the same address or to different addresses - you always need multiple inputs to spend then (which is possible, though makes the transaction larger and thus costlier).
Pieter Wuille
CC BY-SA 3.0
2013-01-01T20:01:36.467Z
2017-10-30T16:21:33.043Z
2017-10-30T16:21:33.043Z
Pieter Wuille
<p>"Still, shouldn't a post-0.6.0 client recognize both the send to the compressed address, and the send to the uncompressed address, because it has the private key sufficient to spend either? – Quizzical Nov 27 '13 at 2:16"</p>

<p>You have a private key? Great! Open bitaddress.org(offline) and scroll to wallet details tab, then enter the private key. You'll find the compressed and uncompressed addresses in the right and left side respectively. Scroll down you'll find the compressed and uncompressed private keys there.
Yes! Private keys when denoted in base 58 check format have different values in compressed and uncompressed form. This was done to ensure that the clients don't get confused as to which address to map (compressed or uncompressed).</p>

<p>The point being: WIF format for every hex private key are different in compressed and uncompressed form.
Hope this answer helps.</p>

CC BY-SA 3.0
2016-05-17T03:47:04.417Z
Posting a secret key into any website is generally a bad idea. These services should really only be used for testing, and even that is arguable.
Alex Waters
CC BY-SA 3.0
2016-05-23T04:25:04.583Z
I said "offline" which means on an airgapped machine. Bitaddress.org is a Java based client side webpage you can easily download the source from git and verify the pgp then use it offline without compromising the security of your private keys.
prof.Zoom
CC BY-SA 3.0
2016-05-23T10:49:31.813Z
@prof.Zoom It's not Java-based. It's JavaScript-based.
UTF-8
CC BY-SA 3.0
2016-05-23T10:51:12.137Z
@AlexWaters How would using them for testing be a bad thing? What are they going to do? Steal the 10 cents you use for testing? Plus, he wrote that you shouldn't do this while you're online.
UTF-8
CC BY-SA 3.0
2017-08-03T19:41:04.610Z
Shouldn't be downvoted, +1 for this non-intuitive nugget: 'Yes! Private keys when denoted in base 58 check format have different values in compressed and uncompressed form' Saved me lots of stress exporting old keys from blockchain.info that showed uncompressed addresses but exported as compressed WIFs. Instead of (offline) bitaddress.org I used: `ku -Wu <compressed WIF>`
Marco Crispini
CC BY-SA 3.0
2016-05-09T03:37:09.827Z
2016-05-23T04:28:05.013Z
2016-05-23T04:28:05.013Z
prof.Zoom
<p>Though Bitcoin initially took only one; the uncompressed public keys, if it then changed to not allow the use of uncompressed keys (and only allowed the use of compressed keys) those people with wallet addresses that correlated to a private key's uncompressed keys would have been unable to access their funds.  </p>

<p>This is because a Public Key:</p>

<blockquote>
  <p>02E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0 (compressed)</p>
</blockquote>

<p>Has an address of</p>

<blockquote>
  <p>1MEqCrJfxPAh2uCcGmAV2Bgkj6qD69XgfF</p>
</blockquote>

<p>While the uncompressed version of that public key:</p>

<blockquote>
  <p>04E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0E44402759C51ED0D3BA2F53E749B30A6D1772F0DAE1E3F465E8C8828DF899FE2 (uncompressed)</p>
</blockquote>

<p>Has an address of </p>

<blockquote>
  <p>1JGTdegLcK8N9mqwhXmGjeUgbQNugii3rm</p>
</blockquote>

<p>If Bitcoin stopped accepting your uncompressed version, you'd have to find a compressed public key that would result in your same address to continue to access your funds.  Doing that is just as difficult and unrealistic as trying to crack the bitcoin algorithm.</p>

CC BY-SA 3.0
2017-10-30T11:22:37.850Z
Good point! I like the fact that one can have 2 address types for the same private key. Migrating to the new compressed public key is the way to go :)
Viet
CC BY-SA 3.0
2017-08-14T18:18:32.317Z
2017-08-14T18:18:32.317Z
Mine
<p>My question is about the difference between compressed keys and addresses, and i know it was addressed in another question but my question is less about the theory and more about how the keys are used practically in Bitcoin.</p>
<p>So heres what I did: I used <code>dumpprivkey</code> for an address <code>183Tw2TqXKkbk5ZeocTYwmxg8x46ADXb6c</code> in the .7.2 client, and got <code>L5DTi7rgqsPg7Vq1vTU2dP2HWMEsNM5w5JCqEDXXXXXXXXXXXX</code>. When i pasted this into <a href="https://www.bitaddress.org" rel="nofollow noreferrer">bitaddress.org's</a> wallet details script it returned several things. First, it showed a different address <code>1FKswUuFsjWKyr4ZPSe3vEpp1iCXXChBZm</code>, but it also showed the address above and said it was the compressed version. I sent like 0.0001 to each of the 2 addresses and my satoshi client only shows a transaction recieved from the 183 (compressed) address.</p>
<p>Can someone please explain in practical terms what the difference is and why they both even exist in Bitcoin? Any help is appreciated.</p>

CC BY-SA 3.0
2013-01-02T07:03:30.723Z
^^ bitaddress.org*
leximus prime
<address>
Why does Bitcoin support both compressed and uncompressed keys/addresses?
leximus prime
# Why does Bitcoin support both compressed and uncompressed keys/addresses?

(Asked by: username_0 on 2012-12-31)

My question is about the difference between compressed keys and addresses, and i know it was addressed in another question but my question is less about the theory and more about how the keys are used practically in Bitcoin.

So heres what I did: I used `dumpprivkey` for an address `183Tw2TqXKkbk5ZeocTYwmxg8x46ADXb6c` in the .7.2 client, and got `L5DTi7rgqsPg7Vq1vTU2dP2HWMEsNM5w5JCqEDXXXXXXXXXXXX`. When i pasted this into [bitaddress.org's](https://www.bitaddress.org) wallet details script it returned several things. First, it showed a different address `1FKswUuFsjWKyr4ZPSe3vEpp1iCXXChBZm`, but it also showed the address above and said it was the compressed version. I sent like 0.0001 to each of the 2 addresses and my satoshi client only shows a transaction recieved from the 183 (compressed) address.

Can someone please explain in practical terms what the difference is and why they both even exist in Bitcoin? Any help is appreciated.

**Tags:** address

> **Comments:**
> **username_0**: ^^ bitaddress.org*  

---

## 3 answers

### Answer by username_1 on 2013-01-01. Score: 24

The reason they exist both, is because Satoshi didn't know about compressed public keys, and it was only recently discovered that they would be possible to use without compatibility problems (support only exists as of version 0.6 of the reference client).

The advantage is clear: their public keys are smaller, resulting in smaller transactions on the network, saving block chain size for everyone.

Update: inside SegWit spends, only compressed keys can be used.

> **Comments:**
> **username_0**: thanks for the answer, but what i really dont understand is, in terms of usability, how come when i sent to the compressed, the satoshi client recieved the transaction, and when i sent the uncompressed, it did not. also, why do sites such as blockchain.info see them as 2 different addresses. also, is it possible to determine the uncompressed from the compressed, and vice versa?  
> **username_1**: The address is just the hash (in base58 encoding) of the serialized public key. Compressed public keys are a more efficient serialization, so they correspond to a different address. Given a public key, you can determine the "compressed address" and the "uncompressed address", but not from just an address. Clients can only receive coins on compressed addresses if they support compressed public keys in the first place.  
> **username_2**: Still, shouldn't a post-0.6.0 client recognize both the send to the compressed address, and the send to the uncompressed address, because it has the private key sufficient to spend either?  
> **username_1**: What's the point? No peer can have the address for the wrong one in case you only give out one. No need to double the number of addresses checked if we know only one is ever shown.  
> **username_3**: Does this mean if custom software gives out the base58 address for an uncompressed address it is unspendable or that it is spendable through RPC ?  
> **username_1**: If I want you to pay to a compressed pubkey address, I'll give you a compressed pubkey address. If not, I'll give you an uncompressed one. You cannot even know, and you certainly shouldn't care.  
> **username_4**: Do both a compressed address and its uncompressed one have distinct balances? If then, can I spend (“make a transaction transferring”) the sum of their balances from one of them? (Related: https://bitcoin.stackexchange.com/a/67137/59572.)  
> **username_1**: Internally Bitcoin does not have a concept of "balance" anywhere. Transactions spend specific explicit outputs of previous transactions. So if you received two payments - whether to the same address or to different addresses - you always need multiple inputs to spend then (which is possible, though makes the transaction larger and thus costlier).  

---

### Answer by username_5 on 2016-05-09. Score: 2

"Still, shouldn't a post-0.6.0 client recognize both the send to the compressed address, and the send to the uncompressed address, because it has the private key sufficient to spend either? – username_2 Nov 27 '13 at 2:16"

You have a private key? Great! Open bitaddress.org(offline) and scroll to wallet details tab, then enter the private key. You'll find the compressed and uncompressed addresses in the right and left side respectively. Scroll down you'll find the compressed and uncompressed private keys there.
Yes! Private keys when denoted in base 58 check format have different values in compressed and uncompressed form. This was done to ensure that the clients don't get confused as to which address to map (compressed or uncompressed).

The point being: WIF format for every hex private key are different in compressed and uncompressed form.
Hope this answer helps.

> **Comments:**
> **username_6**: Posting a secret key into any website is generally a bad idea. These services should really only be used for testing, and even that is arguable.  
> **username_5**: I said "offline" which means on an airgapped machine. Bitaddress.org is a Java based client side webpage you can easily download the source from git and verify the pgp then use it offline without compromising the security of your private keys.  
> **username_7**: @username_5 It's not Java-based. It's JavaScript-based.  
> **username_7**: @username_6 How would using them for testing be a bad thing? What are they going to do? Steal the 10 cents you use for testing? Plus, he wrote that you shouldn't do this while you're online.  
> **username_8**: Shouldn't be downvoted, +1 for this non-intuitive nugget: 'Yes! Private keys when denoted in base 58 check format have different values in compressed and uncompressed form' Saved me lots of stress exporting old keys from blockchain.info that showed uncompressed addresses but exported as compressed WIFs. Instead of (offline) bitaddress.org I used: `ku -Wu <compressed WIF>`  

---

### Answer by username_9 on 2017-08-14. Score: 1

Though Bitcoin initially took only one; the uncompressed public keys, if it then changed to not allow the use of uncompressed keys (and only allowed the use of compressed keys) those people with wallet addresses that correlated to a private key's uncompressed keys would have been unable to access their funds.

This is because a Public Key:

> 02E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0 (compressed)

Has an address of

> 1MEqCrJfxPAh2uCcGmAV2Bgkj6qD69XgfF

While the uncompressed version of that public key:

> 04E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0E44402759C51ED0D3BA2F53E749B30A6D1772F0DAE1E3F465E8C8828DF899FE2 (uncompressed)

Has an address of

> 1JGTdegLcK8N9mqwhXmGjeUgbQNugii3rm

If Bitcoin stopped accepting your uncompressed version, you'd have to find a compressed public key that would result in your same address to continue to access your funds. Doing that is just as difficult and unrealistic as trying to crack the bitcoin algorithm.

> **Comments:**
> **username_10**: Good point! I like the fact that one can have 2 address types for the same private key. Migrating to the new compressed public key is the way to go :)  

---

