<p>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.</p>
<p>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”.</p>
<p>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.</p>
<p>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 <em>others</em> being able to modify signatures after they were created.</p>
<p>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.</p>
<p>Schnorr signatures are not subject to third-party malleability.</p>

CC BY-SA 4.0
2023-08-24T12:52:23.433Z
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.
Pieter Wuille
CC BY-SA 4.0
2023-08-24T18:51:09.530Z
@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
CC BY-SA 4.0
2023-08-24T18:58:20.577Z
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.
Pieter Wuille
CC BY-SA 4.0
2023-08-24T21:29:21.620Z
@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
CC BY-SA 4.0
2023-08-24T21:35:46.590Z
@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.
Pieter Wuille
CC BY-SA 4.0
2023-08-24T22:03:28.443Z
@PieterWuille Al right, thanks Pieter.
dassd
CC BY-SA 4.0
2023-08-21T14:23:46.640Z
2023-08-21T14:23:46.640Z
Murch
<p>I am little confused about what types of transaction malleability exist in bitcoin and which one of them does SegWit solve.</p>
<p><a href="https://bitcoin.stackexchange.com/a/117168/140802">Here</a> <em>Antoine Poinsot</em> talks about <strong>txid malleability</strong> and <strong>third-party malleability</strong> and says that SegWit solves only txid malleability. In the comment on that question, <em>Murch</em> mentioned <strong>first-party malleability</strong>. Furthermore, <a href="https://learning.oreilly.com/library/view/mastering-bitcoin-3rd/9781098150082/ch06.html#id166" rel="noreferrer"><em>Master bitcoin 3rd edition</em></a> talks about <strong>third-party</strong> and <strong>second-party</strong> malleability. <a href="https://bitcoin.stackexchange.com/a/89035/140802">In this answer</a> <em>Pieter Wuille</em> says that SegWit doesn't prevent malleability (that is, in many ways the actual transaction data can still be changed by third parties).</p>
<p>Looking at all this, I'm a bit confused.</p>
<p>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).</p>
<p>So my questions are the following:</p>
<ol>
<li>What types of transaction malleability exist and what situations do they represent?</li>
<li>What type/types of transaction malleability does SegWit solve?</li>
<li>If SegWit does not solve all types of transaction malleability, how these other types are overcome, if there is a solution for them?</li>
<li>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)</li>
</ol>

<security><segregated-witness><transaction-malleability>
What types of transaction malleability exist and which one of them does SegWit solve?
dassd
# What types of transaction malleability exist and which one of them does SegWit solve?

(Asked by: username_0 on 2023-08-18)

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

[Here](https://bitcoin.stackexchange.com/a/117168/140802) *Antoine Poinsot* talks about **txid malleability** and **third-party malleability** and says that SegWit solves only txid malleability. In the comment on that question, *username_1* mentioned **first-party malleability**. Furthermore, [*Master bitcoin 3rd edition*](https://learning.oreilly.com/library/view/mastering-bitcoin-3rd/9781098150082/ch06.html#id166) talks about **third-party** and **second-party** malleability. [In this answer](https://bitcoin.stackexchange.com/a/89035/140802) *username_2 username_2* 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)

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


---

## 1 answers

### Answer by username_1 on 2023-08-21. Score: 2 | Accepted answer

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. username_1 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.

> **Comments:**
> **username_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.  
> **username_0**: @username_2 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.  
> **username_2**: 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.  
> **username_0**: @username_2 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?  
> **username_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.  
> **username_0**: @username_2 Al right, thanks username_2.  

---

