Routing on Lightning is an optimization problem with continuous development, developers do not only aim to reduce the computational costs and increase the privacy, they also mean to delegate route computations to other nodes in a trustless manner, lets take a look at layer 1 for an example.

Full nodes are nodes that verify transactions themselves, they hold the entire blockchain and the UTXO set which makes them able to verify any transaction based on a defined consensus and the history of the transaction inputs. On the other hand lite clients use methods such as SPV to verify the existence of a transaction in a block without downloading the block itself, they rely on other full nodes to make that CPU/Memory heavy operation for them.

The way Lightning currently works is that the sender calculates the route from its node to the receiver’s node, this means that the sender’s node must have an updated network of nodes, it might not be connected to the receiver directly but it is connected through a path in the network.

This might be fine for Lightning in its current state, but it won’t be if the number of channels expand into the millions due to adoption. Trampoline payments is a new suggested way of outsourcing that aims at having lite clients outsourcing the route computation to trampoline nodes, nodes of higher Memory, bandwidth and computation power.

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.

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?