pull down to refresh

TLDR : Do you think a routing node should choose the peers that bring more nodes nearer, or more edges nearer?
Context: I'm writing a lightning node channel advisor for routing nodes. The current method will, for a given transaction ammount, and a given max fee, check how many nodes and how many edges are reachable up to that max cost, in each direction (inbound, outbound). Then, it will check, from the peers that are not yet connected, how many new edges/nodes would be reachable if a channel was open to it. For now, i assumed the best candidate to connect to would be the one that would make reachable the most edges, in the liquidity direction where the node currently reaches the least edges. But, taking my own node into account, it seems i am in the case where the direction i can reach the smallest number of channels, is also the direction i reach the most nodes. So if i do the wrong assumption of what is better between more nodes nd more channels reached, i might actually do suboptimal choices: Choosing to optimize the wrong direction, on the wrong criterium.
My rationale for favouring more edges was:
  • it's the capacity that can be moved, not the number of edges, that gives potential traffic
  • 1sat=1sat, so channel capacities can be (somewhat) compared. One node is far less likely to be comparable to another, so reaching N more nodes is les meaningfull than reaching N2 more edges
But you could say for the opposite argument
  • It's the nodes themselves that initiate the payments. -1 node could have 500 edges, some to nodes already reachable, without guarantee of a cheaper cost for the new paths
Hopefully someone has an opinion on this?
Bonus question : i feel like there is not really a good place to discuss such subjects. Things that are not development of the protocols themselves, but somewhat developement related. Is there a good place i wouldn't be aware of?
Interesting question and I think if I were to try and make money as a LN service provider, I'd consider this a trade secret. Since I'm not and with little experience, the most I can do here is help generate ideas for you, so I don't mind spitballing.
I would try to gather as much info about the network as possible, make some initial test channels at low non-zero fee and come up with an adaptive algorithm that sees where fees are coming from and adds liquidity to chase and support the nodes generating those fees. I guess everyone else will be doing this as well so opportunities might be short-term and have more to do with predicting future flows than standard rent-seeking kind of behavior.
I'd imagine reputation weighs heavily as well so I'd want to ensure 100% uptime as I do all of the above so payments routed through me never fail.
reply
A logic would be to be the bridge between those two. I mean to make the connection between the central nodes with the edges. Like that you will bring the traffic from edges to the center and the center could spread the rest of the traffic to the edges.
What if the edges are some public nodes, but with a lot of private channels? Those edges need your bridge to the center nodes and you will make a lot of routing for them.
Don't consider all the LN traffic only from public nodes. There are many other private LN nodes that you don't "see" them, but are doing way more traffic than a public routing node.
i feel like there is not really a good place to discuss such subjects
Here is the right place to discuss these subjects and this is a very good question.
reply