<p>I think you are conflating two types of malleability:</p>
<ul>
<li>The first one is txid malleability of a presigned transaction: two (or more) parties can't trustlessly build a chain of unconfirmed transactions if tweaking the witness data of any of them would invalidate the whole chain.</li>
<li>The second one is third-party malleability of any transaction. If a third-party (ie not the issuer of the transaction) can turn a valid transaction broadcast to the network into another valid transaction with a different identifier, it can (among other undesirable effects) hinder the propagation of a transaction and potentially of blocks themselves by affecting compact blocks relay.</li>
</ul>
<p>Segregated witness is a fix for the former, but not the latter. The rules you mention that enforce a stricter encoding have to do with the latter.</p>
<p>You would never be able to use presigned transactions trustlessly if simply changing the witness data of a spent transaction would change its txid. [0] Simply creating a new signature would change the txid (no matter the strict DER encoding). And in any multi-party situation just using different spending paths would lead to the same transaction having different identifiers. To illustrate, take a simple 1-of-2 multisig (<code>&lt;1&gt; &lt;A&gt; &lt;B&gt; &lt;2&gt; OP_CHECKMULTISIG</code>). You can try to carve-out any strict encoding rule, the txid of the spending transaction is always going to change depending on whether the script is satisfied by providing a signature for <code>A</code> or <code>B</code>.</p>
<p>On the other hand, separating the witness data from the txid does not fix third-party malleability. Because you need a new identifier to refer to the complete transaction anyways, as that's what gets propagated (it's called the <code>wtxid</code>). But having strict encoding rules (like minimal push, <code>NULLDUMMY</code>, etc..) do help to build the tooling that permits to create non-malleable scripts. See <a href="https://bitcoin.stackexchange.com/a/116282/101498">this answer</a> for more about this.</p>
<p>[0] Another way of fixing this is by having signatures not commit to the spent coin, and assume you'll always be able to re-create a new transaction and re-bind the signatures to it. It's a powerful approach which comes with a different set of tradeoffs. Look for &quot;BIP118&quot;, &quot;ANYPREVOUT&quot; or &quot;NOINPUT&quot; for more about this.</p>

CC BY-SA 4.0
2023-02-13T12:09:39.673Z
2023-02-13T12:09:39.673Z
Antoine Poinsot
<p>The status of BIP146 is “withdrawn”. Even for segwit inputs, high-s ECDSA signatures are only non-standard but consensus valid.</p>
<p>I don’t know about the other malleability issues in detail, but would suspect that they might also be just non-standard but valid.</p>
<p>So, at least some of the above can still be inserted into the blockchain by block authors even when such transactions do not propagate on the network.</p>

CC BY-SA 4.0
2023-02-12T19:52:46.117Z
2023-02-12T19:52:46.117Z
Murch
<p>Below are a few examples of witness malleability, along with reasons why I believe they are no longer valid:</p>
<p><strong>DER Malleability</strong></p>
<ul>
<li>For every DER signature with (r,s), there exists 2 valid 's' values -&gt; BIP146 requires low 's' only</li>
</ul>
<p><strong>scriptSig Malleability</strong></p>
<ul>
<li><p>Can add OP_NOP -&gt; &quot;scriptsig-not-pushonly&quot; error</p>
</li>
<li><p>Can add OP_1 at start of scriptSig -&gt; &quot;Stack size must be exactly one after execution&quot; error</p>
</li>
<li><p>Can add, say, OP_PUSHDATA1 OP_0 -&gt; &quot;Data push larger than necessary&quot; error</p>
</li>
<li><p>Can add OP_1 OP_DROP at start of scriptSig -&gt; &quot;scriptsig-not-pushonly&quot; error</p>
</li>
</ul>
<p>In summary, it appears the Bitcoin team has done a pretty good job of plugging the holes in non-segwit witness data malleability, so I'm not clear why one of the major benefits of segwit to this day is listed as preventing malleability (I get that Segwit is a more absolute solution to this problem, given the witness data isn't part of txid and hence txid is immutable).</p>
<p>The only reasons I can think of why non-segwit malleability would remain an issue is if some of the witness malleability attack vectors listed above are still valid if a transaction is submitted directly to miner (even if rejected by other nodes), or if a non-negligible portion of nodes still hadn't updated these software changes from 2016 etc.</p>

CC BY-SA 4.0
2023-02-13T12:12:04.190Z
Good question, i think it is a good illustration of the infamously confusing terminology in the Bitcoin world. There is more than one malleability. :p (We need a Benevolent Bitcoin Terminology Dictator to assign different names to different things.)
Antoine Poinsot
CC BY-SA 4.0
2023-02-15T21:27:16.343Z
@AntoinePoinsot So... the term malleability is malleable?
Poseidon
<segregated-witness><transaction-malleability><witness-data>
Is a transaction with a non-segwit input STILL considered malleable? If so how?
Peter
# Is a transaction with a non-segwit input STILL considered malleable? If so how?

(Asked by: username_0 on 2023-02-12)

Below are a few examples of witness malleability, along with reasons why I believe they are no longer valid:

**DER Malleability**

* For every DER signature with (r,s), there exists 2 valid 's' values -> BIP146 requires low 's' only

**scriptSig Malleability**

* Can add OP\_NOP -> "scriptsig-not-pushonly" error
* Can add OP\_1 at start of scriptSig -> "Stack size must be exactly one after execution" error
* Can add, say, OP\_PUSHDATA1 OP\_0 -> "Data push larger than necessary" error
* Can add OP\_1 OP\_DROP at start of scriptSig -> "scriptsig-not-pushonly" error

In summary, it appears the Bitcoin team has done a pretty good job of plugging the holes in non-segwit witness data malleability, so I'm not clear why one of the major benefits of segwit to this day is listed as preventing malleability (I get that Segwit is a more absolute solution to this problem, given the witness data isn't part of txid and hence txid is immutable).

The only reasons I can think of why non-segwit malleability would remain an issue is if some of the witness malleability attack vectors listed above are still valid if a transaction is submitted directly to miner (even if rejected by other nodes), or if a non-negligible portion of nodes still hadn't updated these software changes from 2016 etc.

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

> **Comments:**
> **username_1**: Good question, i think it is a good illustration of the infamously confusing terminology in the Bitcoin world. There is more than one malleability. :p (We need a Benevolent Bitcoin Terminology Dictator to assign different names to different things.)  
> **username_2**: @username_1 So... the term malleability is malleable?  

---

## 2 answers

### Answer by username_1 on 2023-02-13. Score: 4

I think you are conflating two types of malleability:

* The first one is txid malleability of a presigned transaction: two (or more) parties can't trustlessly build a chain of unconfirmed transactions if tweaking the witness data of any of them would invalidate the whole chain.
* The second one is third-party malleability of any transaction. If a third-party (ie not the issuer of the transaction) can turn a valid transaction broadcast to the network into another valid transaction with a different identifier, it can (among other undesirable effects) hinder the propagation of a transaction and potentially of blocks themselves by affecting compact blocks relay.

Segregated witness is a fix for the former, but not the latter. The rules you mention that enforce a stricter encoding have to do with the latter.

You would never be able to use presigned transactions trustlessly if simply changing the witness data of a spent transaction would change its txid. [0] Simply creating a new signature would change the txid (no matter the strict DER encoding). And in any multi-party situation just using different spending paths would lead to the same transaction having different identifiers. To illustrate, take a simple 1-of-2 multisig (`<1> <A> <B> <2> OP_CHECKMULTISIG`). You can try to carve-out any strict encoding rule, the txid of the spending transaction is always going to change depending on whether the script is satisfied by providing a signature for `A` or `B`.

On the other hand, separating the witness data from the txid does not fix third-party malleability. Because you need a new identifier to refer to the complete transaction anyways, as that's what gets propagated (it's called the `wtxid`). But having strict encoding rules (like minimal push, `NULLDUMMY`, etc..) do help to build the tooling that permits to create non-malleable scripts. See [this answer](https://bitcoin.stackexchange.com/a/116282/101498) for more about this.

[0] Another way of fixing this is by having signatures not commit to the spent coin, and assume you'll always be able to re-create a new transaction and re-bind the signatures to it. It's a powerful approach which comes with a different set of tradeoffs. Look for "BIP118", "ANYPREVOUT" or "NOINPUT" for more about this.


---

### Answer by username_3 on 2023-02-12. Score: 3

The status of BIP146 is “withdrawn”. Even for segwit inputs, high-s ECDSA signatures are only non-standard but consensus valid.

I don’t know about the other malleability issues in detail, but would suspect that they might also be just non-standard but valid.

So, at least some of the above can still be inserted into the blockchain by block authors even when such transactions do not propagate on the network.


---

