I went onto https://www.bitaddress.org and the last tab there is a place to enter a private key and it shows the various formats of public and private keys.
It is strange to me that the public key can either be 33 Base58 or 130 Base16. It doesn't seem right, especially since the private key is 51 Base58 or 64 Base16 which makes sense.

So what gives? Here is a printscreen:

Bitcoin Address (33 or 34 characters, starts with a '1'): 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm

Public Key (130 characters [0-9A-F]): 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F8179 8483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8


  • What makes you think the public key can be 33 base 58? It most certainly cannot be. Commented Mar 1, 2012 at 6:38
  • 2
    He was thinking his bitcoin address was the same thing as his public key, just in a different format, as opposed to just being a hash of his public key, containing much less information. Commented Mar 1, 2012 at 18:38

2 Answers 2


Bitcoin private keys are 32 bytes, but are often stored in their full OpenSSL-serialized form of 279 bytes. They are serialized as 51 base58 characters, or 64 hex characters.

Bitcoin public keys (traditionally) are 65 bytes (the first of which is 0x04). They are typically encoded as 130 hex characters.

Bitcoin compressed public keys (as of 0.6.0) are 33 bytes (the first of which is 0x02 or 0x03). They are typically encoded as 66 hex characters.

Bitcoin addresses are RIPEMD160(SHA256(pubkey)), 20 bytes. They are typically encoded as 34 base58 characters.

  • 1
    So let me test my understanding: The private key is 32 bytes and the public key has an x and a y component of some magical curve making it 64 bytes. I suppose in the early days they used the full public key. It was good, but it needed a checksum and a prefix to prevent against accidental misuse. But when they added this it became too long, people complained, so they added some compression and shortened it up. What we now call the bitcoin address is 20 bytes now. Is this roughly correct? Commented Mar 3, 2012 at 23:24
  • Note that point compression (turning a 65 byte pubkey into a 33 byte one) is not the same as hashing (which is done for addresses). Commented Mar 6, 2012 at 15:03
  • Also, the hashing and adding of a checksum was always done in addresses. It's just that originally addresses weren't intended to be the norm for doing transactions (using "IP Transactions", which negotiated the pubkey directly). Commented Mar 6, 2012 at 15:04

Your public key is 65 bytes of data: A leading 0x04 byte followed by 32 bytes for the X coordinate and 32 bytes for the Y coordinate of the point it represents. It takes 130 hex characters at 4 bits per character to display the full key.

Your bitcoin address is a hash of your public key. It's a little more complex than that, involving multiple hashes and a built-in checksum, but that's basically true.

It's not possible to get from your bitcoin address to your public key. There are many public keys which have the same bitcoin address. The corresponding private key is able to spend the funds on that address if the funds were sent using the official client. It's incredibly hard to find a keypair with the same bitcoin address as an existing address. The check for spendability for funds sent to a bitcoin address is:

The spender of a transaction's output:

  • must supply a public key which hashes to the address specified by the creator of that transaction, and
  • must be abe to demonstrate that he holds the corresponding private key by signing his new transaction with it

At no point is there a check that the spender has the same public key as the intended recipient. Indeed, the creator of a transaction doesn't know the public key of the intended recipient, only his bitcoin address.

  • Check the (new) first link on the my answer. I linked it to the wiki's ECDSA page which talks about key sizes. Commented Mar 2, 2012 at 23:04
  • Compressed public keys, which will be used as of bitcoin 0.6.0, are only 33 bytes. Commented Mar 2, 2012 at 23:17

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.