Am Di., 31. Aug. 2021 um 10:29 Uhr schrieb ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org>:
> For myself, I think a variant of Pickhardt-Richter payments can be created > which *adapts to* the reality of the current network where `base_fee > 0` is > common, but is biased against `base_fee > 0`, can be a bridge from the > current network with `base_fee > 0` and a future with `#zerobasefee`. I have been thinking about your idea (at least what I understood of it) of using amount*prop_fee + amount*base_fee/min_flow_size, where min_flow_size is a suitable quantization constant (say, 10k or 100k sats, may also chosen dynamically), as a component of the cost function, and I am pretty sure it is great at achieving exactly what you are proposing here. This is a nicely convex (even linear in this component) function and so it's easy to find min-cost flows for it. It solves the problem (that I hadn't thought about before) that you have pointed out in splitting flows into HTLCs. If you use min_flow_size=max_htlc_size, it is even optimal (for this min_flow_size). If you use a smaller min_flow_size, it is still optimal for channels with base_fee=0 but 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. So it will be biased against channels with larger base_fee. But notice that with min-cost flows, we are rarely looking for the cheapest solution anyway, because these solutions (if they include more than one path) will usually fully saturate the cheapest channels and thus have very low success probability. So all in all, I believe you found a great practical solution for this debate. Everybody is free to use any base_fee they chose, we get a workable cost function, and I conjecture that economics will convince most people to choose a zero or low base_fee. Cheers Stefan _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
