Zu jeder gültigen ECDSA-Signatur (r, s) besteht auch das Paar (r, n − s) die Prüfung: Die Negation der Nonce kehrt das Vorzeichen von s um, während k·G und −k·G dieselbe x-Koordinate haben. Low-S wählt den Repräsentanten mit s ≤ n/2; ein Signierer normalisiert, indem er s durch n − s ersetzt, wann immer s größer ist. Für secp256k1 ist n/2 abgerundet 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0.
Bitcoin Core leitet seit Version 0.11.1 (2015) nur noch Low-S-Signaturen weiter und erzeugt sie seit 0.9.0, wie in BIP 146 dokumentiert; der Verifizierer von libsecp256k1 lehnt High-S ab. EIP-2 von Ethereum (Homestead, 2016) machte Transaktionen mit s über n/2 ungültig, doch das Precompile ecrecover akzeptiert weiterhin High-S-Werte, deshalb müssen Smart Contracts, die Signaturen prüfen, die Grenze selbst durchsetzen.
Generische Verifizierer (OpenSSL, WebCrypto, Java, Go) akzeptieren beide Formen, und generische Signierer wie OpenSSL normalisieren nicht, deshalb scheitert etwa die Hälfte ihrer Signaturen an einer Low-S-Prüfung, bis sie normalisiert sind. EdDSA umgeht das Problem, indem es verlangt, dass S kleiner als die Gruppenordnung ist (RFC 8032 §5.1.7).