Why was transaction malleability fix required for Lightning network?

Question

Transaction malleability is that TXID can be changed modifying the signature slightly without the private key. To implement Lightning Network, it was required to fix the malleability.

However, I thought that we just wait for 1 confirmation that we create an opening transaction, which is 2 of 2 Multisig, in order to open a channel.

After researching Lightning network protocol, I kind of found out that before broadcasting the opening transaction, we have to create a commitment transaction that needs the TXID of the opening transaction, and we have to keep it to claim. If the TXID is changed, the commitment transaction won’t be valid. So we needed to fix transaction malleability to keep the commitment transaction valid.

Is this correct? If not, please educate me.

Answer 1

Alice creates a multisig transaction sending 100btc to a shared Alice-Bob output–one that requires both signatures–and signs it. We’ll call this transaction Tx0. And she only reveals Tx0 to Bob after:

Alice and Bob each sign a timelocked transaction for 30 days from now, sending 100btc back to Alice. This is not committed to the blockchain, and opens a “channel” between them.

Uncommitted transaction has dependency over Tx0. After Alice reveals Tx0 to Bob, if Bob successfully changes the transaction hash for Tx0 on blockchain, then uncommitted transaction will become invalid and Alice will not be able to claim 100btc back.

If, in addition to requiring the refund Tx, Alice also requires Bob to sign Tx0 before she does so that only she can submit Tx0 to the blockchain, this attack would not work.

Answer 2

The punishment transaction construction requires an immutable commitment transaction. Transaction malleability was an issue in that regard because it allows for more than one valid version of the same transaction.*

Before the funding transaction is committed to the blockchain, the two channel partners are exchanging commitment transactions that allow each party to unilaterally reclaim their portion of the funds. Whenever a payment is made on the channel, the channel partners exchange updated versions of the commitment transactions. To invalidate outdated states, each party provides a breach remedy to their counterparty which allows the counterparty to claim all funds in the channel if the old state is broadcast. The breach remedy is a second transaction that spends the output of the counterparty's commitment transaction. Hence, the breach remedy construction required the commitment transaction to be immutable.

Additionally, segwit solves another problem. For non-segwit transactions, the transaction id (txid) can only be calculated after a transaction is signed. Hence, a commitment transaction that allows fund recovery could only be constructed after the funding transaction was already fully committed to. Since the witness does not contribute to the txid of segwit transactions, funding a channel from segwit funds simplifies the exchange of information for the construction of commitment transactions.

Answer 3

Lightning network channels are a multi signature operation, if Alice and Bob open a channel, both are signing a contract where they agree the terms, so both sign.

If changing the signature of the transaction (if transaction malleability) is allowed. One side could modify/invalidate the contract.

that why it was fixed