How can I convert my private key so public key is compressed?

[medUSA]

Due to the spam attacks in recent months, I was searching for a precise formula to estimate transaction size so I can attach enough fees for a quick conformation. To my surprise, there are 2 formulas:

TX Size = 180 bytes per input + 34 bytes per output + 10 bytes +/- number of inputs

TX Size = 148 bytes per input + 34 bytes per output + 10 bytes +/- number of inputs

Wanting to verify which one is correct, I stumbled upon "uncompressed public keys" and "compressed public keys" (there are always new things to learn about bitcoin). Compressed public keys make transactions smaller! I learnt that this is actually a legacy issue since nearly all current wallets use "compressed public keys". My address is still using "uncompressed public keys" because I created my address a long time ago (on a wallet service who was slow to update).

So all these years, I have been creating "oversized" transactions and they are bloating the blockchain. I checked my private keys of my addresses. My ancient addresses all begin with "5" and my newer addresses begin with "K" or "L". At least, I know that my wallet provider now supports "compressed public keys".

How can I convert my private key so its public key is compressed?

[dsattler]

Please have a look at this utility:

https://github.com/casascius/Bitcoin-Address-Utility

I remember that it does all sorts of bitcoin address manipulation. Compile it and try it! 

[achow101]

If you convert your private key so that your public key is compressed, you will get another bitcoin address. Since the elliptic curve can return 2 points for public keys, the compressed key uses one point, and the uncompressed uses another. This means that there are two public keys for one private key. By changing your key to compressed, you will be using a different address and cannot send Bitcoin from the first which had an uncompressed key.

[Muhammed Zakir]

From an EC point of view, you have one private key with one corresponding public key.

The problem is, public keys can be serialized in two ways - compressed (33 bytes) or uncompressed (65 bytes). One is slightly harder to deal with, but as storage space is more critical in Bitcoin, we prefer to use the compressed one. Thus, we now have one private key that corresponds to (from Bitcoin's point of view, as we deal with the serialized versions) two public keys. Each of these public keys has an address (as the hash is calculated from the serialized public key). So, 1 private key, 2 public keys, 2 addresses.

So when you want to import a private key, the software has to know which of the public keys (with corresponding address) should be used. The solution is to add a flag bit to the base58 encoding of the private key, notifying the importer whether or not to use the compressed public keys. Typically, these get called compressed and uncompressed private keys - but it's really just a bit saying whether the corresponding public key is compressed or not.

The only reason not to use a compressed public key is that not all software supports it (they were introduced in Bitcoind/Bitcoin-Qt 0.6 only).

 -snip-

* Bolding is my courtesy.

[medUSA]

Thanks everyone for you replies. I have been reading a bit on these WIF format and how the keys are generated. I don't fully understand the technical stuff but I believe I cannot convert an "uncompressed public key" to a "compressed public key" without changing my address.

If you convert your private key so that your public key is compressed, you will get another bitcoin address. Since the elliptic curve can return 2 points for public keys, the compressed key uses one point, and the uncompressed uses another. This means that there are two public keys for one private key. By changing your key to compressed, you will be using a different address and cannot send Bitcoin from the first which had an uncompressed key.

knightdk have said it. I don't want to believe it, but that's how it is.  

My address is derived from the hash of my public key. If I convert my public key from uncompressed to compressed, while they represent the same point on the elliptic curve, my public key will be different. The hash of it will also be different, hence a new address. So, there is little point in "converting" my old private key to use a "compressed public key" because it's the same as generating a new address.

[domob]

Thanks everyone for you replies. I have been reading a bit on these WIF format and how the keys are generated. I don't fully understand the technical stuff but I believe I cannot convert an "uncompressed public key" to a "compressed public key" without changing my address.

Yes, exactly.  You can use the "same" private key as in 256-bit secret, but changing from uncompressed to compressed changes all of:  WIF private key, public key, address.