rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 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