How are Lightning Network transactions routed?

[cupronickel]

The white paper sketches out the concept but it isn't clear how the routing happens in practise on a wider scale. How is the actual route formed? Are there going to be routing tables? How will they be created and how are the multiple payment channels associated?

[1713551373]

1713551373

[1713551373]

1713551373

[1713551373]

1713551373

[gentlemand]

I'd love to know more about too. It's kind of the make or break mystery about it all. If they're not fluid and capable of being rerouted that makes them an order of magnitude clunkier.

There must be a few people here who have a good grasp of it. I'm definitely not one of them. Can anyone chime in?

[pebwindkraft]

maybe here: http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf

Chapter 3:

Proposed Hybrid Routing Algorithm
As a way to satisfy the requirements listed in Section 1, we define a hybrid routing algorithm, which we call Flare, consisting of proactive and reactive stages. The idea behind this approach is that the state of LN can be split into two distinct parts:
• slowly changing, or static, information (payment channels between nodes)
• quickly changing, or dynamic, information (status of nodes, distribution of funds within pay- ment channels, fees for using a channel, etc.)

and then follows a long text on routing possibilities. If you are familiar with the way how networks in the IP world work, you find it quite easy to read, otherwise there'll be a learning curve :-)
I think I read somehwere a comparison to border gateway protocols, but couldn't find it right now...

[Andre_Goldman]

maybe here: http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf

Chapter 3:

Proposed Hybrid Routing Algorithm
As a way to satisfy the requirements listed in Section 1, we define a hybrid routing algorithm, which we call Flare, consisting of proactive and reactive stages. The idea behind this approach is that the state of LN can be split into two distinct parts:
• slowly changing, or static, information (payment channels between nodes)
• quickly changing, or dynamic, information (status of nodes, distribution of funds within pay- ment channels, fees for using a channel, etc.)

and then follows a long text on routing possibilities. If you are familiar with the way how networks in the IP world work, you find it quite easy to read, otherwise there'll be a learning curve :-)
I think I read somehwere a comparison to border gateway protocols, but couldn't find it right now...

Wow, nice paper, suddenly LN became very interesting to me .. 

LN could resemble a mobile ad hoc network (MANET)

Is there any simulation of it (for instance using kernel-level network stack virtualization such as http://imunes.net/ ) or maybe a discreve event simulation on NS2, Opnet etc ?

[HALLASTERA]

I have too many questions about LN. I've read manuals but they all have a political character.
LN may change decentralization to centralization at least little?

[Colorblind]

I'd love to know more about too. It's kind of the make or break mystery about it all. If they're not fluid and capable of being rerouted that makes them an order of magnitude clunkier.

There must be a few people here who have a good grasp of it. I'm definitely not one of them. Can anyone chime in?

Also there is another problem with routing, that makes some routes impossible. For example if certain node have low balance, it can not become an intermediate (because it can't deduct enough funds to push it forward simply because it have none). So there should be constantly updating sheet somewhere that stores current balances and provide adequate routing mapping. My thoughts Lightning network should more look like a star (or constellation of stars) where most routs go through big money holder/aggregator that serves as a trust-less intermediate for most of the funds.
And it's good idea to open direct channel to such hubs to avoid being capped by your nearest node.