<p>Because with SegWit, the signatures aren't part of TXID preimage, so regenerating a signature with a new nonce won't change the TXID.</p>
<p>To understand the problem of 2nd-party malleability you must first understand how multisig is used to emulate covenants in order to enforce payment flow, to create immutable money switches. If it is just one switch, then 2nd-party malleability is not a problem. However, if a switch sends money to another such switch, then 2nd-party malleability becomes a problem.</p>
<p>A scheme like this would be vulnerable to 2nd-party malleability:</p>
<pre><code>-- switch0 -- switch0_0 -- payout0
            |
            \ switch0_1 -- switch1 -- switch1_0 -- payout1
                                    |
                                    \ switch1_1 -- payout2
</code></pre>
<p>But why?</p>
<p>Because each switch is something like</p>
<pre><code>if(switch) {
    require 2-of-2 signature for TX paying to payout0
} else {
    require 2-of-2 signature for TX paying to switch1
    checktimelockverify
}
</code></pre>
<p>Parties A and B will exchange all signatures in all the paths before even funding switch0, so later the other party can't change their mind and hold money hostage.</p>
<p>Suppose party A will have B's signature for 0_0 and 1_0, and party B will have A's signature for 0_1 and 1_1.</p>
<p>Now, suppose party A tries to go through to payout1. It already has B's signatures, so A just has to generate theirs and submit the 2 TXs, right?</p>
<p>OK, so party A submits the 1st TX. BUT. B is monitoring the mempool, sees that, and then extracts A's signature from the TX and generates a <strong>new</strong> signature by B and somehow has the new version mined rather than the original. The outputs of the TX can't be changed by B, he's just changing the nonce, but without SegWit that will change the TXID.</p>
<p>Now A wants to complete the path by spending from switch1, but A can't do it anymore, because the signature by B it has is not good anymore because the prevout reference has changed and signature has become invalid. Now A is stuck, and B is holding A hostage.</p>
<p>With SegWit, if B would generate a new signature it wouldn't change the TXID, so the next signature wouldn't get invalidated and A could go through with the TX.</p>
<p>That isn't the only way to address malleability. What if we had signatures that don't sign the prevout ref parts of the TX? Then A could simply update the prevout refs and the pre-signed signature by B would still be good.</p>
<p><a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">Lightning Network whitepaper</a> was originally proposing this as a solution:</p>
<blockquote>
<p>SIGHASH NOINPUT would neither sign any input transactions IDs nor sign the index. By using SIGHASH NOINPUT, one can be assured that one's counterparty cannot invalidate entire trees of chained transactions of potential contract states which were previously agreed upon, using transaction ID mutation. With the new sighash flags, it is possible to spend from a parent transaction even though the transaction ID has changed, so long as the script evaluates as true (i.e. a valid signature).</p>
<p>SIGHASH NOINPUT implies significant risk with address reuse, as it can work with any transaction in which the sigScript returns as valid, so multiple transactions with the same outputs are redeemable (provided the output values are less).</p>
<p>Further, and just as importantly, SIGHASH NOINPUT permits participants to sign spends of transactions without knowing the signatures of the transaction being spent. By solving malleability in the above manner, two parties may build contracts and spend transactions without either party having the ability to broadcast that original transaction on the blockchain until both parties agree. With the new sighash type, participants may build potential contract states and potential payout conditions and agree upon all terms, before the contract may be paid, broadcast, and executed upon without the need for a trusted third party.</p>
</blockquote>
<p>Later, a non-segwit network (Bitcoin Cash - BCH) adopted a similar approach to solve the 2nd-party malleability problem and implement a 2-stage-refund cross-chain swap, see <a href="https://gitlab.com/0353F40E/cross-chain-swap-ves/-/blob/master/README.md" rel="nofollow noreferrer">&quot;Cross-chain Atomic Swaps With Bitcoin Cash (BCH) Using One-Time Verifiably Encrypted Signatures (VES)&quot;</a>:</p>
<blockquote>
<p>Abstract. With advances in cryptography, it became possible to implement atomic swaps between Bitcoin (BTC) and Monero (XMR) and two such protocols have been successfuly demonstrated. However, the protocols require the scriptable network to have 2nd-party malleability solved and list SegWit as a requirement. With advances in Bitcoin Cash (BCH) smart contract capabilities, it became possible to implement an equivalent atomic swap protocol despite BCH network not having SegWit.</p>
<p>In this work, we present our solution to cross-chain atomic swaps between Bitcoin Cash (BCH) and Monero (XMR), using adaptor signatures and discrete logarithm equivalence proofs. Our solution uses newly available native introspection opcodes to commit to transactions contents, making it immune to 2nd-party malleability, and with transaction size significantly reduced compared to previous work. We also introduce a cross-chain atomic swap between Bitcoin Cash (BCH) and Bitcoin (BTC), using similar approach.</p>
</blockquote>

CC BY-SA 4.0
2024-10-23T15:32:05.563Z
2024-10-23T15:32:05.563Z
bca-0353f40e
<p>The main benefit of <code>segwit</code> transactions is that the TXID does not depend on the witness part of transaction where signature is placed. So, if TX0 in known (but not signed yet) we can sign the TX1.</p>

CC BY-SA 4.0
2024-10-23T11:27:55.350Z
2024-10-23T11:27:55.350Z
amaclin
<p>Segwit introduces a witness section to transactions. Instead of having the signature data in the input script, segwit inputs provide signature data in the corresponding witness stack that appears in the witness section. The txid is still calculated from the non-segwit transaction data, so if a transaction only has segwit inputs, the txid no longer depends on signature data. This permits Alice and Bob to calculate the txid of Tx<sub>0</sub> before it is signed.</p>
<p>The ability to calculate txids before signing a transaction was one of the design goals of segwit as it allows lightning participants to create a refund transaction before signing the funding transaction.</p>
<hr />
<p>Addressing your follow-up:</p>
<blockquote>
<p>Thanks. I know what you mean. There is one statement in book as below. There’s no circular dependency here and, if we ignore third-party transaction malleability, this looks like it should provide us with a trustless protocol. here, i think it describe the legacy tx format, and SegWit has not been introduced yet. So, why There’s no circular dependency here?</p>
</blockquote>
<p>There is only no circular dependency here only if Tx<sub>0</sub> is a segwit transaction. If Tx<sub>0</sub> is described as a legacy transactions, it is impossible for Alice and Bob to create signatures for Tx<sub>1</sub> before Tx<sub>0</sub> has been signed as the inputs of Tx<sub>1</sub> would depend on the txid of Tx<sub>0</sub> which can only be known after Tx<sub>0</sub> is signed.</p>
<p>Please raise an issue in the book’s repository so that the book will be improved in that section.</p>

CC BY-SA 4.0
2024-10-23T13:48:04.120Z
2024-11-08T15:27:04.463Z
2024-11-08T15:27:04.463Z
Murch
<p>In the book &quot;Mastering Bitcoin&quot;, 3rd edition, page 136, there is the statement quoted below.</p>
<blockquote>
<p>&quot;Tx1 spends the second output of Tx0 to two new outputs, one to Alice
for her share of the joint funds, and one to Bob for his share. Alice
and Bob both sign this transaction before they sign Tx0.&quot;</p>
</blockquote>
<p>Why can Alice and Bob both sign transaction tx1 before they sign Tx0? Isn’t it a problem that the txid of tx0 is part of the data needed to generate the txid of tx1?</p>
<p>I know 2nd malleability is about randomness included in the ECDSA signature, but I just want to know if the statement above is right?</p>
<p>reference link:
<a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc" rel="nofollow noreferrer">https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc</a></p>
<p>Thanks!</p>

<transaction-malleability><mastering-bitcoin>
Second-Party Transaction Malleability in book "mastering bitcoin" third edition
fa william
# Second-Party Transaction Malleability in book "mastering bitcoin" third edition

(Asked by: username_0 on 2024-10-23)

In the book "Mastering Bitcoin", 3rd edition, page 136, there is the statement quoted below.

> "Tx1 spends the second output of Tx0 to two new outputs, one to Alice
> for her share of the joint funds, and one to Bob for his share. Alice
> and Bob both sign this transaction before they sign Tx0."

Why can Alice and Bob both sign transaction tx1 before they sign Tx0? Isn’t it a problem that the txid of tx0 is part of the data needed to generate the txid of tx1?

I know 2nd malleability is about randomness included in the ECDSA signature, but I just want to know if the statement above is right?

reference link:
<https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc>

Thanks!

**Tags:** transaction-malleability, mastering-bitcoin


---

## 3 answers

### Answer by username_1 on 2024-10-23. Score: 2 | Accepted answer

Because with SegWit, the signatures aren't part of TXID preimage, so regenerating a signature with a new nonce won't change the TXID.

To understand the problem of 2nd-party malleability you must first understand how multisig is used to emulate covenants in order to enforce payment flow, to create immutable money switches. If it is just one switch, then 2nd-party malleability is not a problem. However, if a switch sends money to another such switch, then 2nd-party malleability becomes a problem.

A scheme like this would be vulnerable to 2nd-party malleability:

```
-- switch0 -- switch0_0 -- payout0
            |
            \ switch0_1 -- switch1 -- switch1_0 -- payout1
                                    |
                                    \ switch1_1 -- payout2

```

But why?

Because each switch is something like

```
if(switch) {
    require 2-of-2 signature for TX paying to payout0
} else {
    require 2-of-2 signature for TX paying to switch1
    checktimelockverify
}

```

Parties A and B will exchange all signatures in all the paths before even funding switch0, so later the other party can't change their mind and hold money hostage.

Suppose party A will have B's signature for 0\_0 and 1\_0, and party B will have A's signature for 0\_1 and 1\_1.

Now, suppose party A tries to go through to payout1. It already has B's signatures, so A just has to generate theirs and submit the 2 TXs, right?

OK, so party A submits the 1st TX. BUT. B is monitoring the mempool, sees that, and then extracts A's signature from the TX and generates a **new** signature by B and somehow has the new version mined rather than the original. The outputs of the TX can't be changed by B, he's just changing the nonce, but without SegWit that will change the TXID.

Now A wants to complete the path by spending from switch1, but A can't do it anymore, because the signature by B it has is not good anymore because the prevout reference has changed and signature has become invalid. Now A is stuck, and B is holding A hostage.

With SegWit, if B would generate a new signature it wouldn't change the TXID, so the next signature wouldn't get invalidated and A could go through with the TX.

That isn't the only way to address malleability. What if we had signatures that don't sign the prevout ref parts of the TX? Then A could simply update the prevout refs and the pre-signed signature by B would still be good.

[Lightning Network whitepaper](https://lightning.network/lightning-network-paper.pdf) was originally proposing this as a solution:

> SIGHASH NOINPUT would neither sign any input transactions IDs nor sign the index. By using SIGHASH NOINPUT, one can be assured that one's counterparty cannot invalidate entire trees of chained transactions of potential contract states which were previously agreed upon, using transaction ID mutation. With the new sighash flags, it is possible to spend from a parent transaction even though the transaction ID has changed, so long as the script evaluates as true (i.e. a valid signature).
>
> SIGHASH NOINPUT implies significant risk with address reuse, as it can work with any transaction in which the sigScript returns as valid, so multiple transactions with the same outputs are redeemable (provided the output values are less).
>
> Further, and just as importantly, SIGHASH NOINPUT permits participants to sign spends of transactions without knowing the signatures of the transaction being spent. By solving malleability in the above manner, two parties may build contracts and spend transactions without either party having the ability to broadcast that original transaction on the blockchain until both parties agree. With the new sighash type, participants may build potential contract states and potential payout conditions and agree upon all terms, before the contract may be paid, broadcast, and executed upon without the need for a trusted third party.

Later, a non-segwit network (Bitcoin Cash - BCH) adopted a similar approach to solve the 2nd-party malleability problem and implement a 2-stage-refund cross-chain swap, see ["Cross-chain Atomic Swaps With Bitcoin Cash (BCH) Using One-Time Verifiably Encrypted Signatures (VES)"](https://gitlab.com/0353F40E/cross-chain-swap-ves/-/blob/master/README.md):

> Abstract. With advances in cryptography, it became possible to implement atomic swaps between Bitcoin (BTC) and Monero (XMR) and two such protocols have been successfuly demonstrated. However, the protocols require the scriptable network to have 2nd-party malleability solved and list SegWit as a requirement. With advances in Bitcoin Cash (BCH) smart contract capabilities, it became possible to implement an equivalent atomic swap protocol despite BCH network not having SegWit.
>
> In this work, we present our solution to cross-chain atomic swaps between Bitcoin Cash (BCH) and Monero (XMR), using adaptor signatures and discrete logarithm equivalence proofs. Our solution uses newly available native introspection opcodes to commit to transactions contents, making it immune to 2nd-party malleability, and with transaction size significantly reduced compared to previous work. We also introduce a cross-chain atomic swap between Bitcoin Cash (BCH) and Bitcoin (BTC), using similar approach.


---

### Answer by username_2 on 2024-10-23. Score: 1

The main benefit of `segwit` transactions is that the TXID does not depend on the witness part of transaction where signature is placed. So, if TX0 in known (but not signed yet) we can sign the TX1.


---

### Answer by username_3 on 2024-10-23. Score: 1

Segwit introduces a witness section to transactions. Instead of having the signature data in the input script, segwit inputs provide signature data in the corresponding witness stack that appears in the witness section. The txid is still calculated from the non-segwit transaction data, so if a transaction only has segwit inputs, the txid no longer depends on signature data. This permits Alice and Bob to calculate the txid of Tx0 before it is signed.

The ability to calculate txids before signing a transaction was one of the design goals of segwit as it allows lightning participants to create a refund transaction before signing the funding transaction.

---

Addressing your follow-up:

> Thanks. I know what you mean. There is one statement in book as below. There’s no circular dependency here and, if we ignore third-party transaction malleability, this looks like it should provide us with a trustless protocol. here, i think it describe the legacy tx format, and SegWit has not been introduced yet. So, why There’s no circular dependency here?

There is only no circular dependency here only if Tx0 is a segwit transaction. If Tx0 is described as a legacy transactions, it is impossible for Alice and Bob to create signatures for Tx1 before Tx0 has been signed as the inputs of Tx1 would depend on the txid of Tx0 which can only be known after Tx0 is signed.

Please raise an issue in the book’s repository so that the book will be improved in that section.


---

