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 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.


3 Answers 3


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.

  • 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? Jan 2, 2013 at 7:02
  • 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. Jan 2, 2013 at 12:15
  • 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, 2013 at 2:16
  • 2
    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. Nov 27, 2013 at 22:01
  • 4
    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. Feb 15, 2014 at 14:52

"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"

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.

  • 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. May 17, 2016 at 3:47
  • 2
    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
    May 23, 2016 at 4:25
  • 1
    @prof.Zoom It's not Java-based. It's JavaScript-based.
    – UTF-8
    May 23, 2016 at 10:49
  • @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
    May 23, 2016 at 10:51
  • 1
    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> Aug 3, 2017 at 19:41

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


While the uncompressed version of that public key:

04E9A095A6A5790BC82FEADE07EE6FC77B05BC4DE7F3790C36D2ECC886D9EC0AC0E44402759C51ED0D3BA2F53E749B30A6D1772F0DAE1E3F465E8C8828DF899FE2 (uncompressed)

Has an address of


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.

  • 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
    Oct 30, 2017 at 11:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.