Why was transaction malleability fix required for Lightning network? 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.
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.