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 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)”:
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.
