7

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 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?

1

1 Answer 1

15

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 or you can read the original publication to learn more.

1
  • Thanks for your answer. Unfortunately the formatting of your blog looks corrupted. Commented Feb 23, 2020 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.