LSP-provided Routeboost

[ZmnSCPxj-jr]

CLN has a haha-only-serious concept called "routeboost". Basically, for every invoice CLN issues, CLN will check which of its channels can fit the invoice amount and adds it as the routehint for the invoice. The idea is that the routehint gives a hint to the payer for at least one channel that the CLN receiver knows is going to be able to receive the invoice.

(In actual implementation, CLN round-robins its channels, and puts the channel which has sufficient inbound capacity to receive an invoice as the routehint in the invoice)

A client will usually have just one LSP, and even if it has multiple LSPs, can already know which one has a channel that can best receive a payment. The question now is, how can the payer best reach the LSP itself? Thus, it might be good to have the LSP also provide a way for the client to ask, "hey, I am expecting an inbound payment of size N millisatoshis, what is the best way for the payer to reach your node?" The LSP can then check for channels that still have inbound capacity, to assist the payer in delivering the payment to the LSP so that the LSP can then deliver to the client.

Open questions:

• How do we prevent the client from turning this into a free probe of how much capacity the LSP has? Note: if the LSP does not rate-limit this query then even randomizing channels may not be enough as the client may just apply statistics on multiple calls to such a query.

[ZmnSCPxj-jr]

In addition to allowing the client to ask "how can I best receive via your node?" we can also add an API to the same LSPS that allows the client to ask "how can I best send via your node?" so that the LSP can continuously probe its peers for how reliable they are at getting payments out to the world, then feed that data to clients that are willing to trust the say-so of the LSP. This is somewhat incentive-compatible as the LSP gets paid on successful routing of payment to/from the client, so it should honestly report the best way for the client to send/receive payments.