For any valid ECDSA signature (r, s), the pair (r, n − s) verifies too: negating the nonce flips the sign of s while k·G and −k·G share their x-coordinate. Low-S picks the representative with s ≤ n/2; a signer normalizes by replacing s with n − s whenever s is larger. For secp256k1, n/2 rounded down is 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0.
Bitcoin Core has relayed only low-S signatures since version 0.11.1 (2015) and produced them since 0.9.0, as documented in BIP 146; libsecp256k1's verifier rejects high-S. Ethereum's EIP-2 (Homestead, 2016) made transactions with s above n/2 invalid, but the ecrecover precompile still accepts high-S values, so contracts that verify signatures must enforce the bound themselves.
Generic verifiers (OpenSSL, WebCrypto, Java, Go) accept both forms, and generic signers such as OpenSSL do not normalize, so about half of their signatures fail a low-S check until normalized. EdDSA avoids the issue by requiring S to be below the group order (RFC 8032 §5.1.7).