Low-S Signatures

ECDSA signatures have an inherent malleability: for any valid (r, s) pair, (r, n-s) where n is the secp256k1 curve order is also a valid signature on the same message. An attacker could grab your unconfirmed transaction, flip the S, and rebroadcast a signature with identical meaning but a different txid.

The low-S rule pins down one form. Require s to be at most n/2, and a signature with S in the upper half is refused. Each signature then has one acceptable form instead of two. Whoever holds the private key can still sign the same transaction again and get a different, equally valid signature, but nobody else can.

History: BIP 62 (2014) proposed low-S as one of several consensus rules against malleability, and it was never deployed. Bitcoin Core began enforcing low-S as relay policy in version 0.11.1, released in October 2015. Nodes running it won't relay or mine a transaction with a high-S signature, but a block that contains one is still valid. BIP 146 (2016) proposed making the rule part of consensus for both legacy and SegWit scripts, and it was closed without being deployed. BIP 141, the SegWit proposal itself, has no low-S rule. As of Bitcoin Core 31.1 (July 2026), low-S is still a standardness rule for every ECDSA input, legacy or SegWit, and not a consensus rule.

What actually fixed third-party malleability was SegWit. When a transaction spends SegWit outputs, its signatures sit in the witness, which the txid doesn't cover, so flipping S there leaves the txid alone (it does change the separate witness ID, the wtxid). For transactions spending older non-SegWit outputs, low-S together with BIP 66's strict DER encoding means the network won't pass along a tweaked copy. A miner could still put a high-S copy in a block, which is why the 0.11.1 release notes say the rule doesn't replace a real fix.