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

Question

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?

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 Shea, Dec 14 '15 at 02:49

score 7 · Accepted Answer · answered Oct 17 '12 at 22:37

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.

answered Oct 17 '12 at 22:37

Pieter Wuille

105,497
9
194
308

Thanks Pieter! Is there a writeup somewhere for this compact signature format? – Ryan Shea Dec 14 '15 at 03:37

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

1 Answers1