<p>There are two different encodings used.</p>

<p>Everything in the Bitcoin protocol, including <strong>transaction signatures</strong> and <strong>alert signatures</strong>, uses <em>DER encoding</em>. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.</p>

<p>For <strong>message signatures</strong>, a <em>custom encoding</em> is used which is more compact (and more recent) and supports public key recovery (given a message and a signature, find which public key would have created it). The code you're referring to in the question is for creating such signatures.</p>

<p>A correct DER-encoded signature has the following form:</p>

<ul>
<li><code>0x30</code>: a header byte indicating a compound structure.</li>
<li>A 1-byte length descriptor for all what follows.</li>
<li><code>0x02</code>: a header byte indicating an integer.</li>
<li>A 1-byte length descriptor for the R value</li>
<li>The R coordinate, as a big-endian integer.</li>
<li><code>0x02</code>: a header byte indicating an integer.</li>
<li>A 1-byte length descriptor for the S value.</li>
<li>The S coordinate, as a big-endian integer.</li>
</ul>

<p>Where initial <code>0x00</code> bytes for R and S are not allowed, except when their first byte would otherwise be above <code>0x7F</code> (in which case a single <code>0x00</code> in front is required). Also note that inside transaction signatures, an extra hashtype byte follows the actual signature data.</p>

CC BY-SA 3.0
2013-08-07T01:15:05.830Z
Thank you, Pieter! Now I understand why we can safely ignore the first byte in the 33 bytes cases.
Ning
CC BY-SA 3.0
2014-10-30T03:49:05.253Z
@StephenM347 If the first byte has its highest bit set (>0x7F), BER (of which DER is a specialization of) says that it is to be interpreted as a negative number. OpenSSL, knowing that signatures only contain positive numbers, ignores this, but this violates the specification. As of v0.8.0, Bitcoin Core requires strict adherence to DER for signatures, although anything that OpenSSL accepts is valid in the blockchain for now (although BIP62 proposes making it a network rule to require strict DER).
Pieter Wuille
CC BY-SA 3.0
2014-10-30T03:51:10.393Z
Great, thanks. Sort of wish Satoshi had just used data pushes for R and S on the stack rather than this whole DER thing, but what can you do! :)
morsecoder
CC BY-SA 3.0
2014-10-29T01:29:07.957Z
Why are values above 0x7F in the first byte of R or S not allowed? Maybe something to do with DER? The signatures that are printing for me seem to have the 0x00 out in front of the R, S about 50% of the time, disjointly.
morsecoder
CC BY-SA 3.0
2017-12-20T17:12:53.907Z
Can you expand more on the custom format? I am trying to recreate the QT signing process. However, C++ is far beyond my understanding.
Jus12
CC BY-SA 4.0
2021-08-12T12:16:40.207Z
How about in Schnorr Signature, is both (R,s) values are included in the signature field
Cisco Mmu
CC BY-SA 4.0
2021-08-12T13:15:12.067Z
@CiscoMmu Yes, in BIP340 signatures the first 32 bytes are the X coordinate of R (and the Y coordinate is implicitly even), and the last 32 bytes are s.
Pieter Wuille
CC BY-SA 4.0
2021-08-15T02:26:12.403Z
thank you Pieter, I have been looking around for few days (i wonder why the Public nonce value did not mention anywhere), until I found it out that ECDSA signature actually consists of signature and Public Nonce. I assume it is the same with SCHNorr. that why I asked.
Cisco Mmu
CC BY-SA 4.0
2023-09-06T08:46:50.887Z
For reference, DER encoding is defined in [ITU-T X.690](https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en) (part of ASN.1)
Lee
CC BY-SA 3.0
2013-08-07T00:30:24.143Z
2013-08-07T00:37:47.527Z
2013-08-07T00:37:47.527Z
Pieter Wuille
<p>A signature created by the Bitcoin-Qt client can always be decoded (base64) to a 65-byte array. This array seems (according to <a href="https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L217">https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L217</a>) to contain a header byte, a 32-byte R part, and a 32-byte S part.</p>

<p>I've extracted some (R,S) pairs from some ECDSA Signatures encoded in the DER format. I found that R and S are not necessarily of 32 bytes in size. They sometimes can be 33 bytes long. Could anyone tell me why the signature created by the Qt client is always 65 bytes, or whether it is OK to always convert both R and S into a 32-byte array? Thanks.</p>

<bitcoin-core><signature><ecdsa><message-signing>
Why the signature is always 65 (1+32+32) bytes long?
Ning
# Why the signature is always 65 (1+32+32) bytes long?

(Asked by: username_0 on 2013-08-06)

A signature created by the Bitcoin-Qt client can always be decoded (base64) to a 65-byte array. This array seems (according to <https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L217>) to contain a header byte, a 32-byte R part, and a 32-byte S part.

I've extracted some (R,S) pairs from some ECDSA Signatures encoded in the DER format. I found that R and S are not necessarily of 32 bytes in size. They sometimes can be 33 bytes long. Could anyone tell me why the signature created by the Qt client is always 65 bytes, or whether it is OK to always convert both R and S into a 32-byte array? Thanks.

**Tags:** bitcoin-core, signature, ecdsa, message-signing


---

## 1 answers

### Answer by username_1 on 2013-08-07. Score: 45 | Accepted answer

There are two different encodings used.

Everything in the Bitcoin protocol, including **transaction signatures** and **alert signatures**, uses *DER encoding*. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.

For **message signatures**, a *custom encoding* is used which is more compact (and more recent) and supports public key recovery (given a message and a signature, find which public key would have created it). The code you're referring to in the question is for creating such signatures.

A correct DER-encoded signature has the following form:

* `0x30`: a header byte indicating a compound structure.
* A 1-byte length descriptor for all what follows.
* `0x02`: a header byte indicating an integer.
* A 1-byte length descriptor for the R value
* The R coordinate, as a big-endian integer.
* `0x02`: a header byte indicating an integer.
* A 1-byte length descriptor for the S value.
* The S coordinate, as a big-endian integer.

Where initial `0x00` bytes for R and S are not allowed, except when their first byte would otherwise be above `0x7F` (in which case a single `0x00` in front is required). Also note that inside transaction signatures, an extra hashtype byte follows the actual signature data.

> **Comments:**
> **username_0**: Thank you, username_1! Now I understand why we can safely ignore the first byte in the 33 bytes cases.  
> **username_2**: Why are values above 0x7F in the first byte of R or S not allowed? Maybe something to do with DER? The signatures that are printing for me seem to have the 0x00 out in front of the R, S about 50% of the time, disjointly.  
> **username_1**: @StephenM347 If the first byte has its highest bit set (>0x7F), BER (of which DER is a specialization of) says that it is to be interpreted as a negative number. OpenSSL, knowing that signatures only contain positive numbers, ignores this, but this violates the specification. As of v0.8.0, Bitcoin Core requires strict adherence to DER for signatures, although anything that OpenSSL accepts is valid in the blockchain for now (although BIP62 proposes making it a network rule to require strict DER).  
> **username_2**: Great, thanks. Sort of wish Satoshi had just used data pushes for R and S on the stack rather than this whole DER thing, but what can you do! :)  
> **username_3**: Can you expand more on the custom format? I am trying to recreate the QT signing process. However, C++ is far beyond my understanding.  
> **username_4**: How about in Schnorr Signature, is both (R,s) values are included in the signature field  
> **username_1**: @username_4 Yes, in BIP340 signatures the first 32 bytes are the X coordinate of R (and the Y coordinate is implicitly even), and the last 32 bytes are s.  
> **username_4**: thank you username_1, I have been looking around for few days (i wonder why the Public nonce value did not mention anywhere), until I found it out that ECDSA signature actually consists of signature and Public Nonce. I assume it is the same with SCHNorr. that why I asked.  
> **username_5**: For reference, DER encoding is defined in [ITU-T X.690](https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en) (part of ASN.1)  

---

