📅 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
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-09 15:06:48
in reply to nevent1q…aws0
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 15:06:48Event JSON
{
"id": "ba83735176421f2892fe6e80837ebe50606d8994a7e4a5eb1ef0e3df3f260e78",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686316008,
"kind": 1,
"tags": [
[
"e",
"22c172b2f754f51b85d4accc190f757c33b70ec92a7231b5a5acb8ecf83097c8",
"",
"root"
],
[
"e",
"13b48994671d8caace29b2047ac5d34a1008f4f0a7b7a1becb02fe6c80ed8997",
"",
"reply"
],
[
"p",
"804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a"
]
],
"content": "📅 Original date posted:2022-09-22\n📝 Original message:\nOn 2022-09-13 11:15, lisa neigut wrote:\n\u003e Hi all,\n\nHi Lisa,\n\nThank you for describing this idea in detail on the mailing list.\n\n\u003e A ratecard is a set of four values, positive or negative, that price\n\u003e different bands of available liquidity for a channel.\n\nAm I understanding correctly that this implies spenders wanting to send \nan LN payment will either need to estimate the current division of funds \nfor every hop along their projected path or will need to pay the highest \nratecard for each hop? How are spenders supposed to make those \nestimates about the division of funds in distant channels?\n\nIf there's no easy and network-friendly way for spenders to gather that \ninformation, I would worry that will lead to the creation of services \nwhich do collect the info and which become central to LN's operation.\n\n\u003e For example, if a payment moves 50k through a 100k channel which is\n\u003e currently at a total available capacity of 75k sats (which means it'll \n\u003e move the\n\u003e capacity from 75k to 25k), that payment will be expected to pay a rate \n\u003e equal to\n\u003e the 0-25% band, as it'll push the available capacity into the 0-25% \n\u003e range.\n\nShouldn't this be pro rata? If it's not expected to be proportional at \nthe protocol level, then spender Alice can still get almost proportional \nrates by sequentially sending Bob's forwarding node fifty 1k payments \nand have 24 of them pay the 51-75 rate, 25 pay the 26-50 rate, and only \n1 pay the 0-25 rate. Since base fees are disallowed, this costs Alice \nnothing extra but reduces network capacity by consuming HTLC slots for \nher, Bob, and every other forwarding channel.\n\nHowever, for Alice to pay proportional fees either way, she'd need a \nfairly precise estimate of the current division of funds in one of Bob's \nchannels, which brings me back to my earlier question about how Alice is \nsupposed to obtain that information in a way that's easy and friendly to \nthe network (and therefore resistant to centralization).\n\nThanks,\n\n-Dave",
"sig": "db59bc135947cbfc7519c707bc46cb5cfc9a4fdbd888d36aad5b389f604d3bbc6cbdaf5be88464399f609dfdca74f526e4de65556cb7ba838584ca45553522ac"
}