ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-01 📝 Original message: Good morning Stefan, > > ...
📅 Original date posted:2021-09-01
📝 Original message:
Good morning Stefan,
> > 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 amountprop_fee + amountbase_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.
I am glad that this is helpful.
Still, I have not really understood well the variant problem "min cost flow with gains and losses" and this scheme might not work there very well.
On the other hand, the current algorithms are already known to suck for large payments, so even a not-so-good algorithm based on Pickhardt-Richter may be significantly better than existing deployed code.
On the software engineering side, the fact that it took you 2 months probably means implementing this would take even longer, like 6 months or so.
I mean to say that prior to deployment we would need the dreary tasks of unit tests and edge cases (which are needed to ensure that basic functionality is not lost if the code is later modified, or more perniciously, that bugfixes do not introduce more bugs), code review, and so on.
And for C-Lightning it would have to be implemented in C, which brings its own set of problems (memory management, being a lot more stringent about dotting every i and crossing every t, explicitly passing objects around, most likely rewriting in a continuation passing style/"callback style"...).
Now we could argue that C-Lightning in practice requires Python anyway, but it also depends on what libraries you pull in, even if C-Lightning in practice requires Python you still want to keep the dependencies few or else deployment can suffer.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Stefan,
> > 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 amountprop_fee + amountbase_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.
I am glad that this is helpful.
Still, I have not really understood well the variant problem "min cost flow with gains and losses" and this scheme might not work there very well.
On the other hand, the current algorithms are already known to suck for large payments, so even a not-so-good algorithm based on Pickhardt-Richter may be significantly better than existing deployed code.
On the software engineering side, the fact that it took you 2 months probably means implementing this would take even longer, like 6 months or so.
I mean to say that prior to deployment we would need the dreary tasks of unit tests and edge cases (which are needed to ensure that basic functionality is not lost if the code is later modified, or more perniciously, that bugfixes do not introduce more bugs), code review, and so on.
And for C-Lightning it would have to be implemented in C, which brings its own set of problems (memory management, being a lot more stringent about dotting every i and crossing every t, explicitly passing objects around, most likely rewriting in a continuation passing style/"callback style"...).
Now we could argue that C-Lightning in practice requires Python anyway, but it also depends on what libraries you pull in, even if C-Lightning in practice requires Python you still want to keep the dependencies few or else deployment can suffer.
Regards,
ZmnSCPxj