Feature Request: Warnings suppression/exemption for selected nodes/channels
hazrulnizam opened this issue · 7 comments
Is your feature request related to a problem? Please describe.
Some channels are used for direct transactions with the peer node e.g. channel to Nicehash is opened in order to perform frequent withdrawals of GPU mining proceeds. As such, these channels/nodes might be considered valuable even though they very seldom route any HTLCs nor they are used as source for rebalancing other channels. As it is, these nodes have a rating of 0 and shows up when the warnings endpoint is called (since its node rating is lower than the threshold).
Describe the solution you'd like
It would be great if an lnd-manageJ user can specify a list of nodes or channels, perhaps in lnd-manageJ.conf, that they would like to suppress warnings for, so that these nodes/channels do not appear when the warnings endpoint is called. For example:
[warnings] channel_fluctuation_lower_threshold=10 channel_fluctuation_upper_threshold=90 max_num_updates=100000 node_flow_minimum_days_for_warning=30 node_flow_maximum_days_to_consider=90 online_percentage_threshold=80 online_changes_threshold=50 node_rating_threshold=1000 exempt_node=027ce055380348d7812d2ae7745701c9f93e70c1adeb2657f053f91df4f2843c71,037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba exempt_channel=810694112540164098
Describe alternatives you've considered
What if a rating is given to these channels/nodes, that will push them above the threshold? I though about this, but do not know how to derive a suitable rating from information available.
The rating is based on the idea that the node (with all of the peers and channels) serves as a routing node. I agree that even for routing nodes there are exceptions (I also have a few). I like the idea of adding a manual list of exceptions/exemptions. Do you think it's a good idea to also exclude those nodes/channels from the rating computation, i.e. return "no rating" for them?
I think the rating computation is still very useful as a benchmark. It is the warnings that I feel should be reserved for truly 'problematic' nodes/channels.
I would propose to exempt nodes/channels by "warning type" to have finer control.
Example:
I am okay with some channels having a very low rating but I still want to see a warning if the channel has too many updates or if the node is too much offline.
How about this config structure:
[warnings]
channel_fluctuation_lower_threshold=10
channel_fluctuation_upper_threshold=90
channel_fluctuation_ignore_nodes=027ce055380348d7812d2ae7745701c9f93e70c1adeb2657f053f91df4f2843c71
channel_fluctuation_ignore_channels=810694112540164098,810694112540164099
max_num_updates=100000
node_flow_minimum_days_for_warning=30
node_flow_maximum_days_to_consider=90
online_percentage_threshold=80
online_changes_threshold=50
node_rating_threshold=1000
node_rating_ignore_nodes=027ce055380348d7812d2ae7745701c9f93e70c1adeb2657f053f91df4f2843c71,037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba
I would start implementing this feature as soon as I receive feedback.
That is an even finer control than my initial suggestion. I would be happy to have that.
channel_fluctuation_ignore_channels=810694112540164098,810694112540164099
The config file (and supporting code) allows several values for the same key. So instead of using some comma separated value, I'd rather have two entries:
channel_fluctuation_ignore_channel=810694112540164098
channel_fluctuation_ignore_channel=810694112540164099
Thank you so much for this! You guys rock!