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?

In the current spec each node shares its view of the entire graph with other nodes, so every node has a local view to the network that it uses to create the most efficient path between itself and the receiving node. No intermediate node is needed to make a decision or to keep routing tables: the entire route is found by the payer.

The node knows for a fact that these exist as every channel has a 2-of-2 UTXO backing it (funding transaction on the Blockchain), a sort of “poof-of-channel-existence”. These channels cannot be spammed (faked) unless the spammers are willing to commit money. Any UTXO that is invalid or already spent means the node will just ignore this channel and search for another efficient route. The current spec is simple but relies on the node having a full view of the network, which in the future might be a problem for mobile nodes like Eclair.

An other architectural choice was self-addressing packets. These work by having each node receiving packets and checking if they belong to it by looking into destination lookup table, if not then it just forwards the packet to any of its adjacent peers. This could have been coupled with a forwarding fee that rewards the accuracy of the forwarding. In the end this solution was not implemented for privacy reasons as it reveals the destination, compared to the current onion routing method used.

• Discussion