// Raiju #Lightning
Raiju
Last month I beef’d up my Lightning Network node channel manager app raiju. I have been running a routing node (node alias matches the tool’s name, raiju) for a few years now, and while it certainly isn’t a profitable enterprise, I have at least learned a bit to make the node a reliable router. This is valuable enough for me to keep running it. I have been baking these lessons into my raiju app which is slowly automating more of my node management tasks. I don’t think any of them are mind blowing, but curious how much others are doing along the same lines.
The goal of raiju is to maximize a node’s routing reliability, while attempting to “break even” on costs. Raiju has a succinct interface, just four commands which are focused on the life-cycle of a channel: candidates, reaper, fees, and rebalance. It might be easiest to talk about the commands in pairs.
candidates and reaper focus on opening and closing channels. candidates analyzes the network graph and attempts to find distant clusters of nodes. The idea here is there might be some off-the-beaten-path routing to offer two (or more) clusters instead of just being yet another node connected to one of the massive routing nodes. There is a chance this might also just strengthen the network in general, making it less dependent on the major hub nodes. reaper is pretty straight forward, it just looks at the current channels and offers up ones which maybe should be closed have have the capital re-allocated to another channel.
fees and rebalance manage liquidity of the node’s current channels. fees does this in a passive manner, by setting the channel fees based on a channel’s current liquidity. If a channel has high local liquidity, fees are lowered to encourage routing and vice versa. rebalance manages liquidity in an active manner, pushing liquidity from channels with high local liquidity to channels with low local liquidity. The fees and rebalance commands coordinate with each other in order to avoid bleeding sats through active rebalancing. By default, the max PPM fee that rebalance will use is equal to the low local liquidity fee of fees. The idea here is protect against paying to move liquidity into a low liquidity channel, only to have it completely reverted by a payment which doesn’t pay as much in fees. Worst case scenario now is that the fees cancel out.
I had been running the fees command for a while, but last month saw quite a feel big upgrades:
- Extended the configure-ability of
feeswith threshold definitions so experimentation is easier (e.g. what defines a high liquidity channel? 80%? 85%?) - Added a “stickiness” setting for
feesto lower the amount of gossip in scenarios where a channel liquidity keeps jumping back and forth over a threshold feesnow has a daemon mode listening to all channel updates of a node in order to instantly update fees when needed, lowering risk of bleeding satscandidatesfilters Tor-only nodes by default now since they are so unstable- a
raijucontainer image is published now for easier installation
I’ll keep adding to raiju as I think of things, but I believe its in a decent spot today.
