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

CC BY-SA 3.0
2015-12-14T03:37:21.557Z
Thanks Pieter! Is there a writeup somewhere for this compact signature format?
Ryan Shea
CC BY-SA 3.0
2012-10-17T22:37:43.343Z
2012-10-17T22:37:43.343Z
Pieter Wuille
<p>There's a hard-coded 27 value in Bitcoin's encoding of Compact Signatures that I don't understand:</p>

<p><a href="https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/key.cpp#L333">https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/key.cpp#L333</a></p>

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

<p>The <a href="https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/key.cpp#L351">decoder requires</a> the first byte be between 27 and 35, but then just subtracts the hard-coded 27 sans explanation.</p>

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

CC BY-SA 3.0
2015-12-14T02:49:47.477Z
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
<signature>
Why Do Compact Signatures Need To Start With a Byte 27-35?
rentzsch
# Why Do Compact Signatures Need To Start With a Byte 27-35?

(Asked by: username_0 on 2012-10-17)

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](https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/key.cpp#L351) 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?

**Tags:** signature

> **Comments:**
> **username_1**: 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.  

---

## 1 answers

### Answer by username_2 on 2012-10-17. Score: 7 | Accepted answer

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.

> **Comments:**
> **username_1**: Thanks Pieter! Is there a writeup somewhere for this compact signature format?  

---

