pull down to refresh

It was my understanding that intermediate nodes know nothing about the origin or destination of a payment. If so, how is a payment routed? Shouldn't it just be a random walk until you "find" the receiver (and pay a bunch of fees along the way)?
When you initiate a payment, your node is responsible for coming up with a route to the destination. For this, it uses its knowledge of the whole LN graph (which is created based on other nodes telling your node their version of the graph). Then, using this graph, some routing algorithm is used so that the resulting route is (ideally) cheap, has a high probability of success, and minimized certain issues. This route is attempted and, if it reaches the destination, everything is fine.
The intermediate nodes have to follow the route given by your node, as they are unable to decrypt the information they don't need. If my node forwards some amount from node A to node B, I just see the corresponding details, without having access to the information node B is able to access (for example, it could be the final recipient, or continue forwarding to node C).
If not, your node integrates the information about the failure into its data set (for example: node X cannot send amount Y to node Z) and tries again. And, possibly, again after that. Usually, you don't see how many failed attempts it took, but every (failed) attempt increases the total time your payment takes.
It is possible to split a payment into several pieces which take different routes, but arrive at the same time (or not at all). If you want to have a closer look at this, and how this relates to payment success probability, I can highly recommend Rene Pickhardt's research work (#PickhardtPayments).
reply
Thanks!
Are there any known/expected limitations to scalability due to requiring knowledge of the global graph?
reply
I did not know LN us using a graph in order to do routes. Is there any way I could pull this information and map it visually? It would be interesting to see how LN nodes route visually.
reply
lncli describegraph is one way to get a textual representation. If you're not used to this kind of stuff, I'd rather look at existing visualizations, though. One example: https://lnrouter.app/graph
reply
im neither a dev nor lightning expert but my understanding is its something like, right now intermediary nodes know the payment hash so well connected ones can/could potentially figure out whos paying who just because they have such volume
this is the goto resource on lightning privacy: https://lightningprivacy.com/en/routing-analysis
reply
in terms of routing its something like: a route is chosen and then the actual payment is sent onion routed (like tor) where each layer/hop only sees where its come from and the next hop, so only sees the nodeid of next hop, not whole path.
payment doesnt just get shot at random from source to destination. routes are determined based on fees, no. of hops etc
someone with more experience and better skills will come along and explain it better though
reply
Routing payments on LN is quite a big challenge. We at Walletano, have lots of metrics that we use to route payments on the network.
One of these metrics is the average time needed to route a payment starting from any direct channel where we have local liquidity, Check this for example: https://gyazo.com/deadb0084ab1b051e79f3f416816da8f
We usually prioritize nodes that have the lowest avgtime to get the payment confirmation. From the above data, you can see that we preferably use as outgoing channel, the channel with nodes like: Sunny Sarah, ipayblue, lnmarkets and getalby. As soon as these averages are changing, we adjust dynamcally our routes to have the fastest payments.
  • we use lots of other metrics or conditions based on the destination, transaction size, fees, etc.
reply