Skip to content

Adds InboundChannelsConfig configuration #594

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

a-mpch
Copy link

@a-mpch a-mpch commented Jul 8, 2025

Fixes partially #502

Context

When running a personal or business node would like to control how peers request channels either blocking all possible channels, announced channels or some channels given a minimum.

This is useful as operator to take care of how liquidity moves. Even more, if we acquired a channel LSP for specific reasons and don't want that liquidity to move.

Other example is when running a operative node (i.e, exchange / wallet) don't want to be full of tiny channels that could affect route finding.

Solution

Added a InboundChannelsConfig configuration on config.rs with two parameters to reject channels or set a minimum channel size. In case that node runner wants to block all possible channels, it would mean to set the minimum_channel_size to a greater number.

Questions

I was thinking that better approach is to have a "channels_config" and inside would have inbound (or policy / limits) and also de Anchors channel config.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jul 8, 2025

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-reviews-bot ldk-reviews-bot requested a review from tnull July 8, 2025 01:30
This commit aims to give two new configurations for node runners
that want to control how inbound channels are requested.

- `reject_announced_channels_requests`: Enable user to reject any
request channel for announced channels.
- `minimum_channel_size`: Permits node runner to set a minimum channel
size for remote peers to open channels.
@a-mpch a-mpch force-pushed the 2025-07-add-disable-and-min-amount-incoming-channels branch from 2479260 to 610b49b Compare July 8, 2025 04:13
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 4th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excuse the delay here! Tbh. I punted on this so far as I'm a bit on the fence about where we want to take the config 'design' overall. Given that for the LSP service we'll want to expose a proper interface that allows users more fine-grained control over which liquidity requests they accept, I also wonder if it would make sense to solve the issue at hand in a similar way.

@a-mpch
Copy link
Author

a-mpch commented Jul 16, 2025

No problem, maybe I could increase the scope of this to help on the LSP interface so it could be solved in a better way.

Said so, wouldn't LSP nodes would like to reject most channels except the ones that LSP opens as liquidity request or collaboratively open with their peers? Maybe I'm missing something from the spec?

@tnull
Copy link
Collaborator

tnull commented Jul 17, 2025

No problem, maybe I could increase the scope of this to help on the LSP interface so it could be solved in a better way.

Thanks, but I believe that might be out-of-scope for this PR. I also believe someone else wanted to look into it already, have to double check if they're actually coming through though.

Said so, wouldn't LSP nodes would like to reject most channels except the ones that LSP opens as liquidity request or collaboratively open with their peers? Maybe I'm missing something from the spec?

Maybe? Probably? But the question is more around a consistent API design. If we introduce an interface for inbound liquidity requests, we could also consider creating a parallel one for channel requests that would provide more flexibility for users that want it. We'll see, not entirely sure yet.

@a-mpch
Copy link
Author

a-mpch commented Jul 18, 2025

Sure! I'll close this PR then. Feel free to reopen or ping it if it makes sense in the future. Happy to help :)

@a-mpch a-mpch closed this Jul 18, 2025
@tnull
Copy link
Collaborator

tnull commented Jul 18, 2025

Sure! I'll close this PR then. Feel free to reopen or ping it if it makes sense in the future. Happy to help :)

Cool, thanks! Yes, depending on which way we'll go, we might even go ahead with the changes at hand, it's just not entirely clear yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants