-
Notifications
You must be signed in to change notification settings - Fork 103
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
Comments
My feedback trying to run an LSP for testing:
|
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
This is also not how bLIP-52 / LSPS2 works, as the 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. |
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?
Hmm, but you can in theory emulate it by sending a few different values in the |
Ah yes, setting the forwarding fee was only omitted from the initial APIs for simplicity reasons basically.
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?
Yes, you can provide a bunch of different variants and the client is then free to choose which one it prefers.
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. |
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.
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?
Err I meant charging senders for later payments to the client. |
Hmm, no? For one it would require a breaking spec change as we'd need to switch the entire structure of
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:
|
Hmm, I was thinking that you'd simply offer a few non-overlapping promises with different min/max channel capacities (I believe the
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). |
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.
Still not quite getting what you're trying to actually achieve that's not covered by the regular bLIP-52 flow?
Again, could you expand why you'd want this to begin with? (still not getting what you mean with 'see above')
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:
The text was updated successfully, but these errors were encountered: