jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-08 📝 Original message: Comments below: >> Step ...
📅 Original date posted:2023-04-08
📝 Original message:
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
📝 Original message:
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