📅 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