Silen Zara

I simplified my channel acceptance criteria a lot and updated my site with the new policies: https://cyberdyne.sh/ From now on, for all nodes: - Minimum size: 10M sats - Maximum size: 30M sats, but it scales up to 500M sats if the opening node has a lot of capacity. The actual max is about 10% of the requesting node's total public capacity. The reject message is now much clearer about the problem and shows exactly the range of channel sizes you are allowed to open (if the requested size is out of that range). I used to check for many things (available sockets, number of channels, terminal score, and latency) and even had a higher minimum size for large nodes, but all of that made things too complex and hard to explain. From now on, just a simple channel size range and that's it.

I often see my peers increasing their fee to me by a very small amount (5 ppm or less). To me this makes very little sense because you risk losing traffic due to FEE_INSUFFICIENT errors (until the update is propagated through the network) for only a very small gain in profit. That's why I use a lower limit on my fee increases. A reasonable amount I personally use is to take the square root of the current fee and use that as a minimum. For (very) low fee rate channels you can override this minimum to something like 10 and for higher fee rate channels maybe something round 25. It becomes even more important if you want to serve transaction from lightning users who are not online all the time and can have a very outdated view of the network. So if you want to maximize your chances of getting routes through your node (which you should) then you've got to be considerate about how you do fee updates.

Graph centrality is an overrated metric for pure routing nodes if they want to optimize their capital efficiency. With more peers it becomes increasingly difficult to make them all flow. If you want to optimize APY then it's often better to have smaller, more specialized nodes that have all channels working together "in the same flow".

There's a lot of information to be learned by observing the payments flowing through a routing node. By having eyes on every payment, over time you will build up intuition about which routes are important to your node. Eventually you will spot patterns and then the fun starts in figuring out how to increase (or decrease!) the probability of those patterns occuring. It can be tricky to spot those patterns because cause and effect are not obvious and seem decoupled without the right intuitions. This is the core concept of running a successful routing node.