bLIP-57: Channel Lease Extensions (LSPS7) #57
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 😅
No description provided.