LSPS2 Service doesn't enforce fees on later forwards

[TheBlueMatt]

After fixing #499, LSPS2 doesn't enforce fees on forwards after the first. In practice this means LDK needs full interception (maybe just for channels marked for it?), I think, so its time to add that, but in theory we could leave #499 un-fixed and then force clients to only relay through the interception SCID, but then it seems like we always open a new channel even if there's enough liquidity available? (presumably we should never open a new channel with a client if there's a channel with enough liquidity?)

[tnull]

Hmm, well, I think we could just allow to specify the 'regular' forwarding fees separately, no? In this initial alpha version of the service we just set them to 0 to make the calculations a bit easier, and to not charge them on top of the channel opening fees for the initial payment.

[tnull]

but then it seems like we always open a new channel even if there's enough liquidity available? (presumably we should never open a new channel with a client if there's a channel with enough liquidity?)

Yeah, there is two answers to this, really:

a) in the LDK Node service-side we need do proper tracking of the to-be-opened channels (retry them after reconnection, etc, see #473), but possibly also not to reopen another channel if the same intercept SCID is reused (though that is exactly the kind of things I'd love feedback from LSPs on: do they want a 1:1 mapping here or not?)

b) Eventually, all LSP operations should default to splicing-in rather than opening redudant channels, and then we could discuss whether to provide a specific API to still allow to request new additional channels, IMO.

[TheBlueMatt]

Hmm, well, I think we could just allow to specify the 'regular' forwarding fees separately, no?

Those are different - they are charged to the sender, not the recipient, so you can only set them so high before payments fail. If an LSP configures to charge N per channel, we really need to make sure they actually charge N.

In this initial alpha version of the service we just set them to 0 to make the calculations a bit easier, and to not charge them on top of the channel opening fees for the initial payment.

Yea, would def prefer to also be able to configure channel fees on top of the channel-open fees, since, again, they're a different kind of fee and the LSP might want to configure those.

a) in the LDK Node service-side we need do proper tracking of the to-be-opened channels (retry them after reconnection, etc, see #473), but possibly also not to reopen another channel if the same intercept SCID is reused (though that is exactly the kind of things I'd love feedback from LSPs on: do they want a 1:1 mapping here or not?)

For LSPS2 and an LSP intending to service non-custodial end-user wallets, yes. I don't see an argument why you'd want an end-user wallet opening a new channel Just Because. In theory the end-user wallet could have a lot of intelligence about future funds receipts, but I'm skeptical any ever would, so, yes, a JIT SCID alias should simply be a reference to a counterparty.

b) Eventually, all LSP operations should default to splicing-in rather than opening redudant channels, and then we could discuss whether to provide a specific API to still allow to request new additional channels, IMO.

Probably not, for the above :)

[tnull]

Those are different - they are charged to the sender, not the recipient, so you can only set them so high before payments fail. If an LSP configures to charge N per channel, we really need to make sure they actually charge N.

I'm honestly a bit confused what exactly you mean here: on the client side we do enforce that the LSP only deducts what was agreed upon. If you mean that on the service side, we need to make sure not to forward 'around' the intercept SCID by the user using the regular SCID alias, this is fundamentally only solved by client-trusts-LSP mode, i.e., withholding the funding tx until we're positive sufficient HTLCs to pay for the channel open have been intercepted and successfully forwarded. Note that (while generally nice) we don't need general-purpose HTLC interception for that (the service-side PaymentQueue logic does most of it, in LDK Node we just need to implement the actual witholding part, etc (#479). FWIW, there is no use 'plugging the holes' another way if in the end the client can just get away with never claiming the intercepted payment.

so, yes, a JIT SCID alias should simply be a reference to a counterparty

What do you mean by 'a reference to a counterparty'?

Probably not, for the above :)

Huh, may make sense to discuss this offline, but IMO, defaulting to splicing for subsequent 'liquidity events' instead of opening parallel channels makes a lot of sense for most scenarios.