Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-16 📝 Original message: On Mon, Jan 16, 2017 at ...
📅 Original date posted:2017-01-16
📝 Original message:
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
📝 Original message:
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