Is a transaction with a non-segwit input STILL considered malleable? If so how?

Question

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.

Answer 1

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 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 2

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.