Why do compressed and uncompressed public keys have to produce different addresses?

Question

I am reading through the "Mastering Bitcoin" book. I understand that in the beginning the public key was both the x and y on the elliptic curve. Then it was optimized to only contain the x, and the y could be derived by solving the curve equation. In practice wallet A and wallet B may generate different public key (assuming one uses the compressed and the other uses the uncompressed algo) Different public keys will hash to different addresses and this is a problem - wallets don't know where to look for coins when importing private keys. That is fixed by adding stuff to the private key to designate which version is used.

I hope I understand correctly up until this point.

My question is: Why can't you just uncompress the compressed public key (effectively making it an uncompressed public key) and then derive the address. That way even if you use the compressed key, address will be exactly the same as the uncompressed one?

Answer 1

My question is: Why cant you just uncompress the compressed public key (effectively making it an uncompressed public key) and then derive the address. That way even if you use the compressed key, address will be exactly the same as the uncompressed one?

You certainly could, but you don't want to. At spending time, the public key is revealed in the spending transaction. That revealed public key must match whatever the address's embedded hash demands. If the address was computed off a compressed public key, the compressed public key must be revealed. If the address was computed off an uncompressed public key, the uncompressed public key must be revealed.

The point of switching to compressed public keys was using less on-chain chain space, and thus indirectly paying less fees (as fees scale proportionally to used on-chain space). If you'd derive the address by decompressing the compressed keys, you'd lose out on the point of using compressed keys in the first place.

Note that uncompressed keys are very rare these days. Almost all wallet software written since ~2012 exclusively uses compressed keys. BIP32 (a common mechanism form generating wallet keys deterministically, introduced in 2013) only supports compressed keys. When using segwit scripts (BIP141, introduced in august 2017), only compressed keys are supported (using uncompressed keys in segwit will cause transactions to not be relayed). The confusion between the two is mostly a non-issue nowadays.

Disclaimer: I'm the author of BIP32, and a co-author of BIP141.