Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-13 📝 Original message: On Tue, 12 Oct 2021 at ...
📅 Original date posted:2021-10-13
📝 Original message:
On Tue, 12 Oct 2021 at 14:08, Anthony Towns <aj at erisian.com.au> wrote:
>
> If you're willing to accept that "worst case" happening more often, I
> think you could then retain the low latency forwarding, by having the
> transaction structure be:
>
> commitment tx
> input:
> funding tx
> outputs:
> Alice's balance
> (others)
>
> low-latency inflight tx:
> input:
> Alice's balance
> output:
> (1) or (2)
> Alice's remaining balance
>
> Bob claim:
> input:
> (1) [<payment-recovery-delay> CSV bob CHECKSIG]
> output:
> [<bob-revoke> checksigverify <alice> checksig
> ifdup notif <channel-recovery-delay> csv endif]
>
> Too-slow:
> input:
> (2) [<payment-timeout> CLTV alice CHECKSIG]
> output:
> Alice
>
> The idea being:
>
> * Alice sends the low-latency inflight tx which Bob then forwards
> immediately.
>
> * Bob then tries to update the base channel state with Alice, so both
> sides have a commitment to the new payment, and the low-latency
> inflight tx is voided (since it's based on a revoked channel state)
> If this succeeds, everything is fine as usual.
>
> * If Alice is unavailable to confirm that update, Bob closes the
> channel prior to (payment-timeout - payment-recover-delay), and posts
> "Bob claim". After an additional pyment recovery delay (and prior
> to payment-timeout) Bob posts Bob claim, ensuring that the only way
> Alice can claim the funds is if he had posted a revoked state.
>
> * In this case, Alice has at least one payment-recovery-delay period
> prior to the payment-timeout to notice the transaction onchain and
> recover the preimage.
>
> * If Bob posted the low-latency inflight tx later than
> (payment-timeout - payment-recovery-delay) then Alice will have
> payment-recovery-delay time to notice and post the "too-slow" tx and
> claim the funds via the timeout path.
>
> * If Bob posted a revoked state, Alice can also claim the funds via
> Bob claim, provided she notices within the channel-recovery-delay
>
In my mind your "update the base channel state" idea seems to fix
everything by itself. So at T - to_self_delay (or a bit before) you say to
your counterparty "can we lift this HTLC out of your in-flight tx into the
'balance tx' (which will go back to naming a 'commitment tx' since it
doesn't just have balance outputs anymore) so I can use it too? --
otherwise I'll have to close the channel on chain now to force you to
reveal it to me on time?". If they agree, after the revocation and new
commit tx everything is back to (tx symmetric) Poon-Dryja so no need for
extra CSVs. Am I missing something?
I realise this kills some of the elegance of your original protocol and
adds quite a bit of complexity but I think it retains the important
properties.
> That only allows one low-latency payment to be inflight though, which I'm
> not sure is that interesting... It's also kinda complicated, and doesn't
> cover both the low-latency and offline cases, which is disappointing...
>
>
It seems to me lazily lifting the HTLCs into the commitment tx would allow
as many low-latency payments as you want to be in-flight. You would
probably just lift them all up to the commitment tx if you lift one. I
think in the case of nodes that want to keep channel keys offline, having
to go on-chain at T - to_self_delay is not a disaster since it will likely
only be the payment receiver who has their keys offline i.e. the merchant
or end user. So only the last hop would go on chain if the user fails to
claim payment as per usual (just to_self_delay earlier than usual).
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/f94a9551/attachment.html>;
📝 Original message:
On Tue, 12 Oct 2021 at 14:08, Anthony Towns <aj at erisian.com.au> wrote:
>
> If you're willing to accept that "worst case" happening more often, I
> think you could then retain the low latency forwarding, by having the
> transaction structure be:
>
> commitment tx
> input:
> funding tx
> outputs:
> Alice's balance
> (others)
>
> low-latency inflight tx:
> input:
> Alice's balance
> output:
> (1) or (2)
> Alice's remaining balance
>
> Bob claim:
> input:
> (1) [<payment-recovery-delay> CSV bob CHECKSIG]
> output:
> [<bob-revoke> checksigverify <alice> checksig
> ifdup notif <channel-recovery-delay> csv endif]
>
> Too-slow:
> input:
> (2) [<payment-timeout> CLTV alice CHECKSIG]
> output:
> Alice
>
> The idea being:
>
> * Alice sends the low-latency inflight tx which Bob then forwards
> immediately.
>
> * Bob then tries to update the base channel state with Alice, so both
> sides have a commitment to the new payment, and the low-latency
> inflight tx is voided (since it's based on a revoked channel state)
> If this succeeds, everything is fine as usual.
>
> * If Alice is unavailable to confirm that update, Bob closes the
> channel prior to (payment-timeout - payment-recover-delay), and posts
> "Bob claim". After an additional pyment recovery delay (and prior
> to payment-timeout) Bob posts Bob claim, ensuring that the only way
> Alice can claim the funds is if he had posted a revoked state.
>
> * In this case, Alice has at least one payment-recovery-delay period
> prior to the payment-timeout to notice the transaction onchain and
> recover the preimage.
>
> * If Bob posted the low-latency inflight tx later than
> (payment-timeout - payment-recovery-delay) then Alice will have
> payment-recovery-delay time to notice and post the "too-slow" tx and
> claim the funds via the timeout path.
>
> * If Bob posted a revoked state, Alice can also claim the funds via
> Bob claim, provided she notices within the channel-recovery-delay
>
In my mind your "update the base channel state" idea seems to fix
everything by itself. So at T - to_self_delay (or a bit before) you say to
your counterparty "can we lift this HTLC out of your in-flight tx into the
'balance tx' (which will go back to naming a 'commitment tx' since it
doesn't just have balance outputs anymore) so I can use it too? --
otherwise I'll have to close the channel on chain now to force you to
reveal it to me on time?". If they agree, after the revocation and new
commit tx everything is back to (tx symmetric) Poon-Dryja so no need for
extra CSVs. Am I missing something?
I realise this kills some of the elegance of your original protocol and
adds quite a bit of complexity but I think it retains the important
properties.
> That only allows one low-latency payment to be inflight though, which I'm
> not sure is that interesting... It's also kinda complicated, and doesn't
> cover both the low-latency and offline cases, which is disappointing...
>
>
It seems to me lazily lifting the HTLCs into the commitment tx would allow
as many low-latency payments as you want to be in-flight. You would
probably just lift them all up to the commitment tx if you lift one. I
think in the case of nodes that want to keep channel keys offline, having
to go on-chain at T - to_self_delay is not a disaster since it will likely
only be the payment receiver who has their keys offline i.e. the merchant
or end user. So only the last hop would go on chain if the user fails to
claim payment as per usual (just to_self_delay earlier than usual).
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/f94a9551/attachment.html>;