Mfrhtyj

Alex Bosworth recently pointed out:

I see people connect to a "well connected" node on LN and by that they mean they connect to a node with lots of channels. The number of channels is actually a contra-indicator of a node's ability to route. Good routers curate and balance. Bad routers spam the open channel button. [Emphasis added]

What criteria should be kept in mind when evaluating nodes while opening new channels on the lightning network?

I agree with Alex Bosworth and I have pointed this out about one year ago when I have filed an issue about the strategy used by the LND autopilot which basically looks for nodes with a high channel count. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.

There are several kind of information we can look at (my autopilot currently only looks at the first ones):

1. Network topology:
   
   
   
   
   • How can I increase my centrality (e.g. by connecting to central nodes)
   
   
   • How can I increase my probability to have well funded routes by connecting to points where a lot of liquidity is floating around
   
   
   • Improve the network topology by increasing the amount of triangles
   
   
   • Geography: It is likely that you pay to services where you live and therefor you might want to connect to nodes that have a similar geoip as yours.
   
   
   
   


2. Node Provenance / properties:
   
   
   
   
   • age of Node (seen by oldest channels)
   
   
   • age of channels (seen by the blockheight of funding transactions)
   
   
   • uptime of the node (can be tracked via the gossip messages and the gossip store)
   
   
   • Routing fees of the node
   
   
   • Reliability of the node to forward payments (can be tracked by doing fake 1 satoshi payments to yourself over different routes)
   
   
   
   

most of the stuff that I mentioned here has been taken from my blog article about autopilots. In general I hope that better autopilots will emerge because I think this problem will be hard to decide by humans without investing a lot of time.

Finally another strategy could be to create routing tables in a similar way as the border gateway protocol does on top of IP. In that case nodes would share partial information about the channel balance so that we would have a better overview of where liquidity is missing.

Here there are some properties:

Node reliability: On-line connected 24/7.

History: when the node came online for first time.

Routing: How many channels has the node.

Capacity: How much capacity can the handle through channels