Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-03 📝 Original message: On Tue, Apr 04, 2023 at ...
📅 Original date posted:2023-04-03
📝 Original message:
On Tue, Apr 04, 2023 at 12:00:32AM +1000, Anthony Towns wrote:
> On Sat, Mar 18, 2023 at 12:41:00AM +0000, jlspc via Lightning-dev wrote:
> > TL;DR
>
> Step 1: Tunable penalties;
> https://github.com/JohnLaw2/ln-tunable-penalties
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html
>
> This is a clever constructions that lets you do a 2-party lightning
> channel with existing opcodes where cheating doesn't result in you
> losing all your funds (or, in fact, any of your in-channel funds).
Ah, a significant difference between this and eltoo is in the game
theory of what happens if you lose access to the latest state.
In eltoo, how things would work in that case, is that you would attempt
to close the channel to an old state that you do still remember (from a
backup), at which point either (a) your counterparty publishes a later
state, and you settle with that (possibly with you paying some modest
penalty if you're using a Daric-like protocol), or (b) your counterparty
does nothing, and you settle at the old state.
With tunable penalties, you are in more of a quandry. If you broadcast
an old "St" transaction to attempt to close to an old state, then your
counterparty will simply claim those funds and penalise you; however
there is nothing forcing them to publish any newer state as well. At
that point your counterparty can hold your share of the channel funds
hostage indefinitely.
Holding your funds hostage is probably an improvement on simply losing
them altogether, of course, so I think this is still a strict improvement
on ln-penalty (modulo additional complexity etc).
Cheers,
aj
📝 Original message:
On Tue, Apr 04, 2023 at 12:00:32AM +1000, Anthony Towns wrote:
> On Sat, Mar 18, 2023 at 12:41:00AM +0000, jlspc via Lightning-dev wrote:
> > TL;DR
>
> Step 1: Tunable penalties;
> https://github.com/JohnLaw2/ln-tunable-penalties
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html
>
> This is a clever constructions that lets you do a 2-party lightning
> channel with existing opcodes where cheating doesn't result in you
> losing all your funds (or, in fact, any of your in-channel funds).
Ah, a significant difference between this and eltoo is in the game
theory of what happens if you lose access to the latest state.
In eltoo, how things would work in that case, is that you would attempt
to close the channel to an old state that you do still remember (from a
backup), at which point either (a) your counterparty publishes a later
state, and you settle with that (possibly with you paying some modest
penalty if you're using a Daric-like protocol), or (b) your counterparty
does nothing, and you settle at the old state.
With tunable penalties, you are in more of a quandry. If you broadcast
an old "St" transaction to attempt to close to an old state, then your
counterparty will simply claim those funds and penalise you; however
there is nothing forcing them to publish any newer state as well. At
that point your counterparty can hold your share of the channel funds
hostage indefinitely.
Holding your funds hostage is probably an improvement on simply losing
them altogether, of course, so I think this is still a strict improvement
on ln-penalty (modulo additional complexity etc).
Cheers,
aj