David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-22 📝 Original message: On 2022-09-13 11:15, lisa ...
📅 Original date posted:2022-09-22
📝 Original message:
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
📝 Original message:
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