Bitcoin Forum

i was thinking and i make a few tests...
i can create 2 different addresses with the same privkey
just using the compressed and the uncompressed pubkey
what you guys think about this?

You are correct.

Why do you ask?

Well not pedantically. Its most logical to consider the compressed/uncompressed flag to be part of a private key... in that logically a private key is _all_ the information required to create a pubkey and to prove you created the pubkey.  Of course, if you permit twiddling arbitrary parts of a private key I can create countless pubkeys. There is a third state too, for that matter.


It isn't the case for conventional EC with conventional serializations, but it's also the case that some public key systems are not unique. E.g. if we seralized the points as Jacobian coordinates there would be ~2^256 distinct pubkeys.

just start a discussion...

Interestingly, this would seem to indicate that there are actually 2²⁵⁷ private keys rather than the often quoted 2²⁵⁶.

Additionally, each address would seem to have, on average, both 2⁹⁶ different private keys with the "compressed bit" that can provide a valid signature AND an additional 2⁹⁶ different private keys without the "compressed bit" that can also provide a valid signature.

Not exactly. Technically, there are less than 2^256 different values because of the order of the underlying finite group but it's not important.
Once you have the exponent and therefore the EC point, there is an infinite way to serialize it. Early version of bitcoin core used the 'uncompressed' DER form. Once hashed and base58 encoded , it gives the address. Because different serializations lead to different addresses, the private key is marked with an additional byte to indicate the usage of compression.
Now we can invent new representations at will - it's just a change of coordinates. In jacobian form, the coordinate is a triplet and introduces an additional degree of freedom. Hence ~2^256 more combinations. But at the end though it's the same points. If bitcoin core accepted this form, the private key would have to add 32 bytes and surely, we surely wouldn't have created 2^512 keys.

Yup, you are right! If you try to create a transaction hash for example, you can see that the length of the hash is smaller if you use the compressed version. You can use either. They're basically the same thing. One just pollutes the blockchain more than the other when you broadcast a transaction, so it would make more sense to go with the compressed version if you had to choose.