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