Comments below: >> Step 1: Tunable penalties; >> <a >> href="https://github.com/JohnLaw2/ln-tunable-penalties";>https://github.com/JohnLaw2/ln-tunable-penalties</a> >> <a >> href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html";>https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html</a>
>> 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). Yes, that's a good point. I did describe an extension, called "Unilateral Close after an Old Transaction is Put On-Chain", in the Tunable Penalties paper and in the Factory Optimized Channels paper. The idea is to add a Trigger transaction that spends the output of the Funding transaction. In response to seeing the Trigger transaction, the other party can put their final State transaction and (after a to-self-delay) Commitment transaction on-chain. However, if the other party doesn't do so, then after a 3*to-self-delay, the party that forgot the state can initiate the Decker-Wattenhofer protocol to settle the channel. Of course, the eltoo protocol could be used instead of the Decker-Wattenhofer protocol at this point if APO is available. Regards, John _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
