<unnamed>

Public Key

npub1gudxspr8gkafq0mvzrwpj5qyuhtr3euwqf08rlkdr63zhe39l30qzplrqg

Profile Code

nprofile1qqsywxngq3n5tw5s8akpphqe2qzwt43cu78qyhn3lmx3ag3tucjlchspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qjm7aw3

Publishing to

relay.nostr.net

Last Notes

2023-06-09 15:05:33 CEST

- reply

📅 Original date posted:2022-03-21
📝 Original message:
Hello Stefan, hello Lightning Devs,
> As to Martin's approximation research, I have asked myself similar
>
> questions. Unfortunately, the paper you cite is paywalled and not
>
> available at sci-hub, so I haven't read it.
Sorry for the paywalled link, without paywall you can read the article on Google Books preview:
https://books.google.de/books?id=hbXsCgAAQBAJ&pg=PA63&source=gbs_toc_r#v=onepage
I like your neat and simple proof idea for approximation preservation!
Cheers, Martin

2023-06-09 15:05:33 CEST

- reply

📅 Original date posted:2022-03-14
📝 Original message:
Dear Lightning Developer, Rene & Carsten,
The min-cost flow formulation for MPP of Rene and Stefan [1] intrigued me and brought me to think about how this optimization problem can be solved efficiently in order to contribute to practically relevant reliable payments on the Lightning network. Applying linear approximation to the convex non-linear cost function C(f) brings runtime improvements [2], however an approximation can deteriorate the solution quality.
This brought me to think about the approximation quality/error of a piecewise linear approximation for the cost function C(f) and how that translate to the original success probability of a flow P(f). After some back and forth with Rene over the last couple of days, I summarized some preliminary insights in the following:
[3] https://raw.githubusercontent.com/drmartinberger/mpp-approx-pf/main/approxPf.pdf
The main (admittedly, mostly theoretical) outcome is, that a piecewise linear approximation of C(f) with given approximation error, also gives an approximation of the function P(f) with lower/upper bound.
However, [3] further underpins the "goodness" of the approach [1] and might address some of Carsten's concerns [4] and of the previous post of Carsten (especially 8) ).
Feedback of any kind is warmly welcome and feel free to reach out in case of questions.
Thank you!
Cheers,
Martin
[1] https://arxiv.org/abs/2107.05322
[2] https://github.com/renepickhardt/mpp-splitter/blob/master/Minimal%20Linearized%20min%20cost%20flow%20example%20for%20MPP.ipynb
[3] https://raw.githubusercontent.com/drmartinberger/mpp-approx-pf/main/approxPf.pdf
[4] https://twitter.com/c_otto83/status/1502329970349248521

2023-06-09 15:05:32 CEST

- reply

📅 Original date posted:2022-03-19
📝 Original message:
Dear Carsten, Rene and fellow lightning developers,
Regarding the approximation quality of the minimum convex cost flow formulation for multi-part payments on the lightning network [1] and Carsten's discussion points on Twitter [2] and on the mailing list:
> 8) Quality of Approximation
>
> There are some problems in computer science that are hard/impossible to
> approximate, in the sense that any kind of deviation from the optimum
> could cause the computed results to be extremely bad. Do you have some
> idea (or proof) that your kind of approximation isn't causing a major
> issue? I guess a piece-wise linearization with an infinite number of
> pieces corresponds to the optimal result. Given a finite number of
> pieces, how large is the difference to the optimum?
I did some literature research and came across an insightful paper [3] by Dorit Hochbaum from 1993, that proves proximity results for integer and continuous optimal solutions of the minimum convex cost flow as well as proximity results of the optimal solutions for a piecewise linear approximation and the original problem.
Admittedly theoretical results, however, it further underpins that a piecewise linear approximation is a reasonable approach to find optimal flows and even shows that searching for optimal solutions on the continuous domain (e.g. with descent methods from convex optimization) also gives near-optimal solutions on the integer domain.
Cheers,
Martin
[1] https://arxiv.org/abs/2107.05322
[2] https://twitter.com/renepickhardt/status/1502293438498234371
[3] https://www.worldscientific.com/doi/abs/10.1142/9789812798190_0005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220319/f278c153/attachment.html>