Lagrang3

At this point there are some observations: 1. initializing my solvers is very expensive. 2. even the `simpleMCFNetwork` is slower than Ortool at solving the MCF. 3. the `MCFNetwork` solver...

@renepickhardt !!! Latest test: ``` runtime for graph initialization: 2.519 sec total runtime for MCF solve: 0.363 sec total runtime (including inefficient memory managment): 2.884 sec ``` The pseudo-polynomial solver...

Primal dual: ``` runtime for graph initialization: 2.745 sec total runtime for MCF solve: 1.255 sec total runtime (including inefficient memory managment): 4.001 sec ```

I will paste here the entire output for the aforementioned run of `basicexample.py` with `random.seed(64)` using `MCFNetwork` with the augmenting-path back-end: ``` Round number: 1 Try to deliver 10000000 satoshi:...

> Just adding a comment here as it's somewhat relevant: I have been working on an alternative min cost flow implementation as well for the Lightning Network. It's based on...

I am uploading here the latest benchmarks I obtained. The test cases were generated by the file `benchmark/benchmark.py`. Each test cases consist of a random pair of nodes from the...

Hi @adamritter. My first impression is that the Min. Cost Flow solver does just that. Any adjustment of costs and capacities should be performed in the following layer.

There should be then a correct algorithmic solution, which is not linear or convex MCF. It is a very interesting proposition, but we should, in my opinion, move this discussion...

BTW. we have this in `renepay` plugin, here [flow.h](https://github.com/ElementsProject/lightning/blob/master/plugins/renepay/flow.h). We first realized that a bound in the liquidity [a,b), meaning that the liquidity satisfies a

Hi @renepickhardt. I was considering the options we have to address this issue in the context of the Summer of Bitcoin project. One possibility is that we start coding the...