From: Pieter Wuille <pieter.wuille@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] After compressed pubkeys: hybrid pubkeys
Date: Sat, 16 Jun 2012 21:26:52 +0200 [thread overview]
Message-ID: <20120616192651.GA13438@vps7135.xlshosting.net> (raw)
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
next reply other threads:[~2012-06-16 19:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-16 19:26 Pieter Wuille [this message]
2012-06-16 21:41 ` Gavin Andresen
2012-06-16 23:39 ` Gregory Maxwell
2012-06-17 1:15 ` Luke-Jr
2012-06-17 11:01 ` Mike Hearn
2012-06-17 12:04 ` Pieter Wuille
2012-06-17 15:16 ` Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120616192651.GA13438@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox