[Lightning-dev] Lightning over taproot with PTLCs

[Anthony Towns]

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