<p>Most of the malleability issues listed in BIP62 stem from the fact that an input script (scriptSig) can be modified and still remain valid for the input, and because the input script is included when calculating the TXID, this modifies the TXID as well.</p>
<p>Example ways you can turn an input script into a different but still valid input script:</p>
<ul>
<li>Any valid ECDSA signature can be turned into a different valid signature by inverting the <em>s</em>-value. BIP62 proposed that an <em>s</em>-value in the lower half of the range be required.</li>
<li>Any push operation can be expressed multiple ways. For example, pushing the byte <code>01</code> can be done with the opcode <code>0x51</code> (<code>OP_1</code>/<code>OP_TRUE</code>), but also less efficiently using the sequence <code>0101</code> (<code>OP_PUSHBYTES_1 01</code>). BIP62 proposed that the most efficient (&quot;canonical&quot;) way be required.</li>
<li>Since the input script is a script, it can be modified any number of ways, for example by including <code>&lt;data&gt; OP_DROP</code> anywhere in the script. BIP62 proposed to restrict input scripts to data pushing opcodes.</li>
</ul>
<p>SegWit cleverly fixed all of these malleability vectors by simply requiring the input script to be empty (or, in the case of wrapped SegWit, to push a single specific byte vector), and moving signatures and other script inputs to the <em>witness</em> which isn't covered by the TXID. Witness data can still be malleated by third parties, but it doesn't affect TXID malleability anymore.</p>
<p>&quot;Nonintentional malleability&quot; just refers to malleability by a third party that the original creator of the transaction didn't intend. It will of course always be possible for the creator to intentionally malleate the transaction themselves before it is included in a block, and even with SegWit you can still create transactions intentionally malleable by third parties by e.g. not requiring any signatures to spend an output.</p>
<p>The pull request you mention changed standardness rules, not consensus rules, so it's easily bypassed by miners. Because SegWit took a different approach to fixing malleability, high <em>s</em>-value signatures are still just non-standard but valid by consensus.</p>

CC BY-SA 4.0
2024-08-26T17:19:30.210Z
2024-08-26T17:58:19.360Z
2024-08-26T17:58:19.360Z
Vojtěch Strnad
<ul>
<li>There are 9 malleability issues listed in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki" rel="nofollow noreferrer">BIP62</a>, but doesn't seem like <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141</a> addressed all of them. If not, why not and why is it not an issue for Lightning or other DoS vectors?</li>
<li>What is exactly meant by the word &quot;Nonintentional&quot; in motivation point #1 of BIP141? Does it imply there can still be &quot;intentional&quot; ways to malleate txid?</li>
<li>What was the exact difference in <a href="https://github.com/bitcoin/bitcoin/pull/6769" rel="nofollow noreferrer">PR6769</a> and Segwit in regards to preventing txid malleability because of ECDSA signatures? Miners could still collude and mine a different txid after this PR, which was fully eliminated by Segwit?</li>
</ul>

<transactions><segregated-witness><transaction-malleability>
Did Segwit (BIP141) eliminate all txid malleability issues listed in BIP62?
WhoIsNinja
# Did Segwit (BIP141) eliminate all txid malleability issues listed in BIP62?

(Asked by: username_0 on 2024-08-26)

* There are 9 malleability issues listed in the [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki), but doesn't seem like [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) addressed all of them. If not, why not and why is it not an issue for Lightning or other DoS vectors?
* What is exactly meant by the word "Nonintentional" in motivation point #1 of BIP141? Does it imply there can still be "intentional" ways to malleate txid?
* What was the exact difference in [PR6769](https://github.com/bitcoin/bitcoin/pull/6769) and Segwit in regards to preventing txid malleability because of ECDSA signatures? Miners could still collude and mine a different txid after this PR, which was fully eliminated by Segwit?

**Tags:** transactions, segregated-witness, transaction-malleability


---

## 1 answers

### Answer by username_1 on 2024-08-26. Score: 3 | Accepted answer

Most of the malleability issues listed in BIP62 stem from the fact that an input script (scriptSig) can be modified and still remain valid for the input, and because the input script is included when calculating the TXID, this modifies the TXID as well.

Example ways you can turn an input script into a different but still valid input script:

* Any valid ECDSA signature can be turned into a different valid signature by inverting the *s*-value. BIP62 proposed that an *s*-value in the lower half of the range be required.
* Any push operation can be expressed multiple ways. For example, pushing the byte `01` can be done with the opcode `0x51` (`OP_1`/`OP_TRUE`), but also less efficiently using the sequence `0101` (`OP_PUSHBYTES_1 01`). BIP62 proposed that the most efficient ("canonical") way be required.
* Since the input script is a script, it can be modified any number of ways, for example by including `<data> OP_DROP` anywhere in the script. BIP62 proposed to restrict input scripts to data pushing opcodes.

SegWit cleverly fixed all of these malleability vectors by simply requiring the input script to be empty (or, in the case of wrapped SegWit, to push a single specific byte vector), and moving signatures and other script inputs to the *witness* which isn't covered by the TXID. Witness data can still be malleated by third parties, but it doesn't affect TXID malleability anymore.

"Nonintentional malleability" just refers to malleability by a third party that the original creator of the transaction didn't intend. It will of course always be possible for the creator to intentionally malleate the transaction themselves before it is included in a block, and even with SegWit you can still create transactions intentionally malleable by third parties by e.g. not requiring any signatures to spend an output.

The pull request you mention changed standardness rules, not consensus rules, so it's easily bypassed by miners. Because SegWit took a different approach to fixing malleability, high *s*-value signatures are still just non-standard but valid by consensus.


---

