What types of transaction malleability exist and which one of them does SegWit solve?

Question

I am little confused about what types of transaction malleability exist in bitcoin and which one of them does SegWit solve.

Here Antoine Poinsot talks about txid malleability and third-party malleability and says that SegWit solves only txid malleability. In the comment on that question, Murch mentioned first-party malleability. Furthermore, Master bitcoin 3rd edition talks about third-party and second-party malleability. In this answer Pieter Wuille says that SegWit doesn't prevent malleability (that is, in many ways the actual transaction data can still be changed by third parties).

Looking at all this, I'm a bit confused.

What I do know is that the transaction malleability comes from the fact that the digital signature does not cover the unlock script field (scriptSig), so if a third party (or anyone) changes its content (for example, adds something extra to the stack that will not affect the unlock validity of the referenced UTXO) it is possible to change the transaction ID and therefore if this transaction is accepted instead of the original one, it may invalidate all transactions in the descendant chain. Of course, this is only possible if we are working with an unconfirmed transaction and referencing its unconfirmed ID. SegWit solves this by moving the digital signature from the unlocking script (input portion of transaction) to separated witness data and therefore digital signature is not the part of transaction ID. So referencing this type of unconfirmed transaction is fine since its ID can't be changed (at least not by this way).

So my questions are the following:

1. What types of transaction malleability exist and what situations do they represent?
2. What type/types of transaction malleability does SegWit solve?
3. If SegWit does not solve all types of transaction malleability, how these other types are overcome, if there is a solution for them?
4. What type of transaction malleability does the situation I described represent? (I guess I'll find out by myself from the answer to the first question)

Answer 1

As you have identified, there are some inherent ways in which a transaction can be changed without changing its outcome. This is especially problematic when it changes the txid for its downstream effect, but it can for example also be used to modify a transaction’s feerate by increasing the overall weight.

First, second, and third party respectively refer to the “creator of a signature”, “a co-signer of the tx”, and “anyone that has a copy of the unconfirmed tx”.

Third-party transaction malleability refers to ways that anyone can change a transaction. For example a third party can invert the sign on the s-value in an ECDSA signature, or add some padding to the signature. Such modifications will make a transaction non-standard, but still valid to include in a block. On a non-segwit input this changes the txid, because the entire transaction is hashed to produce the txid. Transactions that only use segwit inputs prevent changes to the txid from all sources of third-party malleability. ECDSA signatures on segwit inputs are still malleable, but this only affects the WTXID not the TXID.

Generally, the original sender (“first party”) can always change a transaction, e.g. by simply signing again or by creating a replacement transaction. Murch probably shouldn’t have called that “first-party malleability”, since the term “transaction malleability” is inspired by “malleability” in cryptography, which refers to others being able to modify signatures after they were created.

The term “second-party malleability” was newly introduced in Mastering Bitcoin 3rd Edition. It refers to a situation in which a co-author of the transaction (“second party”) modifies the transaction after the sender has signed. This sort of effect needs to be considered in the context of multi-party protocols such as Lightning, coinjoins, or UTXO pools.

Schnorr signatures are not subject to third-party malleability.