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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
