lndash
lndash copied to clipboard
Idea: Node well-connectedness index
Let's introduce the "Node well-connectedness index" - a scalar value that indicates how well-connected a node is.
WCI could be computed as this pseudocode:
wci = 0
for node in all_nodes_in_the_network:
wci += how_many_networks_hops_are_there_between_me_and(node)
We'd need to add channel capacities into the computation, because apparently if one channel is used as a network hop to reach lots of nodes, this is not optimal.
Once we establish the WCI, we can do to do the following:
- identify top 10 nodes that would be the best to open channel with to have the best WCI increase
- identify top 10 channels which we can close with the lowest WCI decrease
The WCI index and top 10 nodes/channels from above should be a separate tab, as this computation might take some time (we are iterating all nodes in the network, not just the ones we have open channels to).
@djmelik I would love to have your input on this. Especially on how we should include the channel capacity into the wci computation.
Love this idea. Especially since the new "Capacity vs Activity" plot is also really awesome.
"Node well-connectedness index" sounds cool. I think it comes pretty close to what they call "bos score" in lnd. Roasbeef mentioned that the autopilot will be completely revamped in v0.6. It'll have two flavors: Selection for routing nodes and for clients.
Here some background: https://github.com/lightningnetwork/lnd/pull/2212 https://github.com/lightningnetwork/lnd/pull/2006
Thanks for the links @21isenough. So it seems it's best to use the upcoming NodeScores
API to get this feature working. Still, this API is slightly different to what I suggest.
Yes, it is different indeed. There will always be a trade-off between your nodes "well-connectedness" and the networks decentralization.
I think, the WCI is a competitive metric while NodeScores
is trying to strike the right balance between the two (e.g. includes randomness).
There certainly is a place for both.
So the goal is to track graph centrality metrics to suggest nodes to connect to that will increase your betweenness? With the new scoring based autopilot system, it should be relatively easy to add these metrics, then let the user enable it on the command line, specifying a weight relative to the other metrics.
There's also an exposed query API that can be hit to allow the UI to poll for the impact w.r.t connecting to candidate nodes.
So the goal is to track graph centrality metrics to suggest nodes to connect to that will increase your betweenness?
@Roasbeef Exactly! Wonder whether we should use channel capacities in adjacency matrix
directly or we need to do a simple preprocessing first.