Signature Malleability (Low S)

One of the most complex "Bugs" in early Bitcoin was Signature Malleability. It allowed a third party to change the look of a signature without invalidating it, which could confuse the network and break Layer-2 protocols.

1. The Math of Duality

On an elliptic curve, for every valid signature $(r, s)$, there is another valid signature $(r, -s)$.

• Because the curve is symmetric, both $s$ and $(n - s)$ are mathematically valid proofs for the same transaction.

• This is called Malleability.

2. The Transaction ID Problem

If you change $s$ to $(n - s)$:

1. The signature is still valid.

2. The Transaction Hash (TXID) changes because the raw bytes of the transaction have changed.

3. The Hack: A malicious node could see your transaction, change the signature, and broadcast the new version. If their version gets mined first, your original TXID is "forgotten." This made it hard to track payments or build smart contracts.

3. The Fix: BIP62 (Low S)

To stop this, Bitcoin developers introduced the Low S rule.

• The rule says: A signature is only "Standard" if $s$ is in the Lower Half of the range.

• Mathematically: $s \le n/2$.

• If your calculation results in a "High S," the wallet simply converts it to $s = n - s$ before broadcasting.

4. SegWit and Malleability

While the Low S rule helped, the real fix came with SegWit.

• SegWit moved the signature out of the "Transaction Header" and into a separate "Witness" field.

• Even if the signature is mutated now, the TXID does not change, because the TXID only hashes the core transaction data, not the witness data.

Term	Meaning	Status
High S	$s > n/2$	Invalid / Non-standard
Low S	$s \le n/2$	Current Standard
Malleability	Changing a signature's hex without breaking it	Fixed by SegWit

In the final section, we will build a Python Signature Auditor.