<p>The requirement for transactions to only have low-s signatures is a <strong>standardness</strong> rule. Standardness is enforced at the mempool policy level and is not a protocol rule. Although the mempool behavior of Bitcoin Core has broad impact on the viability of transactions on the network, since mempool policy and standardness are local choices of Bitcoin Core, they have not always been documented in BIPs.</p>
<p>As mentioned, it was proposed to forbid high-s signatures at the protocol level in BIP62 with the original goal to resolve malleability concerns pertaining to scripts. BIP62 was withdrawn because just script rules were not enough to resolve transaction malleability concerns.</p>
<p>Signatures were later canonicalized in BIP66, and third-party malleability concerns regarding scripts were entirely resolved with BIP141. High-s signatures are still permitted: even for segwit outputs they are only non-standard, so while the txid is no longer influenced by signature data, the wtxid still is, and is still vulnerable to third-party malleability.</p>
<p>Returning to the main question, it turns out that the <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md#transaction-malleability-related-fixes" rel="nofollow noreferrer">Bitcoin 0.9.0 release</a> both started considering high-s signatures non-standard and only creating low-s signatures.</p>
<hr />
<p><sub>Note that third-party transaction malleability generally only concerns ECDSA signatures, Schnorr signatures are inherently <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#Motivation" rel="nofollow noreferrer">non-malleable</a>.</sub></p>

CC BY-SA 4.0
2022-07-05T15:49:13.457Z
BIP62 was withdrawn because its original goal (fixing malleability) wasn't achievable with just script rules (specifically, it couldn't prevent a co-signer from re-signing). The somewhat later and more narrow spun-off goal of canonicalizing signatures for the purpose of switching off OpenSSL for validation (and, the issues it had) was achieved by BIP66. Malleability was later actually made a non-concern with BIP141.
Pieter Wuille
CC BY-SA 4.0
2022-07-05T15:56:41.673Z
Thanks, made a couple more improvements to my post.
Murch
CC BY-SA 4.0
2022-07-05T15:45:37.043Z
2022-07-06T00:43:51.080Z
2022-07-06T00:43:51.080Z
Murch
<p>I was just trying to pin-point which BIP made high-s signatures non-standard. <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki" rel="nofollow noreferrer">BIP62</a> proposed it as a new consensus rule, but was withdrawn. I couldn't find it in another BIP.</p>

<signature><transaction-malleability><non-standard-transaction><bip62>
How and when were high-s signatures made non-standard?
Murch
# How and when were high-s signatures made non-standard?

(Asked by: username_0 on 2022-07-05)

I was just trying to pin-point which BIP made high-s signatures non-standard. [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) proposed it as a new consensus rule, but was withdrawn. I couldn't find it in another BIP.

**Tags:** signature, transaction-malleability, non-standard-transaction, bip62


---

## 1 answers

### Answer by username_0 on 2022-07-05. Score: 3 | Accepted answer

The requirement for transactions to only have low-s signatures is a **standardness** rule. Standardness is enforced at the mempool policy level and is not a protocol rule. Although the mempool behavior of Bitcoin Core has broad impact on the viability of transactions on the network, since mempool policy and standardness are local choices of Bitcoin Core, they have not always been documented in BIPs.

As mentioned, it was proposed to forbid high-s signatures at the protocol level in BIP62 with the original goal to resolve malleability concerns pertaining to scripts. BIP62 was withdrawn because just script rules were not enough to resolve transaction malleability concerns.

Signatures were later canonicalized in BIP66, and third-party malleability concerns regarding scripts were entirely resolved with BIP141. High-s signatures are still permitted: even for segwit outputs they are only non-standard, so while the txid is no longer influenced by signature data, the wtxid still is, and is still vulnerable to third-party malleability.

Returning to the main question, it turns out that the [Bitcoin 0.9.0 release](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md#transaction-malleability-related-fixes) both started considering high-s signatures non-standard and only creating low-s signatures.

---

Note that third-party transaction malleability generally only concerns ECDSA signatures, Schnorr signatures are inherently [non-malleable](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#Motivation).

> **Comments:**
> **username_1**: BIP62 was withdrawn because its original goal (fixing malleability) wasn't achievable with just script rules (specifically, it couldn't prevent a co-signer from re-signing). The somewhat later and more narrow spun-off goal of canonicalizing signatures for the purpose of switching off OpenSSL for validation (and, the issues it had) was achieved by BIP66. Malleability was later actually made a non-concern with BIP141.  
> **username_0**: Thanks, made a couple more improvements to my post.  

---

