Signature Serialization: DER & Compact Formats

Once a signature tuple $(r, s)$ is computed, it must be serialized into a binary stream to be transmitted within transaction inputs and stored on the blockchain.

Bitcoin primarily uses Distinguished Encoding Rules (DER) to serialize ECDSA signatures, though some APIs utilize raw Compact 64-byte representations.

---

🏛️ DER (Distinguished Encoding Rules) Structure

DER is a strict serialization standard defined under the ASN.1 framework. A DER-encoded signature is structured as a sequence of bytes containing nested length-prefix descriptors:

┌──────┬──────┬──────┬──────┬─────────┬──────┬──────┬─────────┬──────┐
│ 0x30 │ TotL │ 0x02 │ LenR │ r-bytes │ 0x02 │ LenS │ s-bytes │ SgHsh│
└──────┴──────┴──────┴──────┴─────────┴──────┴──────┴─────────┴──────┘

🔍 Byte-by-Byte Breakdown of DER:

1. 0x30 (1 byte): The ASN.1 compound sequence header.
2. Total Length (1 byte): The total length of the remaining signature payload (excluding 0x30 and this length byte).
3. 0x02 (1 byte): Denotes that the following element is an integer (specifically $r$).
4. Length of r (1 byte): The length of the $r$ integer payload in bytes (typically 0x20 or 0x21).
5. Value of r (Variable): The big-endian byte representation of $r$.
6. 0x02 (1 byte): Denotes that the following element is an integer (specifically $s$).
7. Length of s (1 byte): The length of the $s$ integer payload in bytes (typically 0x20 or 0x21).
8. Value of s (Variable): The big-endian byte representation of $s$.
9. SIGHASH (1 byte): A single trailing byte appending to the DER signature specifying the transaction signing scope (e.g., 0x01 for SIGHASH_ALL).

---

🚫 The Sign-Bit Padding Rule

Why can the length of $r$ and $s$ fluctuate between 32 and 33 bytes?

In DER, integers are treated as signed numbers in two's complement notation. * If the first byte of $r$ or $s$ has its most significant bit (MSB) set (meaning the byte value is greater than or equal to 0x80), a decoder will interpret the number as a negative value. * Because $r$ and $s$ are always positive coordinate scalars, if the MSB of the integer is set, we must prepend a 0x00 padding byte to force the decoder to interpret it as positive.

📐 Example:

• If $r = \text{0x7f1a...}$, the MSB is not set. It is serialized as a 32-byte integer (LenR = 0x20).
• If $r = \text{0x83c1...}$, the MSB is set (0x83 is $\ge$ 0x80). We prepend 0x00, serializing it as a 33-byte integer (LenR = 0x21, starting with 00 83 c1...).

This causes the overall length of a DER-serialized signature to fluctuate between 70, 71, or 72 bytes on-chain, depending on the random coordinates of the ephemeral point $R$.

---

⚡ BIP 66: Enforcing Strict DER Validation

Historically, Bitcoin nodes accepted non-standard DER encodings (e.g., unnecessary leading zeros, or missing padding bytes). This caused Transaction Malleability:

1. An intermediate node could relay Alice's transaction, but alter the signature serialization format (without breaking the cryptographic signature itself).
2. This modification altered the transaction byte stream, completely changing the transaction hash (TxID).
3. Alice's transaction would still be mined, but her software would fail to track it because the TxID changed.

To solve this, BIP 66 (Strict DER Signatures) was activated as a soft fork. It forces all nodes to strictly reject any signature that does not adhere perfectly to standard DER formatting rules, removing signature-level malleability.