Published on: 2022-03-20T09:07:01+00:00
In the given context, various topics related to Lightning Network routing are discussed. The discussion on zerobasefee suggests that HTLCs are always free to an attacker. However, Zmn's approach for overweighing base fee can be used to let the market decide on the relative importance of optimized routing vs base fees. Martin's research on minimum convex cost flow formulation for multi-part payments on the lightning network is paywalled and not available at sci-hub. An alternative paper by Dorit Hochbaum from 1993 proves proximity results for integer and continuous optimal solutions of the minimum convex cost flow.In an email, Rene thanks Carsten and other Lightning developers for discovering some minor inaccuracies in his piecewise linearization. They discuss Mission Control information provided by lnd, which primarily focuses on a statistic of the ratio of successful payments over the past X attempts on a channel given a certain time interval. Rene has written hands-on instructions in the rust repo and they have been fully implemented in the mainnet test and simulations. It is necessary to know the effective uncertainty by only looking at the effective amount that goes above the minimum certain liquidity and the effective capacity.The email thread discusses the possibility of combining parallel channels, which appears to be reasonable and may become necessary when considering fees and routing requests. However, split payments between parallel channels may not work well in practice due to routing node decisions and channel jamming. Mission Control (MC) information about channel balances may not be accurate for parallel channels as nodes can pick any of them. The size of piecewise linearization is discussed with the conclusion that splitting all channels into an equal number of pieces is well motivated. Leftovers after piecewise linearization could be pruned to reduce the size of the graph and improve runtime. The only requirement for the solver to work is that mu*fee_rate_ppm needs to be an integer.The given context also discusses various considerations related to Lightning Network routing. The author suggests pruning channels with high unit costs on the first segment, especially if they are further away from the source and destination node, to reduce the size of the graph and improve runtime. They have also worked on a heuristic that could throw away about 90% of all channels and found the same flow in the pruned network as on the full network. The author explains how to integrate fees into the function by linearizing the cost function between two features. However, this trick for CLTV or latency-based features will not work for the base fee. Regarding private channels, the author notes that from a probabilistic payment delivery point of view, hiding liquidity can be detrimental. Finally, the author talks about the quality of approximation and how it is possible to find a solution without error by using a finite number that corresponds to the channels capacity and making segments of 1 satoshi each encoding what this satoshi would actually cost in the original function.In the email, the author thanks Carsten, Martin, and fellow lightning developers for verifying and acknowledging their recent findings about the runtime of finding a piecewise linearized approximation to the min cost flow problem. They also discuss the combination of parallel channels and its probabilistic benefits in terms of liquidity availability. The conversation then moves on to the optimal piecewise linearization and the size of each piece. The author explains that splitting all channels into the same number of pieces is well-motivated from a probabilistic point of view and discusses the potential benefits of studying the optimal piecewise linear approximation. Finally, the issue of leftovers after piecewise linearization is addressed, with the author stating that this should not be an issue as long as the domain is larger than N.The email contains a long list of transactions with various details such as source node, target node, probability, and fee rate. The total probability of the entire flow is 0.0032, the total fee is 248793.763 sats, and the effective fee rate is 0.498%. There are 39 arcs included in the payment flow. The writer advises not to get confused by the low probability as the first attempt always has high uncertainty and they will learn fast in each consequent round.The email discusses various questions and considerations related to the development of lnd-manageJ, a tool for managing multi-path payments (MPPs) on the Lightning Network. The author expresses gratitude for a contribution that has allowed them to resume coding and intends to release a usable version soon. However, they note that the code can only be used for real MPPs once a usable MPP gRPC call is made available.
Updated on: 2023-08-01T00:10:19.307536+00:00