Hello all, while OpenSSL's silent support for compressed public keys allowed us to enable them in a fully backward-compatible way, it seems OpenSSL supports yet another (and non-standard, and apparently useless) encoding for public keys.
As these are supported by (almost all?) fully validating clients on the network, I believe alternative implementations should be willing to handle them as well. No hybrid keys are used in the main chain, but I did test them in testnet3, and they work as expected. In total, the following encodings exist: * 0x00: point at infinity; not a valid public key * 0x02 [32-byte X coord]: compressed format for even Y coords * 0x03 [32-byte X coord]: compressed format for odd Y coords * 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format * 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y coords * 0x07 [32-byte X coord] [32-byte Y coord]: hybrid format for odd Y coords Handling them is trivial: if you see a public key starting with a 0x06 or 0x07, use it as if there was a 0x04 instead. I suppose we could decide to forbid these after a certain date/block height, and try to get sufficient mining power to enforce that before that date. Any opinions? Forbidding it certainly makes alternative implementation slightly easier in the future, but I'm not sure the hassle of a network rule change is worth it. -- Pieter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development