š
Original date posted:2022-09-23
š Original message:
On 2022-09-22 16:08, ZmnSCPxj wrote:
> 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.
That's a very easy to understand explanation of how to use the system,
thanks!
> 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.
My concern is about pathfinding algorithms which depend on unscalable
data collection (e.g. frequent whole network probing). If such an
algorithm performs much better than those algorithms which depend on
scalable data collection (e.g. receiving gossip), then the network may
grow to depend on the centralized entities performing the data
collection to the detriment of its robustness and its participants'
independence.
Try-and-try-another-path is somewhat problematic in this regard since,
even with no additional action like probing, entities which send many
payments will likely perform significantly better than entities which
send few payments owing to the high-frequency spenders gaining more
knowledge about which channels and amounts recently worked or did not.
It seems to me that a more idealized system would only rarely have
forwarding failures so that high frequency spenders wouldn't receive
much more information than low frequency spenders. To that regard, fee
ratecards feels like a small step in the wrong direction because
modeling one channel as four separate channels further normalizes
failure and so further moves the system towards centralized dependency.
That said, as you mentioned in a previous post[1], I agree ratecards is
better than frequently issuing new channel updates with modified fees.
Thanks,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-09 13:06:49
in reply to nevent1qā¦4lgh
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 13:06:49Event JSON
{
"id": "4a3a2af97bae3b09dd7643f6fbe666d597a7880bb01c1283c4f2f22e86492af8",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686316009,
"kind": 1,
"tags": [
[
"e",
"22c172b2f754f51b85d4accc190f757c33b70ec92a7231b5a5acb8ecf83097c8",
"",
"root"
],
[
"e",
"24307d3b15a6472bf48528ae79ce663b4a6e8e7bee24b186eed98464c8be5fe8",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2022-09-23\nš Original message:\nOn 2022-09-22 16:08, ZmnSCPxj wrote:\n\u003e Basically, you can model a rate card as four separate channels between\n\u003e the same two nodes, with different costs each.\n\u003e If the path at the lowest cost fails, you just try at another route\n\u003e that may have more hops but lower effective cost, or else try the same\n\u003e channel at a higher cost.\n\nThat's a very easy to understand explanation of how to use the system, \nthanks!\n\n\u003e If your concern is valid, one wonders why it would not already exist\n\u003e now in the current network where try-and-try-again is the standard\n\u003e overall algorithm for payments.\n\nMy concern is about pathfinding algorithms which depend on unscalable \ndata collection (e.g. frequent whole network probing). If such an \nalgorithm performs much better than those algorithms which depend on \nscalable data collection (e.g. receiving gossip), then the network may \ngrow to depend on the centralized entities performing the data \ncollection to the detriment of its robustness and its participants' \nindependence.\n\nTry-and-try-another-path is somewhat problematic in this regard since, \neven with no additional action like probing, entities which send many \npayments will likely perform significantly better than entities which \nsend few payments owing to the high-frequency spenders gaining more \nknowledge about which channels and amounts recently worked or did not. \nIt seems to me that a more idealized system would only rarely have \nforwarding failures so that high frequency spenders wouldn't receive \nmuch more information than low frequency spenders. To that regard, fee \nratecards feels like a small step in the wrong direction because \nmodeling one channel as four separate channels further normalizes \nfailure and so further moves the system towards centralized dependency. \nThat said, as you mentioned in a previous post[1], I agree ratecards is \nbetter than frequently issuing new channel updates with modified fees.\n\nThanks,\n\n-Dave\n\n[1] \nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html",
"sig": "15d9719297770708d69b80445ab9cd37d894281ad369b990e1b2ac866c36d881d82c60ad30dd3c87a391c4e8e524047c2022a2223f42f8594b65309a4710d4c2"
}