ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-16 📝 Original message: Good morning Rene, sorry ...
📅 Original date posted:2022-03-16
📝 Original message:
Good morning Rene, sorry for the lateness,
> Last but not least, please allow me to make a short remark on the (still to me very surprisingly controversial) base fee discussion: For simplicity I did not include any fee considerations to the published code (besides a fee report on how expensive the computed flow is). However in practice we wish to optimize at least for high reliability (via neg log success probabilities) and cheap fees which in particular with the ppm is very easily possible to be included to the piece wise linearized cost function. While for small base fees it seems possible to encode the base fee into the first segment of the piecewise linearized approximation I think the base fee will still be tricky to be handled in practice (even with this approximation). For example if the base fee is too high the "base fee adjusted" unit cost of the first segment of the piecewise linearized problem might be higher than the unit cost of the second segment which effectively would break the convexity. Thus I reiterate my earlier point that from the perspective of the year long pursued goal of optimizing for fees (which all Dijkstra based single path implementations do) it seems to be best if the non linearity that is introduced by the base fee would be removed at all. According to discussions with people who crate Lightning Network explorer (and according to my last check of gossip) about 90% of channels have a base fee of 1 sat or lower and ~38% of all channels already set their base fee away from the default value to 0 [16].
I think the issue against 0-base-fee is that, to a forwarding node operator, every HTLC in-flight is a potential cost center (there is always some probability that the channel has to be forced onchain with the HTLC in-flight, and every HTLC has to be published on the commitment tx), and that cost is *not* proportional to the value of the HTLC (because onchain fees do not work that way).
Thus, it seems reasonable for a forwarding node to decide to pass on that cost to their customers, the payers, in the form of base fees.
The response of customers would be to boycott non-0-base fees, by e.g. using a heuristic that overweighs non-0-base-fee and reducing usage of such channels (but if every forwarding node *has* a base fee, going through them anyway, which is why you just overweigh them, not eliminate them from the graph outright).
Then forwarding nodes will economically move towards 0-base fee.
So I think you would find it impossible to remove the base fee field, but you can strongly encourage 0-base-fee usage by integrating the base fee but overweighted.
(I think my previous formulation --- treat the base fee as a proportional fee --- would do some overweighing of the base fee.)
Which reminds me, I have not gotten around to make a 0-base-fee flag for `clboss`, haha.
And I might need to figure out a learning algorithm that splits base and proportional fees as well, *sigh*.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Rene, sorry for the lateness,
> Last but not least, please allow me to make a short remark on the (still to me very surprisingly controversial) base fee discussion: For simplicity I did not include any fee considerations to the published code (besides a fee report on how expensive the computed flow is). However in practice we wish to optimize at least for high reliability (via neg log success probabilities) and cheap fees which in particular with the ppm is very easily possible to be included to the piece wise linearized cost function. While for small base fees it seems possible to encode the base fee into the first segment of the piecewise linearized approximation I think the base fee will still be tricky to be handled in practice (even with this approximation). For example if the base fee is too high the "base fee adjusted" unit cost of the first segment of the piecewise linearized problem might be higher than the unit cost of the second segment which effectively would break the convexity. Thus I reiterate my earlier point that from the perspective of the year long pursued goal of optimizing for fees (which all Dijkstra based single path implementations do) it seems to be best if the non linearity that is introduced by the base fee would be removed at all. According to discussions with people who crate Lightning Network explorer (and according to my last check of gossip) about 90% of channels have a base fee of 1 sat or lower and ~38% of all channels already set their base fee away from the default value to 0 [16].
I think the issue against 0-base-fee is that, to a forwarding node operator, every HTLC in-flight is a potential cost center (there is always some probability that the channel has to be forced onchain with the HTLC in-flight, and every HTLC has to be published on the commitment tx), and that cost is *not* proportional to the value of the HTLC (because onchain fees do not work that way).
Thus, it seems reasonable for a forwarding node to decide to pass on that cost to their customers, the payers, in the form of base fees.
The response of customers would be to boycott non-0-base fees, by e.g. using a heuristic that overweighs non-0-base-fee and reducing usage of such channels (but if every forwarding node *has* a base fee, going through them anyway, which is why you just overweigh them, not eliminate them from the graph outright).
Then forwarding nodes will economically move towards 0-base fee.
So I think you would find it impossible to remove the base fee field, but you can strongly encourage 0-base-fee usage by integrating the base fee but overweighted.
(I think my previous formulation --- treat the base fee as a proportional fee --- would do some overweighing of the base fee.)
Which reminds me, I have not gotten around to make a 0-base-fee flag for `clboss`, haha.
And I might need to figure out a learning algorithm that splits base and proportional fees as well, *sigh*.
Regards,
ZmnSCPxj