Feed for tag: routing
Proposal for rendez-vous routing on Lightning
A proposal on lightning-dev called “rendez-vous” routing, a new routing schema that could increase the privacy of the payee without affecting the payment model, we explore what it is and why it is needed.
Improving payment UX with low-latency route probing

Pending payments are a common UX problem for LN that users often complain about. While the cause of this problem is not easily unraveled, there have been several issues involving stuck intermediate nodes awaiting revocation and recipients who can’t give timely preimage replies.

Fabrice Drouin proposed a change to address the issue using a faster “proceed/try another route” answer using a probe with a short timeout requirement. The system sends the blank probe request prior to sending the actual payment, via the same route.

Lightning Mesh Network

Joseph Hoane raised some concerns regarding the current routing strategy for LN payments which does not rely on any sort of routing table the way mesh networks usually do:

Since routing tables are not part of the architecture how can the sender chose the next recipient so as to effect an efficient path to the ultimate receiver? With no routing table available the next receiver’s connection to the remote ultimate receiver or to the ultimate receiver’s proximate connections is unknown. Even a powerful bridge node will not know an efficient subsequent path and could send the message on in exactly the most inefficient direction. How does choosing an efficient next intermediate receiver not remain a guess, a shot in the dark?

On the discussion that followed ZmnSCPxj provided an explanation for the reasoning behind the current “simple and direct” payment routing strategy.

Lightning payments are forwarded through a network of payment channels between users, but how does every node know where to send its payments?