ZmnSCPxj [ARCHIVE] on Nostr: š
Original date posted:2022-09-22 š Original message: Good morning Dave, > On ...
š
Original date posted:2022-09-22
š Original message:
Good morning Dave,
> 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.
As I understand it, it is exactly the same way that is done currently: the sender optimistically tries a route with a particular feerate, and if that fails, tries another route.
Basically, you can model a rate card as four separate channels between the same two nodes, with different costs each.
If the path at the lowest cost fails, you just try at another route that may have more hops but lower effective cost, or else try the same channel at a higher cost.
If your concern is valid, one wonders why it would not already exist now in the current network where try-and-try-again is the standard overall algorithm for payments.
Regards,
ZmnSCPxj
Published at
2023-06-09 13:06:48Event JSON
{
"id": "24307d3b15a6472bf48528ae79ce663b4a6e8e7bee24b186eed98464c8be5fe8",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686316008,
"kind": 1,
"tags": [
[
"e",
"22c172b2f754f51b85d4accc190f757c33b70ec92a7231b5a5acb8ecf83097c8",
"",
"root"
],
[
"e",
"ba83735176421f2892fe6e80837ebe50606d8994a7e4a5eb1ef0e3df3f260e78",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "š
Original date posted:2022-09-22\nš Original message:\nGood morning Dave,\n\n\u003e On 2022-09-13 11:15, lisa neigut wrote:\n\u003e \n\u003e \u003e Hi all,\n\u003e \n\u003e \n\u003e Hi Lisa,\n\u003e \n\u003e Thank you for describing this idea in detail on the mailing list.\n\u003e \n\u003e \u003e A ratecard is a set of four values, positive or negative, that price\n\u003e \u003e different bands of available liquidity for a channel.\n\u003e \n\u003e \n\u003e Am I understanding correctly that this implies spenders wanting to send\n\u003e an LN payment will either need to estimate the current division of funds\n\u003e for every hop along their projected path or will need to pay the highest\n\u003e ratecard for each hop? How are spenders supposed to make those\n\u003e estimates about the division of funds in distant channels?\n\u003e \n\u003e If there's no easy and network-friendly way for spenders to gather that\n\u003e information, I would worry that will lead to the creation of services\n\u003e which do collect the info and which become central to LN's operation.\n\nAs I understand it, it is exactly the same way that is done currently: the sender optimistically tries a route with a particular feerate, and if that fails, tries another route.\n\nBasically, you can model a rate card as four separate channels between the same two nodes, with different costs each.\nIf the path at the lowest cost fails, you just try at another route that may have more hops but lower effective cost, or else try the same channel at a higher cost.\n\nIf your concern is valid, one wonders why it would not already exist now in the current network where try-and-try-again is the standard overall algorithm for payments.\n\nRegards,\nZmnSCPxj",
"sig": "709d5f248ea687f21f07b04fd990cd0addf0041be3b2c16c4bdaca2365b98e85bd69b6997a50ecc0c7e44209ad1eb7886d34acf04f7a9d09c63aaa1d8f4dc3d1"
}