# How are compressed PubKeys generated?

What is the process to generate compressed pub keys via ECDSA?

• interested to hear the responses - I thought the privkey and pubkey were only linked via ECDSA. Both are simply hex numbers... (of points on the curve tralala). And using the privkey base58encoded, goes to the WIF privkey. Added an additional hex "01" before encoding, I have a WIF-c (compressed) privkey, from which I derive compressed pubkey. Waiting for the answers... Commented Jan 23, 2018 at 17:57

There is no algorithm for generating compressed pubkeys from private keys keys specifically. In fact, all internal calculations involving points are done using the both the `x` and `y` coordinates of the points involved. There is no other way to operate on points other than using the `(x,y)` coordinates. A compressed representation of the point is useful in data transmission and storage because it only takes 33 bytes as opposed to 65 bytes to convey the point. It's very easy to go from `compressed -> uncompressed` when the need arise to perform point related operations, and even easier to go from `uncompressed -> compressed` representation. To answer your question, you would generate the public key as you normally would with an uncompressed pubkey, and when you're done, look for even-ness or odd-ness of the `y` corrdinate. If it is even, encode only the `x` coordinate with a prefix `0x02` byte, and if it's odd the prefix is `0x03`. To go back from `compressed -> uncompressed` (really I just mean find the original `y` coordinate), you would just solve the curve's equation :

`y^2 = x^3 + a*x + b`

Specifically for secp256k1, the curve used in Bitcoin, `a` is zero, which makes this calculation easier, and there is a shortcut: due to a property of the curve's parameter `p`, where `p ≡ 3 mod 4` we are able to derive the `y` coordinate from an `x` coordinate simply by calculating:

``````q = (p+1) * invmod(4)  mod p
y = powmod(y^2,q)      mod p
``````

And there we have the original `y` coordinate back.

• "it takes 33 bytes as opposed to 65 bytes to convey the point" - does it include the prefixes for the point calculations? Commented Jan 23, 2018 at 23:06
• The prefix is only used by software reading and writing the point as data. It hints the software at what type of key is being read, and if it's a compressed key, which of the two possible `y` coordinates it should choose when uncompressing the point. Commented Jan 24, 2018 at 6:44

with a little bit help from arubi, I came to draw this picture. The blue part is the ECDSA logic. WIF keys and privkeys are linked via base58check en-/decoding. Depending on how you provide the privkey (compressed or uncompressed), the software decides how to create the pubkey and the bitcoin address. Obviously the bitcoin address will differ for compressed/uncompressed keys. With uncompressed keys you have the 512bit pub key with the x/y components, whereas the compressed pub key can be represented as only the x-component. The software would add the prefix 04 for uncompressed, or 02 (if even y) or 03 (if uneven y), and use it as input to sha256/ripemd160 to create the pubkey hash. With the last step there is again base58check encoding, with a checksum involved.

Example (testnet):

``````privkey Hex:   18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
privkey WIF-c: cNR4jZU2sR5goytD4wXT4aeKcbqGSekbxLxY69v8aryxTU1SMnJZ
``````

pubkey hex uncompressed (04 + x + y):

pubkey hex compressed (02 + x, y=even):

``````  (pubkey uncompressed): mfcSEPR8EkJrpX91YkTJ9iscdAzppJrG9j
• Nice diagram! For completeness, there is another valid public key type other than compressed and uncompressed, which is called 'Hybrid'. It encodes both the `x` and `y` coordinates, and its length is 1 + 64 bytes (like an uncompressed pubkey), but the prefix byte could be either `0x07` or `0x06`. Commented Jan 24, 2018 at 18:55
• Basically, the even-ness or odd-ness of the prefix byte hints at the even-ness or odd-ness of the `y` coordinate encoded in the key. I don't think a hybrid key has ever been used on mainnet, but still it is a valid pubkey and can appear in a script. There is no WIF encoding of a hybrid private key, but anyone could sign and redeem a p2pkh script using such a key, and we would not know until it is relayed for spending. Incorporating it into your diagram, the pubkey would be an input to the thrid step. Commented Jan 24, 2018 at 18:55