<p>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.*</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2019-04-13T22:08:20.670Z
2019-04-13T22:15:49.903Z
2019-04-13T22:15:49.903Z
Murch
<p>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.</p>

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

<p>that why it was fixed</p>

CC BY-SA 4.0
2019-01-30T04:52:32.813Z
2019-01-30T04:52:32.813Z
Emi
<p>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:</p>

<p>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.</p>

<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2018-01-23T19:49:33.087Z
So it seems to me that my explanation is correct, right?
ogw_yuya
CC BY-SA 3.0
2018-01-23T19:50:51.013Z
Yes. The reasoning was correct.
Preet
CC BY-SA 3.0
2018-01-23T20:00:06.877Z
Also worth to note that without segwit, any third party (and especially a miner) could change the txid of a transaction.  Bob himself is always free to re-sign the transaction using a different nonce value for the signature using his private key, but a 3rd party can also replace the `s` value of any signature with a specific `s'` value (really it is just `n - s`) while keeping the signature valid.
The great thing about segwit is that it protects from both Bob signing with a different nonce (changing the signature completely) and a 3rd party changing the `s` specifically.
arubi
CC BY-SA 4.0
2018-01-23T18:46:53.250Z
2018-12-02T03:53:10.390Z
2018-12-02T03:53:10.390Z
Preet
<p>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.</p>

<p>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.</p>

<p><p>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.</P></p>

<p>Is this correct? If not, please educate me.</p>

CC BY-SA 3.0
2018-02-16T23:48:21.743Z
LN can work without SegWit, even though a bit limited.
Lubo Kanev
<lightning-network><transaction-malleability>
Why was transaction malleability fix required for Lightning network?
ogw_yuya
# Why was transaction malleability fix required for Lightning network?

(Asked by: username_0 on 2018-01-23)

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.

**Tags:** lightning-network, transaction-malleability

> **Comments:**
> **username_1**: LN can work without SegWit, even though a bit limited.  

---

## 3 answers

### Answer by username_4 on 2018-01-23. Score: 6 | Accepted answer

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.

> **Comments:**
> **username_0**: So it seems to me that my explanation is correct, right?  
> **username_4**: Yes. The reasoning was correct.  
> **username_5**: Also worth to note that without segwit, any third party (and especially a miner) could change the txid of a transaction.  Bob himself is always free to re-sign the transaction using a different nonce value for the signature using his private key, but a 3rd party can also replace the `s` value of any signature with a specific `s'` value (really it is just `n - s`) while keeping the signature valid. The great thing about segwit is that it protects from both Bob signing with a different nonce (changing the signature completely) and a 3rd party changing the `s` specifically.  

---

### Answer by username_2 on 2019-04-13. Score: 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 by username_3 on 2019-01-30. Score: -1

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


---

