From ZmnSCPxj at protonmail.com Mon Sep 26 00:29:24 2022 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 26 Sep 2022 00:29:24 +0000 Subject: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network In-Reply-To: References: Message-ID: 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