So when you want to import a private key, the software has to know which of the public keys (with corresponding address) should be used. The solution is to add a flag bit to the base58 encoding of the private key, notifying the importer whether or not to use the compressed public keys. Typically, these get called compressed and uncompressed private keys - but it's really just a bit saying whether the corresponding public key is compressed or not.
Thanks for the explanation. Being in progress of writing my own library for BTC-stuff,
I tried to "feed" it a compressed key (from my wallet) and an uncompressed key from
vanitygen, and I got a leading (hex)"80" octet for both. The number from the compressed
key was 8 bits longer, though.
Depending on the length (essentially the "ceil(log_2(N))" ) appears a bit fragile to me, for
the decision if the decoded priv-key is intended as a compressed or uncompressed key.
Is software expected to check for leading 5 or L/K on the base58 string, or did I miss
some sound discriminator within this larger N (maybe check it against the order of G
in secp256k1 ?)
If I intended to create a "compressed-key brain wallet", what do I have to do with the
sha²-output (before doing the chksum+base58 stuff) to get a priv-key that I could import
into a standard (sufficiently new) wallet?
Unfortunately, the bitcoin wiki-page about WEF-encoding priv-keys doesn't mention
compressed keys.
(hoping that you still have this thread monitored...)