Pinging a route for capacity

Summary:

A new participant, Rene, in the Lightning Dev community, has proposed an idea to solve a problem posed by Jim Posen. Rene suggested using IP-Fragmentation techniques, as it involves splitting the IP-package to utilize a link layer protocol that doesn't have sufficient bandwidth for a bigger size package. In the case of Lightning network, if the capacity of a channel during routing is not high enough, then one would have to send the second part of the fragmented package on a different route. Rene also suggested that encapsulating the second part of the fragmented payment in a new onion routed package could avoid becoming a problem for onion routing, where the router does not know the final destination but only knows the next hop which can't be utilized as the channel doesn't have enough funds. Rene's proposed method of fragmentation is highly dynamic and still works if a channel runs out of funds while routing payment. In comparison to Jim Posen's proposed ping method, Rene's method seems advantageous, as it could very well happen that a pinged route looks great, and everything appears fine until a channel on that way runs dry.Jim Posen's proposal was to determine all possible routes, rank them by estimated fees based on channel announcements and number of hops, then try them successively until one works. However, Jim thinks that this strategy is not efficient, as a full HTLC commitment handshake on each hop is required just to find out that the last hop in the route didn't have sufficient remaining capacity. Jim suggested sending a ping over an onion route asking "does every hop have capacity to send X msat?" Every hop would forward the onion request if the answer is yes, or immediately send the response back up the circuit if the answer is no. This should reveal no additional information about the channel capacities that the sender couldn't determine by sending a test payment to themselves. Hops could also respond with the latest fee rate in case channel updates are slow to propagate. The benefit of Jim's proposal is that it should make it quicker to send a successful payment because latency is lower than sending an actual payment, and the sender could ping all possible routes in parallel. However, the downside is that it is faster and cheaper for someone to extract information about channel capacities on the network with a binary search.

Updated on: 2023-05-24T21:25:38.642855+00:00