LSPS2: Support splice-in for JIT provisioning #65
Conversation
| `payment_size_msat - opening_fee`, plus any reserve needed on the LSP | ||
| side. | ||
| The LSP determines the funding delta and resulting channel balances. | ||
| The LSP MUST ensure the resulting channel balances allow forwarding at least |
There was a problem hiding this comment.
I think we discussed this elsewhere, but I do think it would be easier in terms of backwards compat., "no surprisees", etc, if we mandate that the LSP always splices in at least payment_size_msat. I.e., the open_channel flow would be untouched, and if the LSP splices it's required to add exactly the same liquidity to the channel as if it was opening a new channel.
You already solve this with the paragraph below, but here, we also need to clarify the new balance should be at least old_balance + payment_size_msat - opening_fee.
| the LSP MAY satisfy an LSPS2 buy by performing a splice-in instead of opening | ||
| a new channel. This choice does not change any LSPS2 messages or parameters | ||
| and is transparent to the client. | ||
| * When choosing splicing, the LSP SHOULD splice-in the full amount of the |
There was a problem hiding this comment.
Let's make this SHOULD a MUST, otherwise it might become very confusing to the client how to track balances/what to expect. If the LSP can use previously-paid liquidity to forward the payment, the client would either be doulby charged or would need to have a way to learn about this beforehand to be able to reevaluate which fee rate offering they deem acceptable. To keep it simple, we need to require splicing to be 1:1 the same contract as opening a new channel.
| * If satisfying an LSPS2 buy via splice-in, the LSP MUST forward only after the | ||
| channel is no longer quiescent, i.e., after both peers have exchanged the | ||
| `tx_signatures` message for the splice transaction per [Splicing][]. The LSP | ||
| MUST NOT require the `splice_locked` message before forwarding. |
|
|
||
| Timeouts and fallback: | ||
|
|
||
| * The `opening_fee_params.valid_until` also applies to splice negotiation. If a |
There was a problem hiding this comment.
I think we also need to clarify how the min_lifetime of the channel is changed during splice-in?
Note this might be an issue where we get to the limits of what is easily expressible with LSPS2: if the client already is close to the end of the lifetime of the original channel, the LSP probably doesn't want to renew the full channel for the opening fee of the new incoming payment.
So the LSP has three options:
- Price-in the TLV of the previously-provisioned liquidity into the offering for the new payment (although that is race-y, given the
valid_untilperiods could overlap). That in turn means that the client sees higher rates from their LSP, without explicitly knowing why/what they're getting into. - Still default to
open_channelto keep the two flows independent. - Decidedly splice-out the original balance some time after the
min_lifetime. Maybe we should clarify that this is an option for the LSP here, which makes it all the more important that they MUST add the fullpayment_size_msaton top rather than 'merging' the channel balances.
|
|
||
| * If the LSP and client already share a channel that supports splicing (i.e., | ||
| splicing was negotiated for that specific channel per [Splicing][]), | ||
| the LSP MAY satisfy an LSPS2 buy by performing a splice-in instead of opening |
3 participants
Adapts the current LSPS2 spec to also support splicing a channel instead of opening a channel If the LSP and client already share a channel that supports splicing.