Skip to content

bLIP-52/LSPS2 service: Revisit service params #478

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tnull opened this issue Mar 3, 2025 · 9 comments
Open

bLIP-52/LSPS2 service: Revisit service params #478

tnull opened this issue Mar 3, 2025 · 9 comments

Comments

@tnull
Copy link
Collaborator

tnull commented Mar 3, 2025

In #420 we added initial support for acting as an bLIP-52/LSPS2 service.

While we introduced a first batch of config knobs, we should (after feedback from LSPs) consider providing further config options, including:

  • min/max channel size
  • max fee (?)
@TheBlueMatt
Copy link

My feedback trying to run an LSP for testing:

@tnull
Copy link
Collaborator Author

tnull commented Mar 23, 2025

I'd like to be able to configure normal channel fees (which have to go in the JIT invoice so have to be communicated over the LSPS protocol to the client) as those are paid by the sender and I can charge the sender some fees not just the recipient,

This is not how bLIP-52 / LSPS2 works. The client and service agree on the terms of service and the client receives a cryptographically secure promise of how much they pay for the channel opening_fee (singluar), while the LSP commits to keeping the channel open for at least min_lifetime blocks.

I'd like to be able to set a fixed-fee in addition to the ppm one - the LSP's costs are fixed, so if they want a simple "passthrough" model they need a fixed-fee not just PPM.

This is also not how bLIP-52 / LSPS2 works, as the compute_opening_fee algorithm does only feature a min_fee_msat, not a flat fee on top of the proportional fee. Note that it is decidedly fixed in the spec so both parties can easily deterministically recompute the correct fees.

Both of these points might be interesting to discuss for future LiqAds-based specs, but likely won't be accommodated by bLIP-52 / LSPS2 based services/clients.

@TheBlueMatt
Copy link

This is not how bLIP-52 / LSPS2 works. The client and service agree on the terms of service and the client receives a cryptographically secure promise of how much they pay for the channel opening_fee (singluar), while the LSP commits to keeping the channel open for at least min_lifetime blocks.

Hmm, should probably have the ability to set the fee, no? The recipient doesn't care what fee the sender pays, and presumably there's nothing in the bLIP about setting a fee after the channel's open, so might as well allow it up front no?

This is also not how bLIP-52 / LSPS2 works, as the compute_opening_fee algorithm does only feature a min_fee_msat, not a flat fee on top of the proportional fee. Note that it is decidedly fixed in the spec so both parties can easily deterministically recompute the correct fees.

Hmm, but you can in theory emulate it by sending a few different values in the opening_fee_params_menu, no? Higher proportional fees for lower amounts. Seems like a really huge oversight in the spec, tbh. I was thinking I'd just stand up a public LSP (now that regulatory winds are shifting in the US) for people to use for testing but without this I don't think I can.

@tnull
Copy link
Collaborator Author

tnull commented Mar 24, 2025

Hmm, should probably have the ability to set the fee, no? The recipient doesn't care what fee the sender pays, and presumably there's nothing in the bLIP about setting a fee after the channel's open, so might as well allow it up front no?

Ah yes, setting the forwarding fee was only omitted from the initial APIs for simplicity reasons basically.

so might as well allow it up front no?

Not sure? Charging the receiver is fundamentally different from charging the sender, no? FWIW, for the former you're basically reneging on the channel lease contract?

Hmm, but you can in theory emulate it by sending a few different values in the opening_fee_params_menu, no? Higher proportional fees for lower amounts.

Yes, you can provide a bunch of different variants and the client is then free to choose which one it prefers.

Seems like a really huge oversight in the spec

Could you expand which part exactly? Charging the client for follow-up payments?

Btw, there is ongoing work on channel lease extensions over at lightning/blips#57, which however currently is mainly focused on/modeled around LSPS1 / bLIP-51.

@TheBlueMatt
Copy link

Not sure? Charging the receiver is fundamentally different from charging the sender, no? FWIW, for the former you're basically reneging on the channel lease contract?

Right, this is just charging the sender not the recipient. In most cases senders cover the fees (at a flat cost to the sender, in many cases), so an LSP probably wants to recover some cost here too.

Yes, you can provide a bunch of different variants and the client is then free to choose which one it prefers.

I assume the client already implements selecting the one that allows for the amount it wants? So we could create a fixed fee configuration parameter (as long as we have some reasonable minimum channel value) and it would mostly just work?

Could you expand which part exactly? Charging the client for follow-up payments?

Err I meant charging senders for later payments to the client.

@tnull
Copy link
Collaborator Author

tnull commented Mar 25, 2025

I assume the client already implements selecting the one that allows for the amount it wants? So we could create a fixed fee configuration parameter (as long as we have some reasonable minimum channel value) and it would mostly just work?

Hmm, no? For one it would require a breaking spec change as we'd need to switch the entire structure of opening_fee_params, thereby invalidating historical promises. But generally I'm not sure why you consider a fixed fee such a central feature. In fact, all of the LSPs I spoke to so far were clear they wanted at least a proportional fee model (short of more complex models). Note that in the variable-amount case, you (the LSP) won't know payment_size_msat upfront, so if you offer a fixed fee you might allow the sender to open a humongous channel for a very small fixed fee.

Err I meant charging senders for later payments to the client.

Okay, now you completely lost me on what it's exactly that you want and think is missing from the spec.

Probably it would be easier to discuss this offline, but just to reiterate the status quo, bLIP-52/LSPS2 supports:

  • charging a on-time fee proportional to the payment size (whether known upfront or variable-amount) that is negotiated and committed-to by the LSP, and deterministically verifiable by the client before it claims the payment. This fee has a lower limit described by min_fee_msat
  • the LSP commits to keep the channel open for at least min_lifetime after that all bets are off, and/or the continuation can be renegotiated by other protocols
  • the LSP may of course also charge the sender forwarding fees, as they are transparent to the recipient.

@TheBlueMatt
Copy link

Hmm, no? For one it would require a breaking spec change as we'd need to switch the entire structure of opening_fee_params, thereby invalidating historical promises. But generally I'm not sure why you consider a fixed fee such a central feature. In fact, all of the LSPs I spoke to so far were clear they wanted at least a proportional fee model (short of more complex models). Note that in the variable-amount case, you (the LSP) won't know payment_size_msat upfront, so if you offer a fixed fee you might allow the sender to open a humongous channel for a very small fixed fee.

Hmm, I was thinking that you'd simply offer a few non-overlapping promises with different min/max channel capacities (I believe the min_channel_balance_sat and max_channel_balance_sat fields would allow for this?). A client which wants to issue an amount-less invoice might struggle, but a graduated wallet that generally issues amount-full invoices should be able to select based on what allows for the amount they want.

Okay, now you completely lost me on what it's exactly that you want and think is missing from the spec.

Right, the only thing that I think is missing is (a) fixed opening fees, see above and (b) the ability to require forwarding fees on the channel to the recipient (which are paid by the sender who sends the LSP client the first payment). Of course using the standard lightning protocol the LSP can require forwarding fees on the channel to the LSP client after the channel is open, but it'd be nice to be able to specify it also on the first payment (which then must be included in the route hint in the invoice).

@tnull
Copy link
Collaborator Author

tnull commented Mar 26, 2025

Hmm, I was thinking that you'd simply offer a few non-overlapping promises with different min/max channel capacities (I believe the min_channel_balance_sat and max_channel_balance_sat fields would allow for this?).

No, these fields determine how much the LSP guarantees to be forwardable to the client. The actual channel size can be freely chosen by the LSP as long as it can accommodate these values, hence the overprovisioning factor.

A client which wants to issue an amount-less invoice might struggle, but a graduated wallet that generally issues amount-full invoices should be able to select based on what allows for the amount they want.

Still not quite getting what you're trying to actually achieve that's not covered by the regular bLIP-52 flow?

(a) fixed opening fees

Again, could you expand why you'd want this to begin with? (still not getting what you mean with 'see above')

(b) the ability to require forwarding fees on the channel to the recipient (which are paid by the sender who sends the LSP client the first payment).

Right, as mentioned above, the absence of 'regular forwarding fees' is merely a limitation of this initial alpha-stage implementation. Essentially, a short-cut we took as we expected that LSPs will tell us that our current API is crap anyways and that they'd require something much more flexible (we'll see if that turns out to be true).

@TheBlueMatt
Copy link

We discussed this offline and, indeed, it does seem to be the case that you can provide a set of promises for non-overlapping amount ranges and create an implicit base fee as a side effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants