ajpwahqgbi / lightning-tools Goto Github PK

The function get_lowfee_reachable_unweighted_maxflows takes about 10 minutes to calculate on my PC.

The script is supposed to call this function for every other node, so 10.000 times for example. This means it will take years to finish. I'm sure this is not normal, so what can be the reason that get_lowfee_reachable_unweighted_maxflows is so slow in my case?

Also calculate the geomean of the low-fee capacity to each other low-fee reachable node; that is, the geomean of the maximum amount we could send to each of those nodes while satisfying the cost constraints.

Also see the paper in #3.

I am trying to use node recommender on Umbrel, but get the following issue. I replaced lightning-cli listnodes with docker exec lnd lncli listnodes, as below. I created the file lnchannels.20210202 as in the readme. What am I doing wrong?

(echo "{"; docker exec lnd lncli listnodes | tail -n +2 | head -n -2; echo "],"; cat lnchannels.20210202 | tail -n +2) | ./node_recommender.py 2033 250

No help topic for 'listnodes'
Traceback (most recent call last):
File "./node_recommender.py", line 291, in
json_data = json.load(sys.stdin)
File "/usr/lib/python3.7/json/init.py", line 296, in load
parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
File "/usr/lib/python3.7/json/init.py", line 348, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.7/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.7/json/decoder.py", line 353, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 2 column 1 (char 2)

The script includes a few banned nodes, like 1ML. But what is the rationale behind this? Does it speed up calculations? And do I need to ban every large node or just these two?

It would be nice to generate a huge SVG from a dot graph for various things, in particular for the prospective peer exploration.

• newly low-fee reachable nodes and edges connecting (new or existing) low-fee reachable nodes to new low-fee reachable nodes should be highlighted in green
• nodes with low-fee routability improvements and edges between (new or existing) low-fee reachable nodes to nodes with low-fee routability improvements should be highlighted in purple
• some sort of visualization of min cuts; perhaps it would be too busy, though, to highlight and dash all the edges that are in the min cut for a newly or improved low-fee reachable node

Consider the following graph described by the edges (src, dest, cost): (a, b, 0.1), (a, c, 0.8), (b, c, 0.0), (b, d, 0.8), (c, d, 0.8). Each node and each edge would be contained in the low-fee reachable subgraph with a cost threshold of 1.0. The naive maxflow--i.e. the way that the maxflow is currently calculated--between node a and node d is 2: ((a, b), (b, d)), ((a, c), (c, d)).

However, despite the fact that all nodes and edges are low-fee reachable, not all routes within the low-fee reachable subgraph satisfy the cost constraint. Specifically the flow ((a, c), (c, d)) has a cost of 1.6 and violates the cost constraint.

The problem is further complicated by the fact that fees in the LN are vectors and not scalars.

Luckily it appears that T.H Szymanski from McMaster university has a good solution to the problem in the IEEE WCNC 2012 paper "Achieving Minimum-Routing-Cost Maximum-Flows in Infrastructure Wireless Mesh Networks".