<blockquote>
  <p>Did I make an error here somewhere in my construct?</p>
</blockquote>

<p>No, you did not. This is indeed an issue for payment channels which can be worked around but reduces the security of a payment channel and increases the complexity of creating a payment channel.</p>

<p>Because malleability poses a problem with payment channels, transactions used for payment channels used in the lightning network make use of Segwit which makes transactions that use Segwit non-malleable. Specifically, for a LN payment channel, the funding transaction must be non-malleable; it must spend from previous segwit outputs and create segwit outputs to allow for future non-malleable transactions.</p>

CC BY-SA 3.0
2017-10-20T21:05:21.657Z
Creating SegWit outputs is not a requirement for non-malleability.
Pieter Wuille
CC BY-SA 3.0
2017-10-20T18:15:32.620Z
2017-10-20T21:11:27.473Z
2017-10-20T21:11:27.473Z
Ava Chow
<p>I am having issues understanding 2-of-2 multisig, with regards to the malleability attack. Where Alice and Bob set up a multisig payment channel where Alice sends 1 BTC in order to do multiple tx afterwards in the payment channel. Where, before Alice can send, Bob needs to sign a 2-of-2 refund over n-locktime.</p>

<p>Alice to MultisigAddr:</p>

<p>1BTC , in: txid-A[n], out: MultisigAddr ---> txid-M[0] </p>

<p>Refund to Alice:</p>

<p>1BTC, in: txid-M[0],out: RefundAliceAddr ---> txid-R[0] with n-locktime, Signed by Bob</p>

<p>In the malleability attack the broadcasted txid-M[0] gets changed to another value, txid-C[0] in order to render the refund to Alice invalid, locking her funds in the multisig channel +-</p>

<p>What I don't understand is how txid-M[0] can be known for Bob to sign the 2of2 multisig transaction for the refund, since it requires the hashing of the transaction from Alice to MultisigAddr first. Did I make an error here somewhere in my construct?</p>

<multi-signature><transaction-malleability>
malleability in 2-of-2 multisig payment channel
user62261
# malleability in 2-of-2 multisig payment channel

(Asked by: username_0 on 2017-10-20)

I am having issues understanding 2-of-2 multisig, with regards to the malleability attack. Where Alice and Bob set up a multisig payment channel where Alice sends 1 BTC in order to do multiple tx afterwards in the payment channel. Where, before Alice can send, Bob needs to sign a 2-of-2 refund over n-locktime.

Alice to MultisigAddr:

1BTC , in: txid-A[n], out: MultisigAddr ---> txid-M[0]

Refund to Alice:

1BTC, in: txid-M[0],out: RefundAliceAddr ---> txid-R[0] with n-locktime, Signed by Bob

In the malleability attack the broadcasted txid-M[0] gets changed to another value, txid-C[0] in order to render the refund to Alice invalid, locking her funds in the multisig channel +-

What I don't understand is how txid-M[0] can be known for Bob to sign the 2of2 multisig transaction for the refund, since it requires the hashing of the transaction from Alice to MultisigAddr first. Did I make an error here somewhere in my construct?

**Tags:** multi-signature, transaction-malleability


---

## 1 answers

### Answer by username_1 on 2017-10-20. Score: 1

> Did I make an error here somewhere in my construct?

No, you did not. This is indeed an issue for payment channels which can be worked around but reduces the security of a payment channel and increases the complexity of creating a payment channel.

Because malleability poses a problem with payment channels, transactions used for payment channels used in the lightning network make use of Segwit which makes transactions that use Segwit non-malleable. Specifically, for a LN payment channel, the funding transaction must be non-malleable; it must spend from previous segwit outputs and create segwit outputs to allow for future non-malleable transactions.

> **Comments:**
> **username_2**: Creating SegWit outputs is not a requirement for non-malleability.  

---

