What is the maximum size of a DER encoded ECDSA signature?

Question

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?, 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?

Answer 1

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 2²⁵⁵, 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.