Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-16 📝 Original message: On 16 January 2017 at ...
đź“… Original date posted:2017-01-16
đź“ť Original message:
On 16 January 2017 at 10:30, Rusty Russell <rusty at rustcorp.com.au> wrote:
> "Andrés G. Aragoneses " <knocte at gmail.com> writes:
> > Hi there,
> >
> > Seems like the list is a bit dormant these days.
>
> Yes, most of the activity has been on the github repository:
>
> https://github.com/lightningnetwork/lightning-rfc
>
>
That's good! I will ask some question about that, bu in a different
thread...
> > Is it because of the low chances of SegWit activation given that it
> stalled
> > at ~26%?
> >
> > On this topic, I would like to ask about the feasibility of LN without
> > SegWit, given these circumstances.
> >
> > Some has been said in the past, I've been reading through the archives.
> But
> > in them, everybody seemed overly enthusiastic about the activation of
> > SegWit (maybe given that OP_CLTV and OP_CSV activated without hassle).
>
> If segwit doesn't activate, something is badly broken in Bitcoin. This
> is not really a lightning issue; there's been no significant technical
> objection to segwit, and it really does make Bitcoin work better.
>
True.
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.
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).
>
> I'm glad that miners are cautious with their upgrades, and segwit
> adoption will take time to roll out across products anyway. Let's look
> again in 6 months.
>
> > Which one is more accurate? Is the security problems only related to
> having
> > to watch the blockchain? If yes, why cannot one outsource this job to a
> > server (e.g. the hypothetical server of your light-wallet) in level2?
>
> Yes, the problem is outsourcing. You can't hand the outsourcer a
> penalty transaction signature if you don't know what the bad transaction
> will look like. And if the signatures are part of the transaction ID,
> you don't.
>
Can you elaborate on this? From my limited understanding, I guess you're
referring to detecting a broadcast of a transaction of a previous state of
the payment channel. In this case, the HTLC-clock of the revocation
transaction starts ticking, and the transaction to revoke this malicious
move would need the ID of the transaction used to broadcast the bad state.
Right?
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?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/13603bc4/attachment.html>;
đź“ť Original message:
On 16 January 2017 at 10:30, Rusty Russell <rusty at rustcorp.com.au> wrote:
> "Andrés G. Aragoneses " <knocte at gmail.com> writes:
> > Hi there,
> >
> > Seems like the list is a bit dormant these days.
>
> Yes, most of the activity has been on the github repository:
>
> https://github.com/lightningnetwork/lightning-rfc
>
>
That's good! I will ask some question about that, bu in a different
thread...
> > Is it because of the low chances of SegWit activation given that it
> stalled
> > at ~26%?
> >
> > On this topic, I would like to ask about the feasibility of LN without
> > SegWit, given these circumstances.
> >
> > Some has been said in the past, I've been reading through the archives.
> But
> > in them, everybody seemed overly enthusiastic about the activation of
> > SegWit (maybe given that OP_CLTV and OP_CSV activated without hassle).
>
> If segwit doesn't activate, something is badly broken in Bitcoin. This
> is not really a lightning issue; there's been no significant technical
> objection to segwit, and it really does make Bitcoin work better.
>
True.
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.
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).
>
> I'm glad that miners are cautious with their upgrades, and segwit
> adoption will take time to roll out across products anyway. Let's look
> again in 6 months.
>
> > Which one is more accurate? Is the security problems only related to
> having
> > to watch the blockchain? If yes, why cannot one outsource this job to a
> > server (e.g. the hypothetical server of your light-wallet) in level2?
>
> Yes, the problem is outsourcing. You can't hand the outsourcer a
> penalty transaction signature if you don't know what the bad transaction
> will look like. And if the signatures are part of the transaction ID,
> you don't.
>
Can you elaborate on this? From my limited understanding, I guess you're
referring to detecting a broadcast of a transaction of a previous state of
the payment channel. In this case, the HTLC-clock of the revocation
transaction starts ticking, and the transaction to revoke this malicious
move would need the ID of the transaction used to broadcast the bad state.
Right?
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?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/13603bc4/attachment.html>;