LSP-managed Inbound Liquidity (client just gets an LSP-specified SCID and uses it for all invoices, LSP figures out how to get payments to the client)

[ZmnSCPxj-jr]

#22 (comment)

FUTURE Idea that will not be added to this pull request, but should be written down somewhere anyway: the jit_channel_scid is a permanent ID for a particular client. The client uses the same jit_channel_scid for all its invoice routehints. When a payment arrives at the LSP, it can check if the client has enough inbound liquidity to forward it; if there is, it simply redirects the payment to any channels with sufficient liquidity. If not, the LSP does liquidity management actions, such as opening a 0-conf channel, or a 0-conf splice, or a 0-conf swap, possibly with help from LSPS4 and other things to make 0-conf safe(r).

Open questions:

• MPP. Probably we should spec out the onion-oracle idea first before doing this.
• How to negotiate the onchain feerates. Liquidity management actions are all onchain actions (at least until we get channel factories, but channel factories require everyone to be online and "online" is not a good expectation from mobile clients), and those actions have to be paid for by the client. We need some way to continuously negotiate the feerates for the onchain fees. In the current LSPS3 spec the onchain fee negotiation is really part of the opening_fee calculation, which is why there is a opening_fee_params.valid_until.

[ZmnSCPxj-jr]

Consider allowing a single client to acquire multiple SCIDs; for example the client could use multiple SCIDs for privacy, and associate a different client-known pubkey with each SCID (the LSP informs the SCID it received as next hop in addition to the onion, so that the client can use an SCID-to-keypair mapping, then decode the onion using the keypair).

Against this, note that SCIDs are more limited --- they are less than 64 bits (some SCIDs refer to actual outpoints on the blockchain) and if a single client were allowed to acquire multiple SCIDs then the available space is that much smaller. LDK in particular uses random pick for interception SCIDs, and random nonces (which is what the SCID would really be, as no two clients are allowed to use the same SCID) are often suggested to be at least 80 bits in size, 64 bits is pushing it for nonces, and because some SCIDs point to actual blockchain positions, we have less than 64 bits actually. We would need to build a persisted table of SCIDs issued, and make sure lookup there is fast when we pick a random new SCID.

[TonyGiorgio]

I understand the deferment and now the technical challenges around bits.

Will LSPS2 be compatible with all the route blinding efforts? My initial reading of it seems like it would be but wanted to double check. Because the privacy considerations of SCID and pubkey rotation should be able to go away with that, correct? I could probably hold off until then, I have a privacy conscious LSP solution currently but do want to move towards this spec. Just need route blinding.

[ZmnSCPxj-jr]

LSPS2 would be compatible with route blinding: it only requires that the LSP somehow receive an onion that points to the jit_channel_scid it specified, which can be done with route blinding.

[ZmnSCPxj-jr]

The continuous JIT Channels spec allows LSP to issue one "permanent" SCID and multiple "ephemeral" SCIDs.

[ZmnSCPxj-jr]

@TonyGiorgio the LSPS group hum is that BOLT11 will be replaced by BOLT12 "soon" anyway, so the ephemeral SCIDs support has been removed from the LSPS4 #37. LSPS4 now only issues a single SCID for each client.

[TonyGiorgio]

@TonyGiorgio the LSPS group hum is that BOLT11 will be replaced by BOLT12 "soon" anyway, so the ephemeral SCIDs support has been removed from the LSPS4 #37. LSPS4 now only issues a single SCID for each client.

That's unfortunate. I'll continue with my own LSP solution then until route blinding happens. I've only been holding my breath for a few years, I'll believe it when I see it.