Two Bitcoins addresses for the same public key?

[BurtW]

The address is the hash of the public key.

The public key can be compressed or uncompressed.

The hash of the compressed form would be different than the hash of the uncompressed form.

So, can you have two addresses for the same public key or is the address defined/specified as the hash of only one of the forms of the public key?

[Mike Hearn]

Wallet software is expected to know which form is "correct" for any given private key. In theory you could have two addresses for each key but no software actually implements that vs the tracking solution.

[kjj]

The confusion comes in when two distinct concepts have the same name.

"private key" can mean either the raw 256 bits used to calculate the signature, or it can mean the encoded format that bitcoin stores.

Public key can also mean either the (x,y) point used to verify signatures, or it can mean the encoded version that bitcoin uses.

In the raw sense, both private keys are the same, and both public keys refer to the same (x,y) point.  In the encoded sense, the compressed private key encoding implies the compressed public key encoding, and ditto for the uncompressed encodings.  The addresses are hashed from the encoded forms, so there are two different addresses that technically refer to the exact same keypair.

Since bitcoin deals exclusively with encoded versions, the two formats are totally distinct different things.  If you generate your own raw private key, you can create both encodings and calculate both addresses.  Import the two encodings into different wallets, and neither one will have any idea about transactions sent to the other.  Even though they could calculate signatures for both, they don't know to look for them.

[Mike Hearn]

You can't compress a private key, only public keys.

[gmaxwell]

The confusion comes in when two distinct concepts have the same name.

THREE. Three concepts in one name!

A public key is also a "script pubkey"— a sequence of instructions in bitcoin script that provide the rules for spending a coin.

A private key is also all the data you need to completely compose a scriptsig for a script pubkey.

This third set of definitions, while perhaps the least conventional, are the ones that actually matter when it comes to creating transactions. Once you use these definitions it's no longer surprising that "compressed or not" results in a distinct keypair, all other things equal— just as adding a hash-preimage check to a script would show up in the pubkey and require the right preimage as part of the private key.

[BurtW]

I see.

Where are we on creating a standard, and actual document, for Bitcoin.  Has anyone started a project in IEEE or any other standards body?

This is the kind of thing that I should be able to find in a documented standard.

[dserrano5]

A public key is also a "script pubkey"— a sequence of instructions in bitcoin script that provide the rules for spending a coin.

Why this name? Shouldn't that be called "redeem script" or something like that? (yeah I know there's a redeemScript related to multisig addresses but that's a relatively recent development).

[gmaxwell]

Why this name? Shouldn't that be called "redeem script" or something like that? (yeah I know there's a redeemScript related to multisig addresses but that's a relatively recent development).

Because in the bitcoin system these scripts are the public key and signature.  The naming its accurate.

[mmeijeri]

Why are addresses calculated from a hash of the public key, rather than using the public key itself? I understand why you would want to add a checksum to guard against typos, but why not append the checksum to the public key rather than its hash? Is it merely a matter of wanting to make the address shorter or is there a deeper reason?

[jackjack]

Why are addresses calculated from a hash of the public key, rather than using the public key itself? I understand why you would want to add a checksum to guard against typos, but why not append the checksum to the public key rather than its hash? Is it merely a matter of wanting to make the address shorter or is there a deeper reason?

This
A public key is 65 or 33 bytes long
A hash160 ( == ripemd160(sha256(x)) ) is 20 bytes long

Also a bit of further security. Currently you need a signature AND the public key to redeem a transaction output. So even if someone breaks secp256k1, they would have to break ripemd260 and sha256 too to redeem that output.
Except if that public key already redeemed an output once, in that case it is known:
 - unused address (notice "Public key: Unknown (not seen yet)")
 - used address (notice "Public key: 020338ce822bbf15ef68145e0d5a4838d8a2eb746ff024c1944e8d4f49c0574c55")