What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-09 13:06:52
in reply to nevent1q…pc9y

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-25 📝 Original message: Good morning aj, and ...

📅 Original date posted:2022-09-25
📝 Original message:
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.

Regards,
ZmnSCPxj
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l