4
1
Here is all we can find in the Lightning Network whitepaper about payment routing process that it is completely unclear to me (at least it is not enough to know what happens exactly at time of finding the best optimized path for a payment between two users):
"It is theoretically possible to build a route map implicitly from observing 2-of-2 multisigs on the blockchain to build a routing table. Note, however, this is not feasible with pay-to-script-hash transaction outputs, which can be resolved out-of-band from the bitcoin protocol via a third party routing service. Building a routing table will become necessary for large operators (e.g. BGP, Cjdns). Eventually, with optimizations, the network will look a lot like the correspondent banking network, or Tier-1 ISPs. Similar to how packets still reach their destination on your home network connection, not all participants need to have a full routing table. The core Tier-1 routes can be online all the time —while nodes at the edges, such as average users, would be connected intermittently. Node discovery can occur along the edges by pre-selecting and offering partial routes to well-known nodes."
I am looking for a document explaining step by step the current routing process used in current Lightning Network to know the steps for finding the best optimized path when user A wants to send an off-chain payment to user B.
P.S. I know that it is possible to use any other routing algorithm as a plug-in; however, I would like to know the current routing protocol used in the current Lightning Network in details (step by step). I also appreciate it if you could propose a document explaining the current routing algorithm in Lightning Network. Thank you
And do you know if this approach has been already used/implemented in Lightning Network? (https://bitfury.com/content/downloads/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf) Thank you
– Questioner – 2018-12-19T10:03:36.220Btw, do you agree with 7th comment in this answer (HERE) where user Jannes says "intermediary hops do not know the source and destination so they can't censor" ? And if so, how an intermediary node is able to find the best rout for a destination that they do not know ? Thank you.
– Questioner – 2018-12-19T13:24:39.883Flare is not used. Currently, no intermediary nodes make routing choices. The payee makes all of the routing decisions in the current protocol and implementations. The payee encrypts the information for each node using their public key, and there is a deterministic way of constructing packets which are always the same size, such that a node does not know which position it is in a path. The only nodes which know are the payer and the payee. – Mark H – 2018-12-19T20:20:48.540
Thank you , So in this case why routing protocols such as Flare has been proposed? What problem does Flare want to solve? And in general, what is problem of the approach you explained in which only payer and payee know the position of the path? Is there any flaw/drawback in the approach you explained? Thanks again. – Questioner – 2018-12-20T09:55:37.150
2The primary issue with source based routing is that the payee needs a full copy of the routing table, or needs to query information about channels and nodes from somebody who does have it, which leaks information and is bad for privacy. While the network is small with limited growth, this isn't really a problem because the routing information is only a few MB. When we start to get node counts in millions and channel counts of billions, it is obviously not going to be practical for each node to have a fully copy of the routing information, and nor will they have the bandwidth to transfer it. – Mark H – 2018-12-20T14:51:52.023
1Flare has possible issues w.r.t privacy, and it also treats some nodes as a kind of "privileged" node. People involved in the LN development wish to avoid this and are therefore not likely to make a rash decision to implement something like Flare, which would be premature optimisation. – Mark H – 2018-12-20T14:56:08.540
1IMO, a more reasonable solution to scaling routing would be to use something like a DHT, where nodes keep local routing information, where local is information about node public keys (or hashes of) who are lexically close to their own node. – Mark H – 2018-12-20T14:57:50.443
Thank you very much. Just (1) what do you mean by "MB"? ("routing information is only a few MB") (2) could you please propose a document/article/example explaining w.r.t privacy issues in more detail? And (3) Do you have any feedback on this approach (it is based on Ant routing) ? (https://arxiv.org/abs/1807.00151) Thank you very much again.
– Questioner – 2018-12-20T15:54:33.7201(1) I meant MiB (megabytes). Nodes need to store the full signed gossip messages for nodes, channels and channel_updates (2 per channel) in order to forward them on to other peers. This information also needs refreshing every 2 weeks. (2) Flare proposes a hub and spoke network, which means "hubs" are effectively privileged nodes and spokes are less privileged, and also less fault tolerant because they depend on hubs to route for them. (3) I've not read the paper yet, I'll have to get back to you on that one. – Mark H – 2018-12-20T16:10:13.880
Thank you very much. so, waiting for your useful feedback on that paper. Thanks again. – Questioner – 2018-12-21T09:56:19.817
,Hi, this article: LINK claims LN using hubs works centrally and in another article claims centralized hubs lead to economic censorship (LINK) Do you think this ant routing approach can be an efficient decentralized solution? (Ant routing) Or may I need to bring up this as a new question? Thank you
– Questioner – 2019-01-14T15:20:55.503