[Lightning-dev] LN without SegWit: less efficient or less secure?

On Mon, Jan 16, 2017 at 12:57:49PM +0800, Andrés G. Aragoneses wrote: > But I guess we're learning that it can happen that technical improvements > get non-technical impediments. In this case, my rough guess is 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. This is a very common misconception among people. Lightning does not reduce the fees that the miners may collect, it increases their reach into transactions that they could not otherwise serve. Think of it like this, there are nowadays many applications that are completely unfeasible in Bitcoin due to the high transaction fees. The transaction fees are high because an on-chain payment requires a lot of resources, i.e., storage, processing and bandwidth. These applications suddenly become possible with L2 protocols, so this adds to the reach of Bitcoin itself. On the other hand Lightning requires strong guarantees that the transactions will be settled in a certain timeframe, for its security. Hence, Lightning will always attach higher than average fees to the on-chain transactions for setup and settlement of its channels. This is okay since coins on these channels may have been transferred hundreds if not millions of times back and forth, so the these high on-chain fees have been amortized over time, and we happily pay them. With the (1) extension of Bitcoin's reach and (2) the higher than usual fees for setup and settlement, I'm absolutely convinced that miners will have a net gain when Lightning rolls out. Lightning is not cutting into the miner's profit, it opens up new possibilities. > Given this, IMHO 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 (which > would lead to the rise of usage of other chains I suppose). That may not all that easy since it'd require a major overhaul of some parts of the current protocol and would add a lot of complexity that segwit'd allow us to sidestep. > If my assumption was correct, wouldn't it be possible to have an > alternative Lightning-Level2? That is: without SegWit, but still with CSV. > And, instead of using revocation, use shorter locktimes like the > Spillman-style payment channels do (everytime there's a need to change > direction)? I know that Spillman-style channels use nLockTime, which is > vulnerable to malleability; so my question is: is there a way to create > OP_CLTV/OP_CSV-style channels (instead of nLockTime-based, so malleability > resistant) without using revocation methods? We actually have a protocol that does just that: my Duplex Micropayment Channels, but it has been neglected a bit 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. > Thanks > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev