bLIP-57: Channel Lease Extensions (LSPS7)#57
bLIP-57: Channel Lease Extensions (LSPS7)#57kaloudis wants to merge 1 commit intolightning:masterfrom
Conversation
| ```json | ||
| { | ||
| "short_channel_id": "871428x964x0", | ||
| "channel_extension_expiry_blocks": 144, |
There was a problem hiding this comment.
Does it make sense to use new_channel_expiry_blocks here instead of channel_extension_expiry_blocks ?
There was a problem hiding this comment.
Good question. Either could work. Open to hear arguments in favor of one over the other.
There was a problem hiding this comment.
Just re-read LSPs1 and now I am convinced it is better to keep channel_extension_expiry_blocks for the sake of uniformity.
|
We have our service deployed to Mutinynet and testnet3, if anyone would like to poke at it: |
|
|
||
| ## Motivation | ||
|
|
||
| The goal of this specification is to provide a standardized LSP API for wallets to extend the lifetime of a channel purchased from an LSP. |
There was a problem hiding this comment.
Isn't it unfair to pay for the extension of a channel in which the balance has been on the non-LSP side during all of the previous period? No capital cost for the LSP. Or would this be taken into account when pricing the next extension?
I do realize of course that this is more of a remark on the side.
There was a problem hiding this comment.
It's up to the LSP how they want to price it. Pricing basing on the current ratio of balances is a bit tricky as it can change drastically in an instant
There was a problem hiding this comment.
Current ratio can of course change drastically, but I was thinking of the average balance of the previous period. So even if the final balance is skewed heavily towards the LSP, it may not mean that the average balance, that is the basis for the calculation of the price of the extension, is too.
A continuous model for this would be to have a constant flow of sats towards the LSP proportional to the LSP balance.
Ofc still side remarks all of this 😅
|
Just wanted to add our two cents here. I definitely understand that some LSPs may want to close channels after a certain period, in order to maintain capital efficiency. For those LSPs it could be useful to have a "renewal" specification like this. But: It just seems more natural, from the perspective of a user, that an LSP never closes channels, as long as the user is actively using the channel, and bringing their node online at least occasionally (say, every 30 days or so.) It might not be the most straightforward "return on capital" available for the LSP, but I just think that the latter practice might be better for the user, as well as the network as a whole. |
4 participants
No description provided.