Quote from: kjj on March 27, 2013, 10:02:16 PM

Quote from: AvL42 on March 27, 2013, 09:37:27 PM

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.

What I meant was, that "compatibility" with old software could hardly have been an argument for the decision to stick to 0x80 prefix. But then, what else was the reason for not just picking a different prefix-byte to indicate compressed keys?

Quote from: kjj on March 27, 2013, 10:02:16 PM

Quote from: AvL42 on March 27, 2013, 09:37:27 PM

Brain wallets & vanitygen

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

Lol, I was rather thinking of those offline-able pages where you could enter a passphrase and have a priv-key and address (and QR of each) generated purely from Javascript. I wanted to mention brainwallet.org, but noticed that that perfectly well gives choice over "compressed"/"uncompressed". Still, blockchain.info also allows importing brainwallets, but doesn't yet seem to support the concept of "compressed brainwallets". (It can import K/L...-style priv-keys, but warns, that their mobile client isn't able to use these.)

Quote from: kjj on March 27, 2013, 10:02:16 PM

Using uncompressed keys causes a modest, but real, bloat in the blockchain and should be avoided whenever possible.

If it were possible to place public keys (compressed or uncompressed) in a new "array" compartment of a transaction and access them per some new opcode with index from the scripts, then transactions that collect multiple coins from each address would benefit even more.

Instead of:
47 30......... 21 02........
47 30......... 21 02........
scripts could then use:
47 30......... ba 00
47 30......... ba 00
and the tx would have the "02........" string only once in that new compartment.
(ba isn't yet an opcode, so I'm using it for that new opcode, only for the sake of this post.)

Quote from: kjj on March 27, 2013, 10:02:16 PM

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, vanitygen is open source, so that wouldn't really be an insurmountable problem...