# 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... 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? 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. 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):