-
Notifications
You must be signed in to change notification settings - Fork 114
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
Adds InboundChannelsConfig
configuration
#594
Conversation
I've assigned @tnull as a reviewer! |
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.
2479260
to
610b49b
Compare
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
🔔 2nd Reminder Hey @tnull! This PR has been waiting for your review. |
🔔 3rd Reminder Hey @tnull! This PR has been waiting for your review. |
🔔 4th Reminder Hey @tnull! This PR has been waiting for your review. |
There was a problem hiding this 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.
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? |
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.
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. |
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. |
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 onconfig.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 theminimum_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.