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


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 2:49

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.