5

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)

1 Answer 1

2

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.

6
  • 2
    Malleability is much wider than the class of problems second-layer protocols care about, and can even be desired. For example, Bitcoin transactions have sighash flags which allow signatures that e.g. only cover the outputs or inputs of a transaction - leaving the non-covered parts explicitly open for change after signing. Also scripts could choose to just take an input that gets ignored. What segwit did is make universally sure that transactions for which changes to the transactions which do not change its effect, also do not change the txid. Aug 24, 2023 at 12:52
  • @PieterWuille What do you think about transaction malleability types defined by Antoine? It looks a little bit strange to me since TXID malleability is also a third party malleability.
    – dassd
    Aug 24, 2023 at 18:51
  • 1
    In general, when we're concerned about txid malleability, it's not third party malleability (as generally, for typical transactions, with BIP62/BIP66 enforced, third parties cannot modify transactions without invalidating them), but concern about another signer re-signing. That's called second-party malleability in mastering bitcoin 3rd edition, but it's debatable whether that should be called malleability at all. Aug 24, 2023 at 18:58
  • @PieterWuille Right, but generally speaking TXID malleability is also a third and second party malleability. I mean, they are both about changing transaction IDs. So Antoine in some way wrote it wrong. And segwit solves both of this malleabilities (as we already discussed before). Right?
    – dassd
    Aug 24, 2023 at 21:29
  • 2
    @Filip The second class in Antoine's answer is not about txid malleability, but transaction malleability (as in second or third parties can change the transaction in general, even though in a way that doesn't change the txid). Such malleability is still a problem for some use cases post-segwit, though a much smaller one. Aug 24, 2023 at 21:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.