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 progress. 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. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
