Allow visibility into the holding cell via `PendingHTLCsForwardable`

[tnull]

Depending on the source/destination of HTLCs it might not make sense to delay forwarding at all (as there wouldn't be any privacy benefits under certain circumstances in practice). We should allow users to decide whether or not to apply the forwarding delay depending on the HTLCs in the holding cell.

[MaxFangX]

👍 This would allow our LSP to use a shorter forwarding delay (or none at all) if the HTLC originates from a Lexe user or is forwarded to a Lexe user, as there is no privacy benefit in these cases which means we can optimize for payment latency. We'd just add the delay when our LSP forwards payments between non-Lexe nodes.

[TheBlueMatt]

What circumstances are you thinking about here? We currently delay forwarding and receiving each by one event cycle. If an LSP wants to not delay payments I'm not sure them delaying forwards but not payments is really worth it.

[tnull]

What circumstances are you thinking about here?

Well, there are no privacy benefits for intra-LSP payments as the LSP already can be pretty certain to know the sender and receiver of the payment. So they could consider to reduce or disable the forwarding delay for client-to-client payments while maintaining a reasonable default delay for any other forwards (i.e., any LSP-user-to-world or world-to-LSP-user or world-to-world payments).

FWIW, adding some delay might still help HTLC batching and the corresponding efficiency improvements, so we could also consider whether this is really necessary if we lowered the sane defaults and do the delaying for the user (i.e., #3768)

[TheBlueMatt]

Well, there are no privacy benefits for intra-LSP payments as the LSP already can be pretty certain to know the sender and receiver of the payment.

I'm not really convinced its worth over-optimizing for this case. We'd have to expose in the API the next-hop for a forward, then the LSP would have to check whether its a client, then they'd have to tell us to go ahead and forward but not forward other HTLCs, only the one that was mentioned in the event, which would be a bunch of work...

But, more broadly, if an LSP is particularly worried about the latency penalty of the delay for intra-LSP-user payments, then I imagine they'd be doubly worried about the latency penalty of the delay for normal forwarded payments, as those are likely to suffer much higher total latency. I'm not really sure I quite grok why an LSP would make a hugely different tradeoff here given a key goal is consistent UX.

In the Lexe case specifically, though, I do wonder if revealing forwarding information is useful to start spinning up the receiving node earlier, given that has some latency penalty (IIRC)?

[tnull]

In the Lexe case specifically, though, I do wonder if revealing forwarding information is useful to start spinning up the receiving node earlier, given that has some latency penalty (IIRC)?

Note that for this case we might want to do #2855 anyways, especially since we recently 'discovered' we'll need to do it soon anyways for LSPS5 support (cf. #2855 (comment)). I imagine the delay between "intercept HTLC" and getting PendingHTLCsForwardable would be sufficient to spawn up the node (IIUC that's what's Lexe already doing by always including an intercept SCID on the client side).

[TheBlueMatt]

Indeed, I think its finally time to do #2855.