SEC defines three types: 0x00 = point at infinity, 0x02 and 0x03 = compressed, 0x04 = uncompressed
02 basically means even y-point, 03 means odd y-point, thus:
uncompressed pubkey = chr(4) + 32-byte x + 32-byte y
compressed pubkey = chr(1 + (y & 1)) + 32-byte x
Also see http://github.com/joric/pywallet (I updated it recently, now it supports compressed keys).
Using OpenSSL you just have to set point conversion via EC_KEY_set_conv_form().
Topic: The prefix byte (0x04) in public keys (Read 2567 times)
Correct. The public key format is managed by OpenSSL, bitcoin treats it as a black box.
Quote
Isn't it a way to differentiate testnet addresses also ?
See my diagram on address calculations. The extra byte for the network gets added to the ripemd160(sha256()) digest. The 0x04 is appears to be constant across all networks (definitely the same on the test-network)
http://dl.dropbox.com/u/1139081/BitcoinImg/PubKeyToAddr.png
Isn't it a way to differentiate testnet addresses also ?
No, DER is used for signatures, but not for public keys. Several encodings of keys are possible (including patented compressed coordinates), but as Bitcoin depends (through the specification of addresses as ripemd160(sha256(pubkey))) on a normalized encoding, i think it is safe the 0x04 will always be there in the current generation of addresses.
So is this related to DER? Looks too lite to be DER (which is similarly used for signatures, but there's like 8 extra bytes floating around).
Is it safe to assume that 0x04 will always be there?
Is it safe to assume that 0x04 will always be there?
Bitcoin uses the standard encoding for public keys, as described in http://www.secg.org/index.php?action=secg,docs_secg. The prefix byte is there to distinguish between several encodings - with 0x04 denoting uncompressed coordinates.
I can't point to anything useful, but can vouch for the fact that it must be there when converting a public key to a bitcoin address (via sha256/ripemd160).
I haven't found any documentation mentioning why we have this extra byte in every public-key serialization. For reference, a public key is always serialized as 65 bytes: (0x04 | PubKeyX(32B) | PubKeyY(32B)), but that 0x04 byte doesn't appear to serve a purpose. If I had to guess, I would think it's to identify the length of the ECDSA key, in multiples of 64 bits / 8 bytes. Or maybe it's the encryption type...?
I hate having to hard-code random bytes into my source files, when it's possible they are actually variable and useful.
I hate having to hard-code random bytes into my source files, when it's possible they are actually variable and useful.
Jump to: