How are compressed PubKeys generated?

Question

Just read this: https://bitcoin.stackexchange.com/a/1715/

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

Answer 1

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.

Answer 2

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:   91msh178DnLBqFhbuYqazuUwWpKBkRQvgj8bggdWMp81nVp9PfM
privkey WIF-c: cNR4jZU2sR5goytD4wXT4aeKcbqGSekbxLxY69v8aryxTU1SMnJZ

pubkey hex uncompressed (04 + x + y):

04 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

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

02 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352

coresponding bitcoin addresses:

  (pubkey uncompressed): mfcSEPR8EkJrpX91YkTJ9iscdAzppJrG9j
  (pubkey compressed):   n3svudhm7bt6j3nTT9uu1A57Cs9pKK3iXW