Bitcoin Developers' Mailing List ()

Pieter Wuille | 16 Jun 2012 21:26

After compressed pubkeys: hybrid pubkeys

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

(Continue reading)

headers

Gavin Andresen | 16 Jun 2012 23:41

Re: After compressed pubkeys: hybrid pubkeys

RE: 0x06/0x07 'hybrid' public keys:

> 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.

I say treat any transactions that use them as 'non-standard' -- don't
relay/mine them by default, but accept blocks that happen to contain
them.

I agree that a rule change isn't worth it right now, but making them
non-standard now is easy and should make a rule change in the future
easier.

--

-- 
--
Gavin Andresen

------------------------------------------------------------------------------
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/

headers

Gregory Maxwell | 17 Jun 2012 01:39

Re: After compressed pubkeys: hybrid pubkeys

On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen <gavinandresen <at> gmail.com> wrote:
> RE: 0x06/0x07 'hybrid' public keys:
>
>> 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.
>
> I say treat any transactions that use them as 'non-standard' -- don't
> relay/mine them by default, but accept blocks that happen to contain
> them.
>
> I agree that a rule change isn't worth it right now, but making them
> non-standard now is easy and should make a rule change in the future
> easier.

ACK.  Hopefully no one will mine these before we can merge denying
them into another rule change. But if they do, oh well.

------------------------------------------------------------------------------
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/

headers

Luke-Jr | 17 Jun 2012 03:15

Re: After compressed pubkeys: hybrid pubkeys

On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
> On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen <gavinandresen <at> gmail.com> 
wrote:
> > RE: 0x06/0x07 'hybrid' public keys:
> >> 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.
> > 
> > I say treat any transactions that use them as 'non-standard' -- don't
> > relay/mine them by default, but accept blocks that happen to contain
> > them.
> > 
> > I agree that a rule change isn't worth it right now, but making them
> > non-standard now is easy and should make a rule change in the future
> > easier.
> 
> ACK.  Hopefully no one will mine these before we can merge denying
> them into another rule change. But if they do, oh well.

I'm willing to make Eligius reject these as well, if someone provides a patch 
that doesn't depend on IsStandard being enforced...

Same goes for rejecting OP_NOP<n> - I can't see any legitimate reason we'd 
want these on mainnet right now.

Luke

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and

(Continue reading)

headers

Mike Hearn | 17 Jun 2012 13:01

Re: After compressed pubkeys: hybrid pubkeys

> * 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

So what's the actual difference in format? Is there any at all, or
it's just the first number that's different?

------------------------------------------------------------------------------
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/

headers

Pieter Wuille | 17 Jun 2012 14:04

Re: After compressed pubkeys: hybrid pubkeys

On Sun, Jun 17, 2012 at 01:01:12PM +0200, Mike Hearn wrote:
> > * 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
> 
> So what's the actual difference in format? Is there any at all, or
> it's just the first number that's different?

>From what I understand, that is indeed the only difference.

--

-- 
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/

headers

Wladimir | 17 Jun 2012 17:16

Re: After compressed pubkeys: hybrid pubkeys

On Sun, Jun 17, 2012 at 2:04 PM, Pieter Wuille <pieter.wuille <at> gmail.com> wrote:

On Sun, Jun 17, 2012 at 01:01:12PM +0200, Mike Hearn wrote:
> > * 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
>
> So what's the actual difference in format? Is there any at all, or
> it's just the first number that's different?

>From what I understand, that is indeed the only difference.

To prevent surprises in the future, in case OpenSSL decides to add more, can we disable all other key formats in advance?

Wladimir

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development