mobile-client-pays-hold-invoice.md

Re: https://twitter.com/super_testnet/status/1725239338533810410

WARNING: this is a five-minute write up in response to a post I saw on X. I haven't thought about this carefully.

Problem: a mobile wallet spender pays a hold invoice that doesn't settle immediately. The spender goes offline. The payment eventually times out far downstream, with each forwarding node settling it offchain until it reaches the initial downstream node. So far, so good, but then the mobile spender is offline when its downstream peer tries to settle with it, so the downstream peer needs to force close the channel to settle the HTLC onchain before HTLC expiry where mobile spender is able to claim a refund of the spend.

Proposed solution: the mobile spender can make their refund condition timelocked relative to confirmation of the commitment transaction, allowing the HTLC to stay open between them and their downstream peer indefinitely. This doesn't cost the downstream peer anything (except storing a database entry). It also still allows the mobile spender to trustlessly receive a full refund if the payment doesn't settle. For a mobile client that's online all the time, they can receive a refund in the same amount of time as currently used. For a mobile client that's offline for t amount of time, their refund is only delayed by t.

Downsides:

1. A relative timelock (OP_CSV) on the refund condition is only safe for a spender to use. Regular forwarding nodes must use absolute timelocks (OP_CLTV) with a delta so that forwarding funds from one channel to another channel is atomic. That means the mobile wallet identifies itself to its downstream peer as the ultimate spender of the payment. For mobile clients using an LSP, it may already be clear that they're the ultimate spender, so no additional privacy is lost.

2. It's a modification to the standard LN protocol. Change is hard.

Here's an example comparison of prototypical HTLCs. The only difference are the lines using OP_CTLV vs OP_CSV.

Standard HTLC
~~~~~~~~~~~~~

OP_IF
  OP_RIPEMD160 <hash> OP_EQUALVERIFY
  <downstream pubkey> OP_CHECKSIG
OP_ELSE
  <spender pubkey> OP_CHECKSIGVERIFY
  <expiry (absolute height)> OP_CLTV
OP_ENDIF

Mobile Spender HTLC
~~~~~~~~~~~~~~~~~~~

OP_IF
  OP_RIPEMD160 <hash> OP_EQUALVERIFY
  <downstream pubkey> OP_CHECKSIG
OP_ELSE
  <spender pubkey> OP_CHECKSIGVERIFY
  <expiry (relative number of blocks after commitment tx confirms)> OP_CSV
OP_ENDIF

This is interesting. It would allow the HTLC refund to happen whenever. Would that also work similarly if the downstream recipient redeemed the payment? Eventually the LSP needs to redeem the HTLC from the offline spender. Is it basically up to the LSP whenever they want to go on chain with it?

That means the mobile wallet identifies itself to its downstream peer as the ultimate spender of the payment.

Not just the downstream recipient, but also to any routers in the middle and other on chain observers too, right?

For mobile clients using an LSP, it may already be clear that they're the ultimate spender, so no additional privacy is lost.

Today, it would be clear the mobile user is the spender from the LSP's point of view, but with a few hops in the middle, the receiver wouldn't even know the LSP it might have came from. When the spender and the routers have the same HTLC script that means there is plausible deniability that the LSP was just routing the payment and was not the source nor connected to the source. This scenario could be an unannounced channel with another routing node where they share a public channel also. Common to do for privacy of total node capacity.

When the source HTLC and routing HTLC is different, I think there's some additional information that is gained from the recipient's POV and from the general network. With on chain heuristics, you'd probably easily determine the LSP, and from there you'd be able to tell that the source of payment came from someone the LSP is directly connected to due to the OP_CSV HTLC style.