Repository navigation
bLIP-52/LSPS2 service: Revisit service params #478
Description
Activity
My feedback trying to run an LSP for testing:
- 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,
- LSPS2 opens channels that are insufficient to pay initial invoice with
channel_over_provisioning_ppm: 0#501 - 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.
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
promiseof how much they pay for the channelopening_fee(singluar), while the LSP commits to keeping the channel open for at leastmin_lifetimeblocks.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_feealgorithm does only feature amin_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.
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.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.
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.
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 historicalpromises. 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 knowpayment_size_msatupfront, 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_lifetimeafter 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.
- 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
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_satandmax_channel_balance_satfields 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).
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_satandmax_channel_balance_satfields 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).
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.
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: