bLIP-57: Channel Lease Extensions (LSPS7) by kaloudis · Pull Request #57 · lightning/blips

kaloudis · 2025-01-10T15:48:52Z

No description provided.

dzdidi · 2025-01-12T08:15:53Z

+```json
+{
+  "short_channel_id": "871428x964x0",
+  "channel_extension_expiry_blocks": 144,


Does it make sense to use new_channel_expiry_blocks here instead of channel_extension_expiry_blocks ?

Good question. Either could work. Open to hear arguments in favor of one over the other.

Just re-read LSPs1 and now I am convinced it is better to keep channel_extension_expiry_blocks for the sake of uniformity.

kaloudis · 2025-02-05T02:17:51Z

We have our service deployed to Mutinynet and testnet3, if anyone would like to poke at it:

Mutinynet: https://mutinynet.com/lightning/node/032ae843e4d7d177f151d021ac8044b0636ec72b1ce3ffcde5c04748db2517ab03

testnet3: https://mempool.space/testnet/lightning/node/03e84a109cd70e57864274932fc87c5e6434c59ebb8e6e7d28532219ba38f7f6df

joostjager · 2025-02-11T11:17:06Z

+
+## 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.


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.

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

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 😅

Interesting idea for sure

MegalithicBTC · 2025-03-10T23:04:37Z

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.

tnull

Excuse the delay here!

Generally makes sense to me to have such a spec, but if we introduce it it might make sense to ensure that it also works for bLIP-52/LSPS2, not only in the bLIP-51/LSPS1 context. Maybe that would require also introducing order ids to LSPS2?

tnull · 2026-03-20T12:56:30Z

+  "token": "",
+  "created_at": "2012-04-23T18:25:43.511Z",
+  "order_state": "CREATED",
+  "payment": {


This should also support BOLT12 by now, parallel to bLIP-51 (cf. #59).

Done. payment mirrors LSPS1.payment, so bolt12 was already implied after #59. The example now includes it and section 4 names it explicitly.

tnull · 2026-03-20T12:59:20Z

+}
+```
+
+- `short_channel_id` <[LSPS0.scid][]> Short Channel Identifier (SCID) of the channel to extend.


I think we need to clarify if this can be any SCID of a previously-purchased channel (maybe even ones towards other peers?), or if it needs to be the actual SCID, or the SCID alias, or, in case of bLIP-52 to jit_channel_scid?

Clarified. The client MUST send an SCID returned by the latest lsps7.get_extendable_channels, and that call MUST only return channels between the client and the LSP. The SCID is the one of the current funding transaction (the splice transaction after a splice), MAY be an alias before confirmation, and MUST NOT be an intercept SCID such as jit_channel_scid. An unknown SCID returns -32602 with property: short_channel_id.

tnull · 2026-03-20T13:58:25Z

+
+| Code   | Message         | Data | Description |
+| ----   | -------         | ----------- | ---- |
+| -32602 | Invalid params  | {"property": %invalid_property%, "message": %human_message% }            | Invalid method parameter(s). |


Can we leave the invalid property out? Including that might introduce quite a bit of complexity for (IMO) little gain, as it's only human readable. Yes it makes debugging a bit easier, but hopefully that isn't required often?

I kept it to match bLIP-51, which has the same row, so clients can share error handling between LSPS1 and LSPS7. If you'd prefer, I can make property a SHOULD here.

tnull · 2026-03-20T13:58:59Z

+  - `%invalid_property%` MUST be one of the fields in the request body. MUST use `.` to separate nested fields.
+  - Example: `{ "property": "channel_extension_expiry_blocks", "message": "Not an integer" }`.
+
+- LSP MUST validate the `token` field and return an error if the token is invalid.


Probably should mention this is only necessary if the token is actually set.

Done: "If the client provided a token, LSP MUST validate it".

tnull · 2026-03-20T14:00:00Z

+| ----   | -------         | ----------- | ---- |
+| -32602 | Invalid params  | {"property": %invalid_property%, "message": %human_message% }            | Invalid method parameter(s). |
+| 001    | Client rejected | {"message": %human_message% }                                            | [LSPS0.client_rejected_error][] |
+| 100    | Option mismatch | {"property": %option_mismatch_property%, "message": %human_message% }    | The order doesnt match the options defined in `lsps7.get_extendable_channels` channel object. |


Seems this is missing the 'unrecognized_or_stale_token' error type we have in LSPS1 and 2.

Added 102 | Unrecognized or stale token, and the token rule now points to it.

tnull · 2026-03-20T14:01:39Z

+The `extendable_channel` object returned in `lsps7.get_extendable_channels`, `lsps7.create_order`, and `lsps7.get_order`, has the following properties:
+
+- `original_order <object>` An *optional* property for the original order for the channel lease, including the `id <string>` to identify the order and the `service <string>` the purchase occured on.
+- `extension_order_ids <string[]>` An *optional* list of order IDs for each time the channel lease has been extended.


I assume this needs to be a subset of original_order_ids?

They don't overlap. original_order is the single order the channel was purchased through (e.g. an LSPS1 order), and extension_order_ids are the ids of earlier completed lsps7.create_order orders for the channel. I reworded the field and added that it MUST NOT contain the original_order id and is ordered oldest first.

tnull · 2026-03-20T14:02:39Z

+- `expiration_block <uint32>` The block height at which the channel lease will expiry. May be marked as 0 if the user opened the channel to the LSP, and the LSP has no obligation to keep open.
+  - MUST be 0 or greater.
+
+> **Rationale `original_order`** The client MAY want to look up the original order for reference.


We don't have order_ids in LSPS2, how do we deal with that here?

original_order MUST now be omitted for channels that weren't opened through an order with an id, with LSPS2 as the example. See the top-level reply.

tnull

Some more comments. It might also be good to think this through in conjunction with splicing (cf. #65 for example). In particular, it could get messy which 'parts' of the balance are considered expired when exactly, for example.

tnull · 2026-03-20T14:08:01Z

+  - MUST be an empty string if the token was not provided.
+- `created_at` <[LSPS0.datetime][]> Datetime when the order was created.
+- `order_state <string enum>` Current state of the order.
+  - `CREATED` Order has been created. Default value.


Why do we need to publish another funding if we extend the channel?

Copy-paste from LSPS1, fixed. COMPLETED now means the lease has been extended and channel.expiration_block equals new_channel_expiry_block.

tnull · 2026-03-20T14:09:17Z

+- `order_state <string enum>` Current state of the order.
+  - `CREATED` Order has been created. Default value.
+  - `COMPLETED` LSP has published funding transaction.
+  - `FAILED` Order failed.


How do we imagine the user gets reimbursed if they pay via Lightning? Do we still need to clarify that the LSP has to hold the HTLC until they updated the order state fully to make the state transition atomic (although we probably don't need a HOLD state)?

Added section 4: the LSP MUST NOT release the preimage before the new expiry is persisted, and if the extension fails it fails the HTLC (that is the refund) and sets REFUNDED. I kept HOLD since the payment object comes from LSPS1, but noted it should only last briefly because extending a lease is a bookkeeping change. There's also a new section 5 for the extension itself, mirroring LSPS1's channel open section.

Add BOLT12 to the payment example and fix order_total_sat, which for an extension equals fee_total_sat. Add the 102 unrecognized or stale token error and only require token validation when a token is given. Fix the COMPLETED order state, which described a funding transaction. Define which SCID identifies a channel, allow LSPS2 channels by omitting original_order, and clarify extension_order_ids, max_channel_extension_expiry_blocks and original_order.service. Add payment rules requiring the LSP to persist the new expiry before releasing the preimage, and failing the HTLC as the refund. Add channel extension and splicing sections. Fix a trailing comma in the create_order example and a broken LSPS0.datetime link.

kaloudis · 2026-09-26T18:36:36Z

Thanks for the review. Addressed in 2bde89e.

On LSPS2: I'd rather not add order ids to LSPS2 for this. original_order is already optional, so LSPS2 channels are listed without it and identified by short_channel_id alone. The spec now says so, and says that expiration_block for those channels is set by LSP policy since bLIP-52 has no lease term.

On splicing: I added a section that defines the lease on the channel as a whole. A splice does not change expiration_block, and after a splice the LSP returns the new SCID. Tracking per-portion expiries seemed like more complexity than it is worth, and an LSP that wants to charge for spliced-in liquidity can price that in the order that adds it (e.g. bLIP-65's flow).

kaloudis force-pushed the lsps7 branch from 5853273 to c4151da Compare January 10, 2025 15:52

dzdidi suggested changes Jan 12, 2025

View reviewed changes

bLIP-57: Channel Lease Extensions (LSPS7)

719c320

kaloudis force-pushed the lsps7 branch from c4151da to 719c320 Compare January 14, 2025 04:47

joostjager reviewed Feb 11, 2025

View reviewed changes

tnull mentioned this pull request Mar 24, 2025

bLIP-52/LSPS2 service: Revisit service params lightningdevkit/ldk-node#478

Open

kaloudis mentioned this pull request Feb 27, 2026

feat: add LSPS7 (Channel Lease Extensions) client handler lightningdevkit/rust-lightning#4450

Closed

tnull reviewed Mar 20, 2026

View reviewed changes


		## 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.

Conversation

kaloudis commented Jan 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kaloudis commented Feb 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MegalithicBTC commented Mar 10, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kaloudis commented Sep 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants