<p>The lightning network as is is working without SIGHASH_NOINPUT. Thus in its current form it is not needed. </p>

<p>However Christian Decker came up with the eltoo payment channel construction. In a nutshell this would get rid of the penalty based construction we use right now and reduce a lot of overhead for maintaining channel state as the state becomes symmetrical for all participants. </p>

<p>In particular multiparty channels and channel factories would become much easier. </p>

<p>The eltoo paper however really depends on SIGHASH_NOINPUT as the channel state is encoded as a "linked" list of update transactions which in case of protocol breach are skipped from the breaching point to the current channel state which requires SIGHASH_NOINPUT. </p>

<p>It is my understanding that essentially all lightning network developers agree that lightning network channels should eventually be constructed via eltoo. </p>

<p>You can read a <a href="https://www.rene-pickhardt.de/index.html%3Fp=2116.html" rel="noreferrer">summary of eltoo on my blog</a> or you can <a href="https://blockstream.com/eltoo.pdf" rel="noreferrer">read the original publication</a> to learn more.</p>

CC BY-SA 4.0
2020-02-23T18:30:39.613Z
Thanks for your answer. Unfortunately the formatting of your blog looks corrupted.
Thorkil Værge
CC BY-SA 4.0
2019-05-02T18:51:30.987Z
2019-05-03T01:31:32.597Z
2019-05-03T01:31:32.597Z
Rene Pickhardt
<p>In the original Lightning whitepaper, Joseph Poon advocates using <code>SIGHASH_NOINPUT</code> so that we can create the first commitment transaction which references the funding transaction <code>txid</code> without actually signing the funding transaction. However that paper was written before SegWit was implemented. Given that SegWit transactions do not have signature component in the <code>txid</code>, it removes the need to actually implement <code>SIGHASH_NOINPUT</code>. </p>

<p>However, today I came across a draft proposal of the sighash in <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki" rel="noreferrer">BIP 118</a> which says it would be active with SegWit v1 and higher. </p>

<p>Am I missing anything else that this sighash flag brings to the table that would warrant it to be implemented in future SegWit versions?</p>

CC BY-SA 4.0
2019-05-02T20:48:37.510Z
For the most in-depth discussion, search the bitcoin-dev mailing list for SIGHASH_NOINPUT https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/
chytrik
<lightning-network><sighash-flags><sighash><bip118-sighash-anyprevout>
Do we still need SIGHASH_NOINPUT for Lightning Network?
Ugam Kamat
# Do we still need SIGHASH_NOINPUT for Lightning Network?

(Asked by: username_0 on 2019-05-02)

In the original Lightning whitepaper, Joseph Poon advocates using `SIGHASH_NOINPUT` so that we can create the first commitment transaction which references the funding transaction `txid` without actually signing the funding transaction. However that paper was written before SegWit was implemented. Given that SegWit transactions do not have signature component in the `txid`, it removes the need to actually implement `SIGHASH_NOINPUT`.

However, today I came across a draft proposal of the sighash in [BIP 118](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki) which says it would be active with SegWit v1 and higher.

Am I missing anything else that this sighash flag brings to the table that would warrant it to be implemented in future SegWit versions?

**Tags:** lightning-network, sighash-flags, sighash, bip118-sighash-anyprevout

> **Comments:**
> **username_1**: For the most in-depth discussion, search the bitcoin-dev mailing list for SIGHASH_NOINPUT https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/  

---

## 1 answers

### Answer by username_2 on 2019-05-02. Score: 15 | Accepted answer

The lightning network as is is working without SIGHASH\_NOINPUT. Thus in its current form it is not needed.

However Christian Decker came up with the eltoo payment channel construction. In a nutshell this would get rid of the penalty based construction we use right now and reduce a lot of overhead for maintaining channel state as the state becomes symmetrical for all participants.

In particular multiparty channels and channel factories would become much easier.

The eltoo paper however really depends on SIGHASH\_NOINPUT as the channel state is encoded as a "linked" list of update transactions which in case of protocol breach are skipped from the breaching point to the current channel state which requires SIGHASH\_NOINPUT.

It is my understanding that essentially all lightning network developers agree that lightning network channels should eventually be constructed via eltoo.

You can read a [summary of eltoo on my blog](https://www.username_2.de/index.html%3Fp=2116.html) or you can [read the original publication](https://blockstream.com/eltoo.pdf) to learn more.

> **Comments:**
> **username_3**: Thanks for your answer. Unfortunately the formatting of your blog looks corrupted.  

---

