malleability in 2-of-2 multisig payment channel

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?

user62261

Posted 2017-10-20T16:51:07.683

Reputation: 1

Answers

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.

Andrew Chow

Posted 2017-10-20T16:51:07.683

Reputation: 40 910

1Creating SegWit outputs is not a requirement for non-malleability. – Pieter Wuille – 2017-10-20T21:05:21.657