Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I am looking into implementing support for compressed public keys on Vanity Pool. However, I have my concerns about importing solutions into a desired vanity address under that format. From what I can see about the explanation how a compressed key format works, it appears that one private key can map into two different Bitcoin Addresses.
Is there some way to specify in the Standard Client which format is to be used for importing, or will one of the formats be preferred all the time?
From a cryptographic point of view, there is just one type of private keys and one type of public keys. A private key is an integer in the range 1 to 115792089210356248762697446949407573529996955224135760342422259061068512044368, a public key is a point on the elliptic curve secp256k1. No magic here.
The problem is that Bitcoin uses addresses, and addresses are derived from the hash of a public key. As you cannot take a hash of the mathematical concept of a "point", it needs to be converted to a byte sequence first. The standard Bitcoin follows, however defines two ways of converting a public key to a byte sequence: a normal one (resulting in 65 bytes) or a compressed one (resulting in 33 bytes). There is no reason to use the normal one, except of course compatibility. As the resulting byte sequence is different in both encodings, the address will be different as well. If coins were sent to one address, the public key encoding that exactly matches it needs to be used to spend them.
Thus, in order to support both, we must remember for each public/private keypair whether the normal or compressed encoding is to be used. As you point out, we also need this information when importing a private key. To do so, the "Wallet Import Format" for private keys (the base58 form, typically starting with a '5'), was extended. If the public key/address for a particular private key are to be derived from the compressed encoding of the public key, the private key gets an extra 0x01 byte at the end, resulting in a base58 form that starts with 'K' or 'L'.
So to answer your question: when importing a private key into the reference client, it will use the normal encoding for public keys if the '5' format was used for the private key, and the compressed encoding if the 'K'/'L' format was used. It doesn't make sense to try to convert one to the other: the client must use the same encoding as was used when generating the address, or the address won't match. Unfortunately, quite a lot of software doesn't support compressed public keys yet (which is a pity, as they save block chain space).
