Allow setting a ChannelConfig for LSPS2 JIT channels#985
Open
IgnacioPorte wants to merge 1 commit into
Open
Conversation
When acting as an LSPS2 service, we'd previously always reuse the node-wide configuration for the JIT channels we open towards clients, while hard-coding their forwarding fees to zero. Here, we add an optional channel_config field to LSPS2ServiceConfig that allows configuring the JIT channels separately from regular channels. If unset, we retain the previous behavior, i.e., zero forwarding fees, as we're compensated via the channel opening fee. This resolves the TODO to revisit the hard-coded zero-fee decision. This change was developed with the assistance of AI tooling (Claude Code).
|
I've assigned @tnull as a reviewer! |
tnull
reviewed
Jul 15, 2026
tnull
left a comment
tnull
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for looking into this. While I think it makes sense to let the LSP configure certain values, ChannelConfig also has a few fields that don't make sense / we don't want to override (notably forwarding fees, but also stuff like accept_underpaying_htlcs). So it's not the right type for this API. If anything we need to create an LSP-specific channel config variant.
| /// If set, the given config is used without modification. Note that this means any | ||
| /// forwarding fees configured here are charged in addition to the channel opening fee. | ||
| /// | ||
| /// If set to `None`, we'll reuse the node-wide config, but override the forwarding fees |
Collaborator
There was a problem hiding this comment.
It's odd to reuse the object, but then honor only a few fields of it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey this PR closes #961.
Context
When acting as an LSPS2 service, the LSP always reuse the node-wide configuration
for the JIT channels it opens towards clients, hard coding their forwarding fees
to zero. An LSP may however want different parameters on client channels than
on its public channels, e.g., different forwarding fees or a different
cltv_expiry_delta.Changes
Adds an optional
channel_configfield toLSPS2ServiceConfig:ChannelConfigis applied as-is to newly-opened JITchannels. In particular, configured forwarding fees are charged in addition
to the channel opening fee.
None), behavior is unchanged: we reuse the node-wide config butoverride the forwarding fees to zero, as we're already compensated via the
channel opening fee.
Compatibility
This is a breaking change, existing
LSPS2ServiceConfiginitializers need toprovide the new field. I assumed this is acceptable based on the struct's
history.
Testing
Extended
lsps2_client_service_integrationto pass a custom config and assertthe opened JIT channel carries it.
This PR was developed with the assistance of AI tooling (Claude Code).