Flare: An Approach to Routing in Lightning Network (2016) [pdf](bitfury.com)
bitfury.com
Flare: An Approach to Routing in Lightning Network (2016) [pdf]
http://bitfury.com/content/downloads/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf
5 comments
The TCP and IP protocol specifications do not mention routing either. There are many routing algorithms possible, and many of them are used simultaneously. The same will be true for the lightning network. Lighting has a long way to go, but writing it off as a cute but useless experiment because of current limitations is short sighted.
TCP/IP based networks don't have rapidly changing topographies. A payment channel network's topography changes every time it processes a transaction, because it changes the amounts available for transferring in the channels that transaction was routed through.
I've read a lot about LN routing in the last year, and I still don't get what the plan is. Since it's the responsibility of each client to route its payment, you now put yourself in a situation where each client must know the state of the network - maybe not the whole network, but enough to get to the destination. We didn't even get to the routing, and already this is a huge problem. That O(n^2), and will not scale. How do you expect everyone to know the state of millions of channels, where the state changes thousands of times per second.
Note this is nearly 2 years old already, and the Lightning work is still ongoing. It'd be really interesting to see where this Flare proposal went, and whether there are more routing proposals.
The lightning network is a solution in search of a problem. Every other cryptocurrency has no problem scaling. Btc is artificially limited to 1MB every 10 minutes. Bitcoin cash is upgrading to a 32MB block limit right now. Bigger blocks and multiple chains mean this is essentially not an issue for many years to come, all it takes is not using btc.
How does LN do routing currently? Why does it fail so often?
> It is theoretically possible to build a route map implicitly from observing 2-of-2 multisigs on the blockchain to build a routing table. [...] Node discovery can occur along the edges by pre-selecting and offering partial routes to well-known nodes.
That's it. The word "routing" also only appears once outside of that section.
There are several proposals that all eventually end in "use payment hubs with high liquidity", which are just the equivalent of banks. It doesn't solve any of the problems that the Bitcoin crowd wanted to solve in the first place: Fees will still exist as nobody will altruistically commit thousands of Bitcoin into thousands of LN channels, decentralization is out of the window, and anonymity (or rather pseudonymity) will be easily reversed due to the need for long lasting LN channels to make efficient use of the LN.
All of the above is not even considering that you need to commit a large amount of Bitcoin into LN channels to be able to make use of LN's advantages (not waiting for block confirmations) effectively - which you have to constantly monitor to not lose your channel contents.
LN is an interesting technological experiment but it has no practical uses outside of test environments due to the limitations I laid out above.
1: https://lightning.network/lightning-network-paper.pdf