LND: Generate non-standard forwards... to implement Lightning Service Provide Specification #2 (LSPS2)

[MegalithicBTC]

The Challenge: "non-standard" forwards

We're working on implementing an "LSP-side" implementation of LSPS2.

LSPS2 goes a long way to solving the "chicken or egg" problem where a wallet user needs a lightning channel, but doesn't already have onchain funds or funds in an existing Lightning channel to pay for a channel.

LDK's client-side solution for LSPS2 is exceptionally elegant. It requires just two functions... node.set_liquidity_source_lsps2 and node.bolt11_payment().receive_via_jit_channel. This proof of concept works perfectly in our initial tests, and should be a really easy way for mobile wallet developers to incorporate an LSP.

The challenge... building the "LSP-side" implementation of LSPS2 that will work with LND. This is critical, as most of the biggest liquidity sources on the Lightning Network are running LND. (Like our nodes, for example.)

"LSP-side" LSPS2 is rather complicated, but we have the implementation nearly finished, and up to this point have been able to do everything using just Alex Bosworth's lightning library, and our own custom code with NodeJS, Postgres, and Redis.

We're REALLY close to finishing this, but we have a blocker right at this point in the specification:

The LSP generates non-standard forwards, where the amount received
by the client is smaller than specified in the onion;

Currently, we are intercepting the forwards with subscribeToForwardRequests.

We can intercept and log the forwards without problems.... but... Currently this subscribeToForwardRequests function only allows for .accept() or .reject() or .settle().

So our challenge is to figure out how to "generate non-standard forwards" and send these to the client node.

Here is where we are with our research.

Can we use existing LND APIs?

Could the SendToRouteV2 API work? Would it be as simple as modifying the payment hash, and then sending it?

let requestBody = {
  payment_hash: <string>, // <bytes> (base64 encoded)
  route: <object>, // <Route> 
  skip_temp_err: <boolean>, // <bool> 
};

Do we need to drop down into Go to use internal LND functions?

Here is an example from Breez's LSPD library, where they use a function to construct an onion and then send it.

Is this something similar to what we need to do?

LDK has already implemented this

LDK already has an "LSP-side" implementation for LSPS2.

In LDK's channelmanager.rs, the pub fn forward_intercepted_htlc seems to do exactly what we need, specifically this code, which I think satisfies this The LSP generates non-standard forwards, where the amount received by the client is smaller than specified in the onion; line in the specification:

let skimmed_fee_msat =
			payment.forward_info.outgoing_amt_msat.saturating_sub(amt_to_forward_msat);
		let pending_htlc_info = PendingHTLCInfo {
			skimmed_fee_msat: if skimmed_fee_msat == 0 { None } else { Some(skimmed_fee_msat) },
			outgoing_amt_msat: amt_to_forward_msat, routing, ..payment.forward_info
		};

		let mut per_source_pending_forward = [(
			payment.prev_short_channel_id,
			payment.prev_funding_outpoint,
			payment.prev_channel_id,
			payment.prev_user_channel_id,
			vec![(pending_htlc_info, payment.prev_htlc_id)]
		)];
		self.forward_htlcs(&mut per_source_pending_forward);
		Ok(())

Similar code is here, in the lightning-liquidity crate.

So: Does anyone have any suggestions for a strategy we should look at for LND?

thanks!

[JssDWt]

In lspd I made a PR for LSPS2 on top of LND here: breez/lspd#149

It does lean on a fork of LND with the following rpc modifications:

• allowing to send a custom amount and short channel id in the HtlcInterceptor (most important)
• GetPeerByScid method that gets a peer by scid (not strictly necessary)
• GetPeerConnected that returns whether a peer is currently online (only necessary for notifications/LSPS5)
• modifications to allow zero reserve on the remote side (not strictly necessary)

You can't use SendToRouteV2, because you don't have the payment secret. Only the sender and the recipient know this. So you'll have to forward the original onion sent by the sender in order to get the payment to settle.

The part of lspd that does the onion rewriting is for breezmobile. For LSPS2 there is no need to rewrite the onion blob, only the lower amount and new short channel id have to be passed to LND. I believe the diff for that is fairly small: breez@5f0a699
The question is whether LND will accept it as a PR.

[SeverinAlexB]

I texted @alexbosworth if he is open to such a PR.

[SeverinAlexB]

Here we go

[MegalithicBTC]

Thanks much. Obviously would rather not fork LND but unless we find a cleaner solution, we'll use this.

[MegalithicBTC]

@JssDWt Thanks for the diff ( breez@5f0a699 ) you provided, which will be very useful.

I wanted to see if you agreed with this idea: In addition to your proposed modifications, the forked LND must incorporate additional changes, which will be necessary in order to protect against payment probes, as well as possible malicious attacks against the LSP, where clients attempt to open many channels and never settle the paying invoices.

HERE IS MY REASONING:

I'm hoping you could look at it and tell me if I've got something wrong.....

At the top of the page, here: https://github.com/BitcoinAndLightningLayerSpecs/lsp/tree/main/LSPS2#lsps2-jit-channel-negotiation

Using the "LSP trusts client" model, a naive probe that goes all the way to the payee would cause the LSP to open a channel to the client. If the payee never receives a payment over that channel, the LSP would not receive payment for the channel open. Note that it is possible for this to not be the case in the "Client trusts LSP" model, where the LSP can hold the funding tx until receiving a correct preimage.

So, to be safe, a "Client trusts LSP" model is necessary.

Given that, near the bottom of LSPS2, we find this:

https://github.com/BitcoinAndLightningLayerSpecs/lsp/blob/c39931860576a1478be9bdb7bf421325d5689bf6/LSPS2/README.md?plain=1#L890

• If client_trusts_lsp is specified and true:
  • The LSP MAY wait for the client to send the preimage to the
    incoming payment via a update_fulfill_htlc before broadcasting
    the funding transaction.
  • The client MUST NOT wait for the LSP to broadcast the funding
    transaction before sending the preimage via a
    update_fulfill_htlc.
  • The client and LSP MUST immediately send channel_ready.

So: Both peers must send channel_ready BEFORE the "LSP-side" broadcasts the funding transaction, right?

I don't see anything in the LND API that would allow us to open a channel, but then "sit" on that channel, and not broadcast the funding transaction to the mempool until a later time....

So: A further addition to the proposed fork to LND would be required (am I right about this?):

NEW CODE THAT MUST BE RUNNING IN THE FORKED LND:

This PublishTransaction ...

lnd/funding/manager.go

Line 2676 in d7e0f69

err = f.cfg.PublishTransaction(fundingTx, label)

.... must conditionally NOT run, .... if the channel is LSPS2 related... then in this case... . instead of immediately running PublishTransaction, we take the the data will be necessary to run PublishTransaction in the FUTURE... and persist it to our own database.... and then run a sendChannelReady

lnd/funding/manager.go

Line 3163 in d7e0f69

func (f *Manager) sendChannelReady(completeChan *channeldb.OpenChannel,

PROPOSED SEQUENCE OF EVENTS FOR CHANNEL OPENING:

1. LSP intercepts payment(s) which must eventually get to the Client, and holds those payment(s) until their aggregate payment amount is sufficient.
2. LSP opens a channel.
3. LSP polls the database, to look for the data necessary to run a PublishTransaction (this could take some time, as the entire back-and-forth between the LSP and the client, to get all the way to the PublishTransaction state, can take a few seconds).
4. When LSP sees that data sufficient to run a PublishTransaction call exists, then it...
5. Deducts its fee, then forwards the rest of the payment through the channel, using the extra arguments in the Resume function provided in the fork ... func (f *interceptedForward) Resume(outgoingAmount lnwire.MilliSatoshi, outgoingChanID lnwire.ShortChannelID, onionBlob [lnwire.OnionPacketSize]byte)
6. AFTER the forward has been successful, and the HTLC is no longer pending...
7. Then the LSP runs the PublishTransaction function, using persisted data from the database

In this way, the LSP would be protected from spurious payments (which the client will refuse to settle), and also would be protected from from payment probes (which will never settle).

[guggero]

I haven't read the full thread here, just wanted to point out this PR which might be useful for this situation (or parts of it): #8633
This allows you to modify an HTLC when forwarding (using the HtlcInterceptor API that subscribeToForwardEvents also uses under the hood). You can change the amount that's going to be put in the actual HTLC output and in the p2p/wire message using the outgoing_amount_msat (and the action: RESUME_MODIFIED). Obviously you can't modify the amount that's specified in the onion message, as that's encrypted. But as long as the ultimate recipient can deal with the discrepancy between the HTLC output amount and the onion amount, that should be fine.

The above PR is currently merged to the 0-19-staging branch which is expected to be merged into master in one of the upcoming v0.18.x minor releases.
If you want to use the new fields with the lightning JavaScript library, that probably also requires a PR in that project.

[JssDWt]

This is great. It seems to solve the reduced amount.

One more thing that would be needed is to pick the outgoing channel / peer.