AcceptLND - Channel requests management tool for LND \ stacker news ~bitcoin

AcceptLND - Channel requests management tool for LND

4011 sats \ 9 comments \ @aftermath 12 Dec 2023 bitcoin

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.

Source code: https://github.com/aftermath2/acceptlnd

view all related items

76 sats \ 0 replies \ @antic 12 Dec 2023

this is great--should be baked into lnd

71 sats \ 0 replies \ @nikotsla 12 Dec 2023

Added to my to-do, useful :)

55 sats \ 4 replies \ @xz 12 Dec 2023

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

0 sats \ 3 replies \ @aftermath OP 12 Dec 2023

Thanks!

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.

10 sats \ 2 replies \ @xz 12 Dec 2023

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.

20 sats \ 1 reply \ @aftermath OP 12 Dec 2023

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=network.target
Wants=lnd.service

[Service]
WorkingDirectory=/home/<user>
Type=simple
ExecStart=/home/<user>/acceptlnd
User=<user>
Restart=always
RestartSec=60
KillMode=process

[Install]
WantedBy=multi-user.target

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.