Glossary / Addresses & keys
Compressed public key
- Definition
- A compressed public key stores only the x coordinate of a curve point plus a one byte parity flag, fitting a full public key into 33 bytes instead of 65.
Every point on secp256k1 has two possible y values for a given x, so recording which one it is costs a single byte rather than 32. Wallets have generated compressed keys by default since Bitcoin Core 0.6, released in March 2012, and the saved bytes come off the size of every input you later spend. Cheaper spending is the entire payoff, and the format is invisible in daily use.
How it works
Public key compression is algebra rather than data compression. The curve equation, y squared equals x cubed plus 7, has at most two solutions for y at any given x, and those two solutions are always one even number and one odd number. Storing x plus one bit of information about which solution applies is therefore enough for anyone to recover the point exactly, by solving the equation and picking the root with the right parity.
The encoding puts that bit in the leading byte. A prefix of 0x02 means the y value is even, 0x03 means it is odd, and the 32 bytes that follow are the x coordinate. Total length: 33 bytes. The old format signals itself with a 0x04 prefix and carries both coordinates in full, for 65 bytes. Any software reading a key can tell the two apart from the first byte alone, which is how wallets stayed compatible through the transition.
The 32 bytes saved land in different places depending on the output type. In a legacy input the key sits in the unlocking script and is charged at full weight, so 32 bytes cost 32 vbytes, about 640 satoshis at a 20 sat/vB fee rate. In a SegWit input the key sits in the witness, which is discounted fourfold, so the same 32 bytes cost 8 vbytes. Neither figure is dramatic on its own, and both repeat on every input of every transaction you ever sign.
Where you see it
You meet compressed keys in raw transaction data. Open any recent spend in a block explorer and the public key in the witness or script will begin with 02 or 03, followed by 64 hexadecimal characters. Keys starting with 04 are relics.
The format also decides what an address looks like. Hashing a compressed key gives a different result from hashing the uncompressed version of the same key, so one private key can correspond to two entirely separate legacy addresses with separate balances. Wallets handle this by convention rather than by cleverness: everything derived through BIP-32, which covers every seed phrase wallet in ordinary use, is compressed throughout, and a Wallet Import Format string beginning with K or L announces that the key belongs to the compressed side of that fork.
SegWit removed the ambiguity for good. BIP-143 forbids uncompressed keys inside version 0 witness programs, so any bc1q address is compressed by rule, and Taproot went further by defining x-only 32-byte keys that drop the parity byte altogether.
Compressed public key vs uncompressed public key
The compressed and uncompressed forms encode the same point, and the difference is only what has to be written down. The compressed form keeps x and derives y when needed, which costs a few microseconds of arithmetic and saves 32 bytes forever. The uncompressed form stores y outright, which saved computation on hardware from 2009 and now buys nothing. Because the two byte strings differ, they hash to different addresses, and that mismatch, rather than the byte count, is what occasionally strands funds from very old wallets.