From aj at erisian.com.au Sat Sep 24 09:01:59 2022 From: aj at erisian.com.au (Anthony Towns) Date: Sat, 24 Sep 2022 19:01:59 +1000 Subject: [Lightning-dev] Fee Ratecards (your gateway to negativity) In-Reply-To: References: <8a5b29bf105ea2187b55daa8a74d7101@dtrt.org> <391a9c57e4f34962920c0348cbf85cef@dtrt.org> Message-ID: On Fri, Sep 23, 2022 at 03:13:53PM -0500, lisa neigut wrote: > Some interesting points here. Will try to respond to some of them. > > pathfinding algorithms which depend on unscalable data collection > Failed payment attempts are indistinguishable from data collection probing. Even so, data collection probing is *preferable* -- it can happen out of band, and doesn't need to cause latency when you're trying to finish paying for your coffee so you can sit down and get back to doomscrolling. In general: if you need to know channel capacities to efficiently make payments, doesn't that fundamentally mean that that information should be gossipped? For instance, in a world where everyone's doing rate cards, maybe every channel is advertising fees at -0.05, +0.01, +0.1, +1.0 bps because that's just what turns out to be "best". But then when you're trying to find a route, it becomes critically important to know which channels are at which capacity quartile. If you're not gossipping that information, then someone making a payment needs to either probe every plausible path, or subscribe to an information provider that is regularly probing every channel. I still think what I wrote in June applies; from [0], what you want to maintain is a balanced flow over time, not any particular channel balance -- so collecting less fees at 25% balance than at 75% balance is generally a false optimisation; and from [1], having fee rate cards that just depend on time of day/week is probably a much better method of optimising for what actually matters -- "these are the times my channel is in high demand in this direction, so fees are high; these are the times demand is low, so fees are low". [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003624.html [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003627.html > I like to think that the introduction of negative fees make channel > balance data a competitive advantage and will actually cause node > operators to more closely guard their balances / the balance data > they've collected about peers, which should hopefully reduce the current > trend of sharing this information with centralized parties. Having fees depend on the channel balance makes the data a competitive advantage to the people trying to use the channel; for the channel owner, the optimal situation is everyone knows the balance, so that more payments get routed over the channel (because people don't overestimate the fee rate). That encourages channel owners to broadcast the information, not keep it private. If they can't broadcast it, that just creates a market for centralised information brokers... Cheers, aj