Integrate Gateway with LSP Spec

[justinmoon]

Here is a spec that a bunch of large LSPs like Breez and Block have agreed to build their APIs around.

Integrating this with our lightning gateway could have 2 benefits:

1. It would reduce the burden of managing liquidity - inbound channels could be created automatically from the LSP to us. But outgoing channels would still need to be manually opened.
2. If we use LDK, gatewayd could just be one binary. This would make deployments marginally simpler.

After talking to @johncantrell97, there are basically 2 directions here:

1. Wait for LND / Core Lightning to integrate LSP spec and integrate with this in the gateway
2. Add an LDK-based node to gatewayd and use his ldk-lsp-client to communicate with the LSP. The only 2 things we would need to use this library for are (1) ask what the fees are and (2) get an SCID from the LSP, which the gateway would include its registration with the federation. We couldn't directly use ldk-node because it doesn't support and likely won't add HTLC interception, but John said we could start with ldk-sample and add whatever we need there. He mentioned that he would try to make an example which combines ldk-sample and ldk-lsp-client.

[moneyball]

@justinmoon Can you describe your HTLC interception use case? LDK supports it but as you note LDK Node does not. We're planning to be very conservative expanding the LDK Node API but if there is a strong need by many users for something it will certainly be considered.

[TheBlueMatt]

Forgive me, I don't recall what fedimint needs exactly anymore - why does it need HTLC interception? My recollection was that it really only needs the ability to use its own payment hashes and provide the preimages when it wants to.

[m1sterc001guy]

Here's how a fedimint user receives ecash via lightning:

1. Fedimint user (e.g fedimint-cli) constructs a lightning invoice which contains a route hint to the Lightning Gateway's lightning node, where the short channel id is a fake scid, which is just a number that corresponds to a federation.
2. An IncomingContract is created on the federation, which essentially uploads the (encrypted) preimage to the invoice to the federation's guardians.
3. The Lightning Gateway's lightning node then listens for incoming HTLCs (using HTLC interception) where the short channel id matches the short channel id for a federation that the gateway is registered to. If it finds one, it will look for a preimage for sale in the federation via the IncomingContract. The Lightning Gateway can then use its own ecash balance to "buy" the preimage from the federation (which transfers ecash to the end Fedimint user), and the gateway can then complete the payment using the decrypted preimage.

So I believe we use HTLC interception so that the gateway doesn't need to actually custody funds on behalf of Fedimint users, and instead does this swap between a preimage and ecash notes.

We've already used LDK Node a little bit in some of our tests, I think if we wanted to implement the LSP spec it would probably be beneficial to actually use LDK. Gateway operators would then just need to run a gateway and not need a separate lightning node (although some users with existing lightning nodes will likely still want to do that).

[TheBlueMatt]

Right, okay, so I don't think you actually need HTLC interception, you only need custom payment hashes/preimages - there's no need to "forward" the payment from the receipt to the federation, in fact doing so (correctly) would require extra work and dealing with Lightning onions.

[m1sterc001guy]

Yes correct, no need to forward the HTLC to the federation. Without HTLC interception though I'm not sure how/when the Lightning Gateway would know when to go buy the preimage. The HTLC scid is how the gateway knows which federation has the preimage. Perhaps you had a different mechanism in mind.

[TheBlueMatt]

I dunno about other lightning nodes (or ldk-node), but LDK in general identifies whether the payment hash has a known preimage or not based on the payment secret. Thus you'll see a different event come out of LDK without the SCID being different.

[TheBlueMatt]

Ah, so I checked with tnull and it appears that ldk-node does not, in fact, support custom payment hashes either, sadly.

[tnull]

Yeah, at least currently that's the case, also as we don't expose a separate step when payments are claimable to the user. We might look into allowing users to get further information/hooks into the underlying events, but how/when is still tbd.

[m1sterc001guy]

That sounds like it will work for our use case as well

[justinmoon]

https://github.com/lightningdevkit/lightning-liquidity is a related project that could help automate liquidity management of LDK node connecting to spec-compliant LSP. Docs are sparse, so we should reach out to devs when we want to explore more deeply.

[tnull]

Yes, note this is the same (but renamed from ldk-lsp-client) repository as mentioned above. LDK Node integration is actively being worked on, and early-stage client-side support for the LSPS2 JIT channel standard will be ready for testing/experimentation very soon.

[elsirion]

I think since we have a concrete proposal for integrating LDK Node + LSP Spec we can close the discussion here and rather work in issues. #4095