Pour toute signature ECDSA valide (r, s), la paire (r, n − s) passe elle aussi la vérification : remplacer le nonce par son opposé inverse le signe de s, tandis que k·G et −k·G ont la même coordonnée x. La règle low-S retient le représentant tel que s ≤ n/2 ; un signataire normalise en remplaçant s par n − s chaque fois que s est plus grand. Pour secp256k1, n/2 arrondi à l’entier inférieur vaut 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0.
Bitcoin Core ne relaie que des signatures low-S depuis la version 0.11.1 (2015) et en produit depuis la 0.9.0, comme le documente le BIP 146 ; le vérificateur de libsecp256k1 rejette les signatures high-S. L’EIP-2 d’Ethereum (Homestead, 2016) a rendu invalides les transactions dont s dépasse n/2, mais le précompilé ecrecover accepte toujours les valeurs high-S : les contrats qui vérifient des signatures doivent donc imposer eux-mêmes cette borne.
Les vérificateurs génériques (OpenSSL, WebCrypto, Java, Go) acceptent les deux formes, et les signataires génériques comme OpenSSL ne normalisent pas : environ la moitié de leurs signatures échouent donc à un contrôle low-S tant qu’elles ne sont pas normalisées. EdDSA évite le problème en exigeant que S soit inférieur à l’ordre du groupe (RFC 8032 §5.1.7).