Good morning Joseph,

> I root for the Lightening Network’s success, but it seems to have an inherent 
> weakness. 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?
> I don’t think any solution to the mesh network routing problem has been 
> found. What am I missing here? Thanks.

The current spec has each participant share their views of the entire graph 
with each other.  The payer uses its own local view of the entire network to 
create a route from payer to payee.  None of the intermediate nodes need to 
make any decisions or keep routing tables: the entire route has been found by 
the payer in the first place.  No guesswork is necessary: either you know of a 
route and can provide it entirely (so intermediate nodes never have to guess) 
or you know of no route and are unable to pay.

The existence of channels has a simple proof: every channel is backed by a 
2-of-2 multisig UTXO.  When sharing views of network graph, each channel in the 
view includes a reference to the UTXO backing it.  To show that the channels 
are indeed Lightning channels, a signature matching the 2-of-2 multisig is 
required.  The proof-of-channel-existence is thus the reference to the UTXO, 
plus a signature signing that reference.  If a node receives a supposed channel 
from a peer, but the UTXO does not exist or is already spent, then the node 
ignores that channel and does not add it to its local network view..  It is 
thus not possible to fake a channel (to spam the network views of Lightning 
peers) without actually committing money into some UTXO, which deters spam.

The solution currently in use is simple and direct, at the cost that each node 
has to keep a view of the entire network.  The so-called "Lightning Network 
scaling problem" is largely a problem of these local network views becoming too 
large for low-end devices to keep; perhaps the Eclair developers should chime 
in at this point, since they target mobile devices and may be able to give a 
perspective on whether the network map is too large for mobile devices already.


The mesh network routing problem in general can be solved by self-addressing 
packets (like IP (the Internet) uses).

When a node receives a packet that is not addressed to it, it looks up the 
destination address in its routing table. If it does not exist in the routing 
table, then the node simply throws it to some other peer, which at least is 

Similarly, a "payment packet" can offer a forwarding fee and the payment.  When 
a node receives it, it could deduct some part of the fee for itself and attempt 
to forward it to one of its other peers.  The more accurately it can forward 
the payment, the more likely it can earn from the forwarding fees (if the 
payment fails to reach the destination then the node cannot earn fee).  Even a 
simple "try all your peers" approach would in aggregate result in a 
breadth-first search of the network graph, so if it is reachable then the 
payment will indeed get forwarded.  The drawback is that it reveals the 
destination of the payment, which is why Lightning went with onion routing.

Lightning-dev mailing list

Reply via email to