The requirement for transactions to solely have low-s signatures is a standardness rule. Standardness is enforced on the mempool coverage stage and isn’t a protocol rule. Though the mempool habits of Bitcoin Core has broad influence on the viability of transactions on the community, since mempool coverage and standardness are native decisions of Bitcoin Core, they haven’t all the time been documented in BIPs.
As talked about, it was proposed to forbid high-s signatures on the protocol stage in BIP62 with the unique objective to resolve malleability issues pertaining to scripts. BIP62 was withdrawn as a result of simply script guidelines weren’t sufficient to resolve transaction malleability issues.
Signatures have been later canonicalized in BIP66, and third-party malleability issues concerning scripts have been solely resolved with BIP141. Excessive-s signatures are nonetheless permitted: even for segwit outputs they’re solely non-standard, so whereas the txid is not influenced by signature information, the wtxid nonetheless is, and remains to be susceptible to third-party malleability.
Returning to the principle query, it seems that the Bitcoin 0.9.0 launch each began contemplating high-s signatures non-standard and solely creating low-s signatures.
Word that third-party transaction malleability usually solely issues ECDSA signatures, Schnorr signatures are inherently non-malleable.
