From dave at dtrt.org Fri Sep 23 01:11:18 2022 From: dave at dtrt.org (David A. Harding) Date: Thu, 22 Sep 2022 15:11:18 -1000 Subject: [Lightning-dev] Fee Ratecards (your gateway to negativity) In-Reply-To: References: Message-ID: <8a5b29bf105ea2187b55daa8a74d7101@dtrt.org> On 2022-09-13 11:15, lisa neigut wrote: > Hi all, Hi Lisa, Thank you for describing this idea in detail on the mailing list. > A ratecard is a set of four values, positive or negative, that price > different bands of available liquidity for a channel. Am I understanding correctly that this implies spenders wanting to send an LN payment will either need to estimate the current division of funds for every hop along their projected path or will need to pay the highest ratecard for each hop? How are spenders supposed to make those estimates about the division of funds in distant channels? If there's no easy and network-friendly way for spenders to gather that information, I would worry that will lead to the creation of services which do collect the info and which become central to LN's operation. > For example, if a payment moves 50k through a 100k channel which is > currently at a total available capacity of 75k sats (which means it'll > move the > capacity from 75k to 25k), that payment will be expected to pay a rate > equal to > the 0-25% band, as it'll push the available capacity into the 0-25% > range. Shouldn't this be pro rata? If it's not expected to be proportional at the protocol level, then spender Alice can still get almost proportional rates by sequentially sending Bob's forwarding node fifty 1k payments and have 24 of them pay the 51-75 rate, 25 pay the 26-50 rate, and only 1 pay the 0-25 rate. Since base fees are disallowed, this costs Alice nothing extra but reduces network capacity by consuming HTLC slots for her, Bob, and every other forwarding channel. However, for Alice to pay proportional fees either way, she'd need a fairly precise estimate of the current division of funds in one of Bob's channels, which brings me back to my earlier question about how Alice is supposed to obtain that information in a way that's easy and friendly to the network (and therefore resistant to centralization). Thanks, -Dave