Para qualquer assinatura ECDSA válida (r, s), o par (r, n − s) também passa na verificação: trocar o sinal do nonce inverte o sinal de s, enquanto k·G e −k·G têm a mesma coordenada x. O low-S escolhe o representante com s ≤ n/2; um signatário normaliza substituindo s por n − s sempre que s for maior. Para a secp256k1, n/2 arredondado para baixo é 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0.
O Bitcoin Core só retransmite assinaturas low-S desde a versão 0.11.1 (2015) e as produz desde a 0.9.0, como documenta a BIP 146; o verificador da libsecp256k1 rejeita high-S. A EIP-2 do Ethereum (Homestead, 2016) tornou inválidas as transações com s acima de n/2, mas o contrato pré-compilado ecrecover ainda aceita valores high-S, então os contratos que verificam assinaturas precisam impor esse limite por conta própria.
Verificadores genéricos (OpenSSL, WebCrypto, Java, Go) aceitam as duas formas, e signatários genéricos como o OpenSSL não normalizam, então cerca de metade das assinaturas deles falha em uma verificação low-S até ser normalizada. O EdDSA evita o problema exigindo que S seja menor que a ordem do grupo (RFC 8032 §5.1.7).