pull down to refresh

If you ever ran a routing lightning node, you have probably experienced how hard and time consuming it is to do it right.
From selecting good peers that would bring activity to your node, to crafting batch transactions to save on fees, or monitoring the channels' performance to close underperforming ones.
Many runners have scripts that gather routing statistics, monitor peer connections and even probe thousands of routes to see which ones run low on liquidity. These tasks are not trivial and require someone to be on top of them regularly. Furthermore, certainly not every node runner is able or capable of doing that.
Well, Hydrus is my attempt at automating all those operations into a single agent that handles channels opening, closing and splicing (once available in LND) by itself.
I believe it could save a lot of time and energy from bitcoiners, so they can dedicate them to funnier and more interesting tasks.

How does it work?

When opening channels, Hydrus ranks all nodes in the network graph to determine which ones are the best candidates to connect to and opens a channel to them in a single on-chain transaction. Hydrus will always respect the minimum and maximum channel size and number of channels configured.
When closing channels, Hydrus will evaluate the performance of all local channels and peers, and will close only those that fail to reach the minimum requirements. Closing a channel should be the last option, so it has to do really bad compared to the others to be closed.
Both algorithms can be tweaked by changing the heuristic weights in the configuration. For example, if you value a node's centrality more than its fees, you could set all centrality heuristics to 1 and fees to 0.5 or 0 (disabled).
The user may provide a list of nodes not to open channels with or a list of channels to keep no matter how they perform.

Dry run

If you just want see what Hydrus would have done in a real scenario, enable the dry_run option in the configuration. No channels will be opened, closed or re-sized.

Getting nodes and channels ranking

Similarly, you could execute the binary with the --nodes_scores CLI flag to get a full list of the candidates ranked by their score, or with --channels_score to get an overview of the node's active channels performance.

Wrap up

Hydrus is free open-source software, its source code is at https://github.com/aftermath2/hydrus.
This project is still in beta phase and there is definitely a lot of room for improvement, I would really appreciate any feedback or suggestions. Please feel free to open an issue or submit a pull request at the repository.
If you want to support my work, you can follow me on nostr at npub1vg7rf9g8xmmyyxq3g75meltprz2ur6kkuudtjdf4j49d356evuyspt380h.
Hmm, very interesting. I'm always happy to see people work on LN development. I'm an amateur LN node runner, but I've never been able to do so profitably. Nor do I have any intention of spending the time to make it profitable, but if someone can make an easy to install software that automates it, I'd be very interested.
Questions:
How often does it decide to open/close channels and how does it decide when is a good time? I assume it looks at on-chain fees, but what's the decision rule?
You also mentioned centrality vs channel fees in determining which nodes to open channels to. But I thought channel fees were not public info? Maybe I'm wrong about that
reply
You also mentioned centrality vs channel fees in determining which nodes to open channels to. But I thought channel fees were not public info?
Routing policies are public, otherwise your node wouldn't be able to construct a route. You get all the network nodes routing policies using the lncli describegraph command, it will display all edges and two fields node1_policy and node2_policy indicating how much fees they charge, HTLC ranges, etc.
reply
thanks, good to know!
reply
How often does it decide to open/close channels and how does it decide when is a good time? I assume it looks at on-chain fees, but what's the decision rule?
That is up to the user to decide, you can run Hydrus daily, once a week, once a month, etc. This is typically configured in the systemd service timer or in a cronjob.
Once executed, the agent gathers information from the local node to decide whether it should open new channels (num_channels < max_channels) or potentially close some (num_channels > min_channels). So in some scenarios it may not do any changes.
Apart from that, there's a configuration called agent.channel_manager.max_sat_vb which is the maximum number of satoshis per virtual byte that you are willing to spend. If transaction fee is estimated to be higher than that value, no changes will be made.
So yeah, the agent can be scheduled to execute at anytime but it may do nothing depending on certain factors.
reply
35 sats \ 1 reply \ @siggy47 27 Mar
Dumb question: If you're trying to experiment with a routing node, I would assume if you choose to automate, you must pick one option, or else chaos would ensue? For instance, try hydrus for opening channels while using LNDg to automate fees?
reply
As long as the other tools do not open/close channels I think it should be fine.
Hydrus in particular will base its decisions based on the current node and network states, and will try to be between the configured number of channels. It currently does not make changes to routing policies, although I might change that to facilitate things even more.
So the worst case scenario is that the other automation tool is opening/closing channels to keep the node in a certain state different than Hydrus. That would cause a conflict and both agents would keep making changes one after the other.
reply
I am curious to see how it works. It might help level the playing field when it comes to routing nodes.
reply
interesting, curious to test
reply