|
October 28, 2013, 07:43:32 AM |
|
Currently, Bitcoin private and public keys have the following data types:
* Uncompressed private key: 64 hex bytes, eg:
a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3
* Uncompressed public key: 04 + x coordinate + y coordinate
04be686ed7f0539affbaf634f3bcc2b235e8e220e7be57e9397ab1c14c39137eb43705125aac75a 865268ef33c53897c141bd092cf4d1a306b2a57e37e1386826d
* Compressed public key: 02 or 03 (depending on whether y is odd or even) + x coordinate
03be686ed7f0539affbaf634f3bcc2b235e8e220e7be57e9397ab1c14c39137eb4
* Private key intended to become a compressed key: key + '01'
a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae301
* BIP32 internal format for a private key intended to become a compressed key: '00' + key
00a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3
There is an obvious problem here: the compressed public key encoding and the private key encoding are ambiguous. For example, consider the string:
02d20bbd7e394ad5999a4cebabac9619732c343a4cac99470c03e23ba2bdc2bc01
This can be seen in one of two ways:
1. As a compressed public key with x coordinate d20bbd7e394ad5999a4cebabac9619732c343a4cac99470c03e23ba2bdc2bc01 2. As a private key intended to become a compressed key, with the original key being 02d20bbd7e394ad5999a4cebabac9619732c343a4cac99470c03e23ba2bdc2bc
The question is: why is it the case that every other encoding we use puts the type data at the beginning (02/03 for uncompressed, 04 for compressed, 00 for BIP32 privkeys), while to-be-compressed private keys are instead marked with '01' at the end?
The solution that I propose is to make the BIP32 internal private key format, that of '00' + key being the standard way to encode a private key intended to become a public key, standard. That way there will be a trivial algorithm to determine the data type of anything:
* Is it base58? Then, decode it and run the algorithm on the result. * Is it 20 bytes? It's an address * Is it 32 bytes? It's a standard old-style privkey * Is it 33 bytes? Look at the first byte, if it's 00 it's a privkey to be used with compression, if it's 02 or 03 it's a compressed pubkey, if it's 04 it's an uncompressed pubkey.
The WIF format of a new-style privkey would then start with Kw (precisely, it would be between "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73NUBByJr" and "KwFevqMbSXhGxNWuVc6vuERwdXq7aDQtiLNkjPVokF87Rs4LmqrN").
|