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").