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.
- snip -
Interestingly, this would seem to indicate that there are actually 2
257 private keys rather than the often quoted 2
256.
Additionally, each address would seem to have, on average, both 2
96 different private keys with the "compressed bit" that can provide a valid signature AND an additional 2
96 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.
