ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-25 📝 Original message: Good morning again aj, ...
📅 Original date posted:2022-09-25
📝 Original message:
Good morning again aj, and Rene,
> Good morning aj, and Rene,
>
> > * you're providing a way of throttling payment traffic independent of
> > fees -- since fees are competitive, they can have discontinuous effects
> > where a small change to fee can cause a large change to traffic volume;
> > but this seems like it should mostly have a proportional response,
> > with a small decrease in htlc_max_msat resulting in a small decrease in
> > payment volume, and conversely. Much better for stability/optimisation!
>
>
> This may depend on what gets popular for sender algorithms.
>
> Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.
>
> * Simplifies the computation of base fee when using a min-cost solver.
> * Simplifies the design of splitting/merging decisions if not using a min-cost solver.
> * Improves privacy once we have PTLCs (if most senders use the same standard value, it is much harder to figure out if two sub-payments, with approximately the same standard quantum, belong to the same payment or not).
>
> If so, then we expect a large discontinuity for the `htlc_max_msat` vs `htlcs_sent` curve around whatever selected quantum there is.
> If you set `htlc_max_msat` below this quantum your expected number of payments forwarded will drop to near 0, but a little above that and you might very well saturate since all payments are quantized anyway.
>
> At least fees gets you basic economics of supply and demand, and is a natural throttle in all markets, including liquidity markets.
Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.
The `htlc_max_msat` vs `payment_volume` curve is basically the integral of the distribution of HTLC sizes.
But:
* As above, senders might quantize, and if some standard quantum becomes popular, the distribution is really a spike around the standard quantum, and there is a massive discontinuity there.
* Coffee or other popular everyday product may settle on a standard price, which again implies a spike around that standard price.
So the reliability of `htlc_max_msat` as a valve is dependent on market forces, and may be as non-linear as feerates, which *are* the sum total of the market force.
Feerates on the other hand are always going to be something that senders optimize for, because obviously senders will have a maximum amount they will be willing to pay in fees (as before, the intuition here is that the maximum fee senders are willing to pay is equivalent to the difference in subjective value between the millisatoshis they are sending and the service/product they are purchasing).
Whatever future sender algorithms are devised, feerates will still work consistently as a valve, whreas `htlc_max_msat` may fail in a future where sender algorihms quantize the payments around some standard quantum for privacy and ease-of-implementation purposes.
Regards,
ZmnSCPxj
📝 Original message:
Good morning again aj, and Rene,
> Good morning aj, and Rene,
>
> > * you're providing a way of throttling payment traffic independent of
> > fees -- since fees are competitive, they can have discontinuous effects
> > where a small change to fee can cause a large change to traffic volume;
> > but this seems like it should mostly have a proportional response,
> > with a small decrease in htlc_max_msat resulting in a small decrease in
> > payment volume, and conversely. Much better for stability/optimisation!
>
>
> This may depend on what gets popular for sender algorithms.
>
> Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.
>
> * Simplifies the computation of base fee when using a min-cost solver.
> * Simplifies the design of splitting/merging decisions if not using a min-cost solver.
> * Improves privacy once we have PTLCs (if most senders use the same standard value, it is much harder to figure out if two sub-payments, with approximately the same standard quantum, belong to the same payment or not).
>
> If so, then we expect a large discontinuity for the `htlc_max_msat` vs `htlcs_sent` curve around whatever selected quantum there is.
> If you set `htlc_max_msat` below this quantum your expected number of payments forwarded will drop to near 0, but a little above that and you might very well saturate since all payments are quantized anyway.
>
> At least fees gets you basic economics of supply and demand, and is a natural throttle in all markets, including liquidity markets.
Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.
The `htlc_max_msat` vs `payment_volume` curve is basically the integral of the distribution of HTLC sizes.
But:
* As above, senders might quantize, and if some standard quantum becomes popular, the distribution is really a spike around the standard quantum, and there is a massive discontinuity there.
* Coffee or other popular everyday product may settle on a standard price, which again implies a spike around that standard price.
So the reliability of `htlc_max_msat` as a valve is dependent on market forces, and may be as non-linear as feerates, which *are* the sum total of the market force.
Feerates on the other hand are always going to be something that senders optimize for, because obviously senders will have a maximum amount they will be willing to pay in fees (as before, the intuition here is that the maximum fee senders are willing to pay is equivalent to the difference in subjective value between the millisatoshis they are sending and the service/product they are purchasing).
Whatever future sender algorithms are devised, feerates will still work consistently as a valve, whreas `htlc_max_msat` may fail in a future where sender algorihms quantize the payments around some standard quantum for privacy and ease-of-implementation purposes.
Regards,
ZmnSCPxj