As a result of with SegWit, the signatures aren’t a part of TXID preimage, so regenerating a signature with a brand new nonce will not change the TXID.
To grasp the issue of 2nd-party malleability you could first perceive how multisig is used to emulate covenants with a purpose to implement cost circulation, to create immutable cash switches. If it is only one change, then 2nd-party malleability shouldn’t be an issue. Nevertheless, if a change sends cash to a different such change, then 2nd-party malleability turns into an issue.
A scheme like this might be susceptible to 2nd-party malleability:
-- switch0 -- switch0_0 -- payout0
|
switch0_1 -- switch1 -- switch1_0 -- payout1
|
switch1_1 -- payout2
However why?
As a result of every change is one thing like
if(change) {
require 2-of-2 signature for TX paying to payout0
} else {
require 2-of-2 signature for TX paying to switch1
checktimelockverify
}
Events A and B will trade all signatures in all of the paths earlier than even funding switch0, so later the opposite get together cannot change their thoughts and maintain cash hostage.
Suppose get together A could have B’s signature for 0_0 and 1_0, and get together B could have A’s signature for 0_1 and 1_1.
Now, suppose get together A tries to undergo to payout1. It already has B’s signatures, so A simply has to generate theirs and submit the two TXs, proper?
OK, so get together A submits the first TX. BUT. B is monitoring the mempool, sees that, after which extracts A’s signature from the TX and generates a new signature by B and by some means has the brand new model mined moderately than the unique. The outputs of the TX cannot be modified by B, he is simply altering the nonce, however with out SegWit that may change the TXID.
Now A needs to finish the trail by spending from switch1, however A cannot do it anymore, as a result of the signature by B it has shouldn’t be good anymore as a result of the prevout reference has modified and signature has turn out to be invalid. Now A is caught, and B is holding A hostage.
With SegWit, if B would generate a brand new signature it would not change the TXID, so the subsequent signature would not get invalidated and A may undergo with the TX.
That is not the solely solution to handle malleability. What if we had signatures that do not signal the prevout ref elements of the TX? Then A may merely replace the prevout refs and the pre-signed signature by B would nonetheless be good.
Lightning Community whitepaper was initially proposing this as an answer:
SIGHASH NOINPUT would neither signal any enter transactions IDs nor signal the index. Through the use of SIGHASH NOINPUT, one might be assured that one’s counterparty can’t invalidate total timber of chained transactions of potential contract states which had been beforehand agreed upon, utilizing transaction ID mutation. With the brand new sighash flags, it’s potential to spend from a mum or dad transaction despite the fact that the transaction ID has modified, as long as the script evaluates as true (i.e. a legitimate signature).
SIGHASH NOINPUT implies important threat with handle reuse, as it will possibly work with any transaction wherein the sigScript returns as legitimate, so a number of transactions with the identical outputs are redeemable (offered the output values are much less).
Additional, and simply as importantly, SIGHASH NOINPUT permits individuals to signal spends of transactions with out understanding the signatures of the transaction being spent. By fixing malleability within the above method, two events could construct contracts and spend transactions with out both get together being able to broadcast that unique transaction on the blockchain till each events agree. With the brand new sighash kind, individuals could construct potential contract states and potential payout circumstances and agree upon all phrases, earlier than the contract could also be paid, broadcast, and executed upon with out the necessity for a trusted third get together.
Later, a non-segwit community (Bitcoin Money – BCH) adopted an analogous strategy to unravel the 2nd-party malleability downside and implement a 2-stage-refund cross-chain swap, see “Cross-chain Atomic Swaps With Bitcoin Money (BCH) Utilizing One-Time Verifiably Encrypted Signatures (VES)”:
Summary. With advances in cryptography, it turned potential to implement atomic swaps between Bitcoin (BTC) and Monero (XMR) and two such protocols have been successfuly demonstrated. Nevertheless, the protocols require the scriptable community to have 2nd-party malleability solved and checklist SegWit as a requirement. With advances in Bitcoin Money (BCH) sensible contract capabilities, it turned potential to implement an equal atomic swap protocol regardless of BCH community not having SegWit.
On this work, we current our answer to cross-chain atomic swaps between Bitcoin Money (BCH) and Monero (XMR), utilizing adaptor signatures and discrete logarithm equivalence proofs. Our answer makes use of newly accessible native introspection opcodes to decide to transactions contents, making it resistant to 2nd-party malleability, and with transaction measurement considerably diminished in comparison with earlier work. We additionally introduce a cross-chain atomic swap between Bitcoin Money (BCH) and Bitcoin (BTC), utilizing related strategy.
