lightning-dev

LN without SegWit: less efficient or less secure?

LN without SegWit: less efficient or less secure?

Original Postby Christian Decker

Posted on: January 16, 2017 12:46 UTC

Andres G.

Aragoneses wrote a message on the Lightning-dev mailing list, suggesting that miners are afraid of losing their fee-gathering monopoly for moving money to layer2-actors (payment hubs), given that it will be much easier to spawn paymenthub nodes than mining nodes. However, this is a common misconception since Lightning does not reduce the fees that the miners may collect; instead, it increases their reach into transactions that they could not otherwise serve. Lightning requires higher-than-average fees for setup and settlement, but coins on these channels may have been transferred hundreds if not millions of times back and forth, so this amortizes the high on-chain fees over time. With the extension of Bitcoin's reach and the higher than usual fees for setup and settlement, miners will have a net gain when Lightning rolls out since it opens up new possibilities.Andres suggests that the only way to move forward would be to start running layer2 solutions in production in spite of the technical difficulties that SegWit non-activation implies. Then, when miners realize they cannot halt progress on layer2 development, they will probably start assuming they need to give up blocking, for the sake of not stagnating the currency. Andres also asks if it would be possible to have an alternative Lightning-Level2 without SegWit, but still with CSV. He suggests using shorter locktimes like the Spillman-style payment channels do every time there's a need to change direction. He wonders if there is a way to create OP_CLTV/OP_CSV-style channels (instead of nLockTime-based, so malleability resistant) without using revocation methods. The protocol Duplex Micropayment Channels does just that, but it has been neglected lately and simply is not at the same development level as Lightning is. Furthermore, it assumes that we have a malleability fix, otherwise, the invalidation tree construction does not work.