Published on: 2021-09-02T06:13:04+00:00
ZmnSCPxj proposes a variant of Pickhardt-Richter payments as a bridge from the current Lightning Network with base fee to a future with zero base fee. This variant can be created by adapting the cost function through the use of amountprop_fee and amountbase_fee/min_flow_size, where min_flow_size is a suitable quantization constant. The resulting function is convex and easy to find min-cost flows for it. However, it overestimates the fee for channels with base_fee > 0 and is less accurate the smaller the min_flow_size and the larger the base_fee.In another thread, ZmnSCPxj proposed the cost function: fee + fee_budget * (1 - success_probability), which becomes convex if the base-to-prop hack is done on the fee component. This can be made separable by redefining addition but this may break other properties that a mincostflow algorithm needs. The cost unit ends up being millisatoshi, which is attractive since everything should really be in terms of financial units. However, ZmnSCPxj is not sure if this would be workable since there may be a non-linear relationship between probability and fee. ZmnSCPxj also questions the effect of an increase in fee on success probability and vice versa. He proposes that if success probability is high, then the effect of an increase in fee should be larger compared to the effect of an increase in success probability, and vice versa if success probability is low. He is uncertain if neglogprob plus some fee times a conversion factor has that behavior.In an email exchange on September 1, 2021, a user named ZmnSCPxj cautioned against accepting the premise that a proposed algorithm is "optimal." The algorithm in question was deemed optimal under a specific heuristic used to approximate what the user wants. However, in reality, there are a lot of different factors to consider such as CLTV, fees, and estimated failure probability calculated from node online percentages at-open liquidity. ZmnSCPxj suggested translating all these factors to a single unit such as millisatoshi, which is already being done in practice. However, this involves some heuristics on the part of the application developer. There is no one-size-fits-all solution for balancing competing costs, and different designs may lead to different score units. Thus, neither approach can be provably better than the other.In a recent forum post, ZmnSCPxj cautioned against accepting the proposed algorithm as "optimal," stating that it is only optimal under a specific heuristic used to approximate user preference. Various considerations, from CLTV to fees, need to be balanced in reality, making it challenging to arrive at an optimal solution. However, ZmnSCPxj suggests that it may be possible to translate these considerations into a single unit of measurement: the millisatoshi. ZmnSCPxj went on to explain how CLTV-delta, node failure probability, and fees could be converted into millisatoshis. For instance, the total CLTV-delta time can be calculated based on the worst-case amount of time that an outgoing payment will be stalled. The expected nominal rate of return can be computed by putting the funds in a Bitcoin-denominated investment, which can then be converted into a percentage of the funds. Meanwhile, node failure probability can be multiplied with channel failure probability to determine the effective cost of this path. Finally, fees are already denominated in millisatoshis.The proposed algorithm for the Lightning Network is not necessarily "optimal" since there are many factors to balance, such as CLTV, fee, estimated failure probability, and fees. Heuristics are used to approximate what the user wants and balance these factors into a score that can be fed into a routing algorithm. However, there is no guarantee of convergence to a single solution, which may lead to nonconstructive disagreement between LN developers in the future. Additionally, this approach may make the job of node operators less predictable and be perceived as a loss of decentralization to the developers. Despite this, some argue that users should be able to solve an NP-hard problem if necessary, similar to how the program "apt-get install" solves an NP-hard problem every time it runs.In this conversation, a variant of Pickhardt-Richter payments is proposed that can adapt to the reality of the current network where base_fee > 0 is common but is biased against it. The idea involves using amountprop_fee + amountbase_fee/min_flow_size as a component of the cost function, where min_flow_size is a suitable quantization constant. This solution solves the problem of splitting flows into HTLCs and allows for finding min-cost flows easily. However, it could be less accurate for channels with a larger base_fee and smaller min_flow_size. Despite this, the solution is practical and can work well for most people.
Updated on: 2023-07-31T23:46:28.476285+00:00