Why Do Compact Signatures Need To Start With a Byte 27-35?

6

4

There's a hard-coded 27 value in Bitcoin's encoding of Compact Signatures that I don't understand:

https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/key.cpp#L333

I get that the need to encode the nRecId to disambiguate the correct recovered key, but I don't understand the 27 (or for that matter why fCompressedPubKey is encoded as a 4).

The decoder requires the first byte be between 27 and 35, but then just subtracts the hard-coded 27 sans explanation.

It this poor man's bitmasking? It there something in the protocol that Compact Signature's can't begin with a 0x00 and this is a weird work-around? Perhaps it's acting as a sort of magic cookie?

rentzsch

Posted 2012-10-17T19:43:01.503

Reputation: 163

To clarify, the decoder requires the first byte to be 27, 28, 29, or 30 for uncompressed public keys, and 31, 32, 33, or 34 for compressed public keys. – Ryan – 2015-12-14T02:49:47.477

Answers

7

Frankly, I just picked a range of numbers whose binary representation wouldn't easily collide with those of addresses (0, 111), secret keys (128, 239), public keys (2-7) or signatures (48). At the time, I didn't really expect it to end up in the message signing feature eventually.

Pieter Wuille

Posted 2012-10-17T19:43:01.503

Reputation: 54 032

Thanks Pieter! Is there a writeup somewhere for this compact signature format? – Ryan – 2015-12-14T03:37:21.557

Asked: 2012-10-17T19:43:01.503

Viewed: 403 times

Active: 2012-10-17T22:37:43.343