Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-12 📝 Original message: On Mon, Oct 11, 2021 at ...
📅 Original date posted:2021-10-12
📝 Original message:
On Mon, Oct 11, 2021 at 09:23:19PM +1100, Lloyd Fournier wrote:
> On Mon, 11 Oct 2021 at 17:30, Anthony Towns <aj at erisian.com.au> wrote:
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
> This problem may not be as bad as it seems.
Maybe you can break it down a little bit further. Consider *three*
delays:
1) refund delay: how long you have before a payment attempt starts
getting refunded
2) channel recovery delay: how long you have to recover from node
failure to prevent an old state being committed to, potentially losing
your entire channel balance
3) payment recovery delay: how long you have to recover from node
failure to prevent losing funds due to a forwarded payment (eg,
Carol claimed the payment, while Alice claimed the refund, leaving
Bob out of pocket)
(Note that if you allow payments up to the total channel balance, there's
not really any meaningful distinction between (2) and (3), at least in
the worst case)
With layered transactions, (2) and (3) are different -- if Bob's node
fails near the timeout, then both Alice and Carol drop to the blockchain,
and Carol knows the preimage, Bob may have as little as the channel
"delay" parameter to extract the preimage from Carol's layered commitment
tx to be able to post a layered commitment on top of Alice's unilateral
close to avoid being out of pocket.
(Note that that's a worst case -- Carol would normally reveal the preimage
onchain earlier than just before the timeout, giving Bob more time to
recover his node and claim the funds from Alice)
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
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...
Cheers,
aj
📝 Original message:
On Mon, Oct 11, 2021 at 09:23:19PM +1100, Lloyd Fournier wrote:
> On Mon, 11 Oct 2021 at 17:30, Anthony Towns <aj at erisian.com.au> wrote:
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
> This problem may not be as bad as it seems.
Maybe you can break it down a little bit further. Consider *three*
delays:
1) refund delay: how long you have before a payment attempt starts
getting refunded
2) channel recovery delay: how long you have to recover from node
failure to prevent an old state being committed to, potentially losing
your entire channel balance
3) payment recovery delay: how long you have to recover from node
failure to prevent losing funds due to a forwarded payment (eg,
Carol claimed the payment, while Alice claimed the refund, leaving
Bob out of pocket)
(Note that if you allow payments up to the total channel balance, there's
not really any meaningful distinction between (2) and (3), at least in
the worst case)
With layered transactions, (2) and (3) are different -- if Bob's node
fails near the timeout, then both Alice and Carol drop to the blockchain,
and Carol knows the preimage, Bob may have as little as the channel
"delay" parameter to extract the preimage from Carol's layered commitment
tx to be able to post a layered commitment on top of Alice's unilateral
close to avoid being out of pocket.
(Note that that's a worst case -- Carol would normally reveal the preimage
onchain earlier than just before the timeout, giving Bob more time to
recover his node and claim the funds from Alice)
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
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...
Cheers,
aj