AcceptLND is a channel requests management tool based on policies.
It makes it easy for node operators to set custom and complex requirements without writing a single line of code.
For example, the following policies will only accept channels with a capacity higher than 3M sats and from a node that is hybrid and has zero base fees on all his channels.
policies: - request: channel_capacity: min: 3_000_000 node: hybrid: true channels: zero_base_fees: true
A policy may have conditions which must be met for them to be enforced as well. Some of the things we can do with them are:
  • Reject channels from nodes whose median outgoing fee rate is higher than X sats (or lower than X, or between X and Y)
  • Set different requirements for public and private channels
  • Reject channels from a node that is already connected to you
  • Whitelist/blacklist nodes by public key
  • Reject channels from nodes that have a high rate of disabled channels
  • And much more
Multiple example policies can be found at examples.
Not only it facilitates controlling a node's channels and who you are connected with, but it could also be used to prevent potential attacks that would require certain setups to be performed. For instance, an attack that needs more than one channel opened to the same node could be mitigated with a policy that has node.channels.together.max = 1.
this is great--should be baked into lnd
Added to my to-do, useful :)
Love the concept. Would it be easy to implement a few further parameters to further customize requirements? Just curious.
policies: - request: channel_capacity: min: 3_000_000 node: hybrid: true min_node_age: 720d alias: true color: FF0000
Yes, alias and color would be trivial to add because they are in the GetNodeInfo RPC method response. I didn't add them because I thought they had no value and could be easily changed, do you think they should be added?
Regarding min_node_age, that kind of information is not provided by the LND RPC but can be obtained by checking that the node's oldest channel is at least 103,680 blocks old (not complex neither).
There is a worth mentioning workaround that requires no changes and uses the node.channels.block_height field. For example:
policies: - request: channel_capacity: min: 3_000_000 node: hybrid: true channels: block_height: operation: range min: 103_680 # 720 days * 144 blocks per day
However, that would be true only if the oldest and newest channels were created 103,680 blocks from each other.
I was thinking blocktime might be more helpful, and I guess oldest channel would validate when the node was known on network, so that'd be right.
I think the oldest channel might be more helpful to most users. I was thinking this as a selection criteria because it may be less likely with nodes having reputation from age, similarly to how it's used on some node ranking.
Guess color or alias would not be so useful, unless some edge case where maybe there could be secret criteria to open channels, or if users use implementation or protocol in it [lnd] [cln] [tor] ..
I'd like to run this, thinking if I can get it to start up as systemd / systemctl service. Would be good this way for integrating install guides into raspibolt, minibolt.
I agree it would be useful to have that field, I'll add it in the next release.
Running it with systemd is pretty straightforward, simply download the binary or compile it yourself (give it execution permissions) and create the following service with sudo nano /etc/systemd/system/acceptlnd.service
[Unit] Description=AcceptLND Wants=lnd.service [Service] WorkingDirectory=/home/<user> Type=simple ExecStart=/home/<user>/acceptlnd User=<user> Restart=always RestartSec=60 KillMode=process [Install]
And then sudo systemctl enable acceptlnd and sudo systemctl start acceptlnd.
Doing a guide for Minibolt and Raspibolt is a great idea, I'll open an issue on their repositories to see if they are ok with it.
Thanks for that. Upgraded go and got the service running.
Excelente debería aplicarlo