<p>A signature in Bitcoin (as used to sign transactions inside scriptSigs and scriptWitnesses), consists of a DER encoding of an ECDSA signature, plus a sighash type byte.</p>
<p>Overall, this means they consist of:</p>
<ul>
<li>DER encoded signature data, consisting of:
<ul>
<li>1-byte type 0x30 &quot;Compound object&quot; (the tuple of (R,S) values)</li>
<li>1-byte length of the compound object</li>
<li>The signature's R value, consisting of:
<ul>
<li>1-byte type 0x02 &quot;Integer&quot;</li>
<li>1-byte length of the integer</li>
<li>variable-length R value's bytes</li>
</ul>
</li>
<li>The signature's S value, consisting of:
<ul>
<li>1-byte type 0x02 &quot;Integer&quot;</li>
<li>1-byte length of the integer</li>
<li>variable-length S value's bytes</li>
</ul>
</li>
</ul>
</li>
<li>The sighash type byte</li>
</ul>
<p>Summing this all up, we have 7 bytes (compound header, compound length, R value header, R value length, S value header, S value length, sighash type byte) excluding the actual R and S data bytes.</p>
<p>So we have reduced the question to wondering what the size of the R and S data bytes are. These encode 256-bit values, which ordinarily means 32 bytes. However, integers in DER are signed, which means that if their highest bit is set, they are interpreted as negative. For that reason, if the value being encoded is 2<sup>255</sup>, a 33rd byte is added in front.</p>
<p>There is a standardness rule on the network that requires the S value to be below N/2 (N being secp256k1 curve order) (&quot;Low S&quot;), but no such rule exists for R. Furthermore, it is only a standardness rule which miners are allowed to bypass.</p>
<p>So ignoring the Low S rule, signatures (including the sighash type byte) can be up to 7+33+33 = 73 bytes.</p>
<p>Perhaps the number you're citing also includes the push opcode used in scriptSig to push the signature onto the stack, but that still only gets us to 74.</p>
<p>Perhaps the 75th byte is the length of the scriptSig itself? But that would only be relevant for scriptSigs which consists of just a signature - for example P2PK spends.</p>

CC BY-SA 4.0
2020-04-14T14:35:01.193Z
what about the "v" value of an ecdsa ?
maroodb
CC BY-SA 4.0
2020-04-14T16:40:56.347Z
An ECDSA signature encodes a tuple (r, s), nothing more.
Pieter Wuille
CC BY-SA 4.0
2020-04-14T16:43:23.460Z
so the "v" value in ethereum signature isn't important?
maroodb
CC BY-SA 4.0
2020-04-14T16:43:45.653Z
I have no idea what you're talking about. There is no such thing.
Pieter Wuille
CC BY-SA 4.0
2020-04-14T16:45:53.343Z
OK, maybe isn't related to ecdsa, thanks :)
maroodb
CC BY-SA 4.0
2021-06-10T23:00:40.077Z
The 'v' you are referring to is the recovery id bit (0-3 inclusive), its not used as part of a DER serialized bitcoin signature. It is however, a ECDSA construct, not specific to Bitcoin or Ethereum. Hope this helps.
Tobin
CC BY-SA 4.0
2021-11-09T07:55:42.900Z
@PieterWuille I'm confused by: "if the value being encoded is 2^128, a 33rd byte is added in front." - Shouldn't it be ">= 2^255"?
Kalle Rosenbaum
CC BY-SA 4.0
2021-11-09T14:18:54.243Z
@KalleRosenbaum Of course, fixed!
Pieter Wuille
CC BY-SA 4.0
2018-07-13T22:33:56.133Z
2021-11-09T14:18:37.520Z
2021-11-09T14:18:37.520Z
Pieter Wuille
<p>I've been told by a seasoned Bitcoin contributor that signatures in Bitcoin could be up to 75 bytes. I'm curious to find out how that maximum comes to pass.</p>

<p>According to this answer on <a href="https://bitcoin.stackexchange.com/a/12556/5406">Why the signature is always 65 (1+32+32) bytes long?</a>, the signature is always 6 bytes plus the length of <code>R</code> and <code>S</code>, where the latter two can be up to 33 bytes (Is that accurate?). In the worst case that would result in a length of 72 bytes. </p>

<p>Can signatures be longer than 72 bytes? Under what circumstances does that happen and what is the maximum?</p>

<signature><ecdsa><serialization>
What is the maximum size of a DER encoded ECDSA signature?
Murch
# What is the maximum size of a DER encoded ECDSA signature?

(Asked by: username_0 on 2018-07-13)

I've been told by a seasoned Bitcoin contributor that signatures in Bitcoin could be up to 75 bytes. I'm curious to find out how that maximum comes to pass.

According to this answer on [Why the signature is always 65 (1+32+32) bytes long?](https://bitcoin.stackexchange.com/a/12556/5406), the signature is always 6 bytes plus the length of `R` and `S`, where the latter two can be up to 33 bytes (Is that accurate?). In the worst case that would result in a length of 72 bytes.

Can signatures be longer than 72 bytes? Under what circumstances does that happen and what is the maximum?

**Tags:** signature, ecdsa, serialization


---

## 1 answers

### Answer by username_1 on 2018-07-13. Score: 15 | Accepted answer

A signature in Bitcoin (as used to sign transactions inside scriptSigs and scriptWitnesses), consists of a DER encoding of an ECDSA signature, plus a sighash type byte.

Overall, this means they consist of:

* DER encoded signature data, consisting of:
  + 1-byte type 0x30 "Compound object" (the tuple of (R,S) values)
  + 1-byte length of the compound object
  + The signature's R value, consisting of:
    - 1-byte type 0x02 "Integer"
    - 1-byte length of the integer
    - variable-length R value's bytes
  + The signature's S value, consisting of:
    - 1-byte type 0x02 "Integer"
    - 1-byte length of the integer
    - variable-length S value's bytes
* The sighash type byte

Summing this all up, we have 7 bytes (compound header, compound length, R value header, R value length, S value header, S value length, sighash type byte) excluding the actual R and S data bytes.

So we have reduced the question to wondering what the size of the R and S data bytes are. These encode 256-bit values, which ordinarily means 32 bytes. However, integers in DER are signed, which means that if their highest bit is set, they are interpreted as negative. For that reason, if the value being encoded is 2255, a 33rd byte is added in front.

There is a standardness rule on the network that requires the S value to be below N/2 (N being secp256k1 curve order) ("Low S"), but no such rule exists for R. Furthermore, it is only a standardness rule which miners are allowed to bypass.

So ignoring the Low S rule, signatures (including the sighash type byte) can be up to 7+33+33 = 73 bytes.

Perhaps the number you're citing also includes the push opcode used in scriptSig to push the signature onto the stack, but that still only gets us to 74.

Perhaps the 75th byte is the length of the scriptSig itself? But that would only be relevant for scriptSigs which consists of just a signature - for example P2PK spends.

> **Comments:**
> **username_2**: what about the "v" value of an ecdsa ?  
> **username_1**: An ECDSA signature encodes a tuple (r, s), nothing more.  
> **username_2**: so the "v" value in ethereum signature isn't important?  
> **username_1**: I have no idea what you're talking about. There is no such thing.  
> **username_2**: OK, maybe isn't related to ecdsa, thanks :)  
> **username_3**: The 'v' you are referring to is the recovery id bit (0-3 inclusive), its not used as part of a DER serialized bitcoin signature. It is however, a ECDSA construct, not specific to Bitcoin or Ethereum. Hope this helps.  
> **username_4**: @username_1 I'm confused by: "if the value being encoded is 2^128, a 33rd byte is added in front." - Shouldn't it be ">= 2^255"?  
> **username_1**: @username_4 Of course, fixed!  

---

