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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
