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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to