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.


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? – leximus prime Jan 2 '13 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. – Pieter Wuille Jan 2 '13 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 '13 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. – Pieter Wuille Nov 27 '13 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. – Pieter Wuille Feb 15 '14 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. – Alex Waters May 17 '16 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 '16 at 4:25
  • 1
    @prof.Zoom It's not Java-based. It's JavaScript-based. – UTF-8 May 23 '16 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 '16 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> – Marco Crispini Aug 3 '17 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 '17 at 11:22

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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