<p>Yes, you are correct. Joseph Poon and Tadje Dryja in their <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">Lightning Network whitepaper</a> proposed the <code>SIGHASH_NOINPUT</code> flag to prevent transaction malleability flaw hampering the creation of commitment transaction prior to funding transaction. However, with the deployment of SegWit in 2017, <code>NOINPUT</code> was not longer needed as <a href="https://bitcoin.stackexchange.com/questions/89256/how-to-calculate-txid-for-segwit-transactions">signatures are not part of the <code>txid</code> construction</a> in a SegWit transaction. Since signatures did not form the part of the <code>txid</code> calculation, it solved the ECDSA signature malleability issue that <code>NOINPUT</code> was trying to solve. Thus SegWit deployment allowed us to create the commitment transaction even before signing the funding transaction.</p>

<p>Lightning Network specs have gone a sea change since that paper was published way back in early 2016. I have tried to highlight below how the parties communicate the signing of the transactions as is today and proposals of the future when opening up a channel with each other.</p>

<p>In the current specs (<a href="https://github.com/lightningnetwork/lightning-rfc/" rel="nofollow noreferrer">BOLT 1.0</a>), only one party is allowed to contribute bitcoins to the channel. This simplifies the process of exchanging signatures and creating the commitment transaction prior to the funding transaction. Let us say Alice and Bob wants to open a channel. Alice will broadcast the funding transaction only when she has received Bob's signature for the commitment transaction that she holds. Since Alice is the sole funder over here, she has all ammunition to create the funding transaction after Bob exchanges his funding pub key. She creates and signs the transaction, calculates the <code>txid</code> and then shares it with Bob along with her commitment transaction signature that Bob is holding.</p>

<p>Currently <a href="https://github.com/lightningnetwork/lightning-rfc/pull/524" rel="nofollow noreferrer">there is a proposal</a> (BOLT 1.1) for allowing both parties to contribute funds to the channel. Both parties help each other to build the funding transaction by sharing the inputs and outputs of the funding transaction with each other that they plan to use to fund the channel. It is important to note that they share all information apart from the signatures for those inputs. Once both of them have shared all the inputs and outputs, the parties have enough information to calculate the funding <code>txid</code>. This is because SegWit transactions signatures are not included in calculation of the <code>txid</code> (as mentioned before). This allows us to build the first commitment transaction even before the funding transaction has been created.</p>

<p><strong>Note:</strong> Currently, as is, Lightning Network implementation does not require the <code>NOINPUT</code> flag. But to implement the Eltoo payment construction there is a proposal to introduce <code>SIGHASH_NOINPUT</code>. In a nutshell, Eltoo allows us to get rid of the penalty transactions and reduce a lot of overhead on maintaining the channel states. If you are interested you can read <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002176.html" rel="nofollow noreferrer">the discussion of this proposal</a> on the Lightning mailing list.</p>

CC BY-SA 4.0
2019-10-29T17:14:47.870Z
Fantastic response, thanks! I know Tad & Joseph are very capable so I wanted to make sure the errata was reported correctly. Prior to NOINPUT and SegWit, the example I've posted is Dead on Conception because the refund/commitment cannot be guaranteed in a trustless manner. I'm hopping into the discussion archive now. What is the best discussion forum to actively contribute feedback and proposals to LN?
GViz
CC BY-SA 4.0
2019-10-29T17:23:30.493Z
@GViz You can propose and give feedback on the Lightning Dev email list. You can register in the mailing list [here](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). For full info on the lightning network specs you can refer to [BOLTs on Github Page](https://github.com/lightningnetwork/lightning-rfc). Open source github pages for lightning network implementations are: (1) [C-Lightning](https://github.com/ElementsProject/lightning); (2) [LND](https://github.com/lightningnetwork/lnd); (3) [Eclair](https://github.com/ACINQ/eclair)
Ugam Kamat
CC BY-SA 4.0
2019-10-29T05:04:06.590Z
2019-10-29T06:05:57.343Z
2019-10-29T06:05:57.343Z
Ugam Kamat
<p>I was watching <a href="https://www.youtube.com/watch?v=jyDE-aFqJTs" rel="nofollow noreferrer">Tadje Dryja's talk</a> at SF Bitcoin Devs conference on transaction malleability, which formed part of the basis behind the Lightning Network.
<a href="https://i.sstatic.net/ZrvYu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ZrvYu.png" alt="enter image description here"></a></p>

<p>At 17'45", I saw this example. Prior to SegWit and even before considering malleability, how is it possible to even sign a refund txn without knowing the TX-fund signatures? The funding signatures from both parties are required to create the <code>txid</code> that is referenced in the TX-refund input. However, if this information is known, one of the parties can send the funding txn to the network before a refund txn is ever signed, thus forcing the other party's funds into the multi-sig contract. Am I missing something? </p>

<p>(I think SIGHASH_NOINPUT was introduced to get around this exact limitation.)</p>

<lightning-network><multi-signature><transaction-malleability>
Multisig refund transaction flaw in Lightning Network talk
GViz
# Multisig refund transaction flaw in Lightning Network talk

(Asked by: username_0 on 2019-10-28)

I was watching [Tadje Dryja's talk](https://www.youtube.com/watch?v=jyDE-aFqJTs) at SF Bitcoin Devs conference on transaction malleability, which formed part of the basis behind the Lightning Network.
[![enter image description here](https://i.sstatic.net/ZrvYu.png)](https://i.sstatic.net/ZrvYu.png)

At 17'45", I saw this example. Prior to SegWit and even before considering malleability, how is it possible to even sign a refund txn without knowing the TX-fund signatures? The funding signatures from both parties are required to create the `txid` that is referenced in the TX-refund input. However, if this information is known, one of the parties can send the funding txn to the network before a refund txn is ever signed, thus forcing the other party's funds into the multi-sig contract. Am I missing something?

(I think SIGHASH\_NOINPUT was introduced to get around this exact limitation.)

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


---

## 1 answers

### Answer by username_1 on 2019-10-29. Score: 1 | Accepted answer

Yes, you are correct. Joseph Poon and Tadje Dryja in their [Lightning Network whitepaper](https://lightning.network/lightning-network-paper.pdf) proposed the `SIGHASH_NOINPUT` flag to prevent transaction malleability flaw hampering the creation of commitment transaction prior to funding transaction. However, with the deployment of SegWit in 2017, `NOINPUT` was not longer needed as [signatures are not part of the `txid` construction](https://bitcoin.stackexchange.com/questions/89256/how-to-calculate-txid-for-segwit-transactions) in a SegWit transaction. Since signatures did not form the part of the `txid` calculation, it solved the ECDSA signature malleability issue that `NOINPUT` was trying to solve. Thus SegWit deployment allowed us to create the commitment transaction even before signing the funding transaction.

Lightning Network specs have gone a sea change since that paper was published way back in early 2016. I have tried to highlight below how the parties communicate the signing of the transactions as is today and proposals of the future when opening up a channel with each other.

In the current specs ([BOLT 1.0](https://github.com/lightningnetwork/lightning-rfc/)), only one party is allowed to contribute bitcoins to the channel. This simplifies the process of exchanging signatures and creating the commitment transaction prior to the funding transaction. Let us say Alice and Bob wants to open a channel. Alice will broadcast the funding transaction only when she has received Bob's signature for the commitment transaction that she holds. Since Alice is the sole funder over here, she has all ammunition to create the funding transaction after Bob exchanges his funding pub key. She creates and signs the transaction, calculates the `txid` and then shares it with Bob along with her commitment transaction signature that Bob is holding.

Currently [there is a proposal](https://github.com/lightningnetwork/lightning-rfc/pull/524) (BOLT 1.1) for allowing both parties to contribute funds to the channel. Both parties help each other to build the funding transaction by sharing the inputs and outputs of the funding transaction with each other that they plan to use to fund the channel. It is important to note that they share all information apart from the signatures for those inputs. Once both of them have shared all the inputs and outputs, the parties have enough information to calculate the funding `txid`. This is because SegWit transactions signatures are not included in calculation of the `txid` (as mentioned before). This allows us to build the first commitment transaction even before the funding transaction has been created.

**Note:** Currently, as is, Lightning Network implementation does not require the `NOINPUT` flag. But to implement the Eltoo payment construction there is a proposal to introduce `SIGHASH_NOINPUT`. In a nutshell, Eltoo allows us to get rid of the penalty transactions and reduce a lot of overhead on maintaining the channel states. If you are interested you can read [the discussion of this proposal](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002176.html) on the Lightning mailing list.

> **Comments:**
> **username_0**: Fantastic response, thanks! I know Tad & Joseph are very capable so I wanted to make sure the errata was reported correctly. Prior to NOINPUT and SegWit, the example I've posted is Dead on Conception because the refund/commitment cannot be guaranteed in a trustless manner. I'm hopping into the discussion archive now. What is the best discussion forum to actively contribute feedback and proposals to LN?  
> **username_1**: @username_0 You can propose and give feedback on the Lightning Dev email list. You can register in the mailing list [here](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). For full info on the lightning network specs you can refer to [BOLTs on Github Page](https://github.com/lightningnetwork/lightning-rfc). Open source github pages for lightning network implementations are: (1) [C-Lightning](https://github.com/ElementsProject/lightning); (2) [LND](https://github.com/lightningnetwork/lnd); (3) [Eclair](https://github.com/ACINQ/eclair)  

---

