Post
Topic
Board Bitcoin Technical Support
Re: Compressed vs. Uncompresed Private Keys
by
kjj
on 27/03/2013, 22:02:16 UTC
I wonder, why they didn't just pick a different first byte, like 0x81, or whatever makes a good base58-start.
There's little use for a wallet to import a compressed key when it doesn't yet know how to handle it correctly, and those that do know how to handle it, could easily check for a second prefix on import.

If the system processing the WIF doesn't understand compressed keys, it'll complain that it found 264 bits when it expected 256.  Or it should.  At any rate, it's been a while, the old software should be updated if it doesn't understand.

Quote
You should pretty much always do compressed keys for new generation.  There is no reason to ever use uncompressed keys, at least none that I'm aware of.

Brain wallets are by convention uncompressed. While I can now (with help of your answer) create a compressed key from a passphrase and import that into my wallet, I might have a hard time to reconstruct it later for another wallet when I don't have my scripts at hand.

Also, vanitygen doesn't seem to search for vanity compressed keys (at least not the version I've got here).

Unless you are computing EC multiply, SHA-256 and RIPEMD-160 with pen and paper, you are going to need tools either way.

Using uncompressed keys causes a modest, but real, bloat in the blockchain and should be avoided whenever possible.  Uncompressed keys offer absolutely no advantages over compressed keys, require no more special knowledge to process*, and take no extra effort to create.

If there is some convention around using uncompressed keys for brain wallets, that convention needs to be die quickly, like a year ago.  May I suggest that the convention change to "create compressed, redeem both compressed and uncompressed"?  The private key is exactly the same in both cases, only the bitcoin address changes, and there are only two possible, so the redeeming system should have no problem checking both of them.

The author of vanitygen has been ignoring requests on the forums for compressed key support for over a year now.  I still have no idea why, since it should have very close to zero impact on key generation speed.

Well, I guess you have to remember "0x02=even, 0x03=odd" instead of remembering "0x04=magic", but that is close enough to nothing for me.