6

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

Murch
  • 71,155
  • 33
  • 180
  • 600
Questioner
  • 1,151
  • 8
  • 22

1 Answers1

9

There's no document explaining step-by-step, because the routing decisions are not part of the protocol (the BOLTs). It is purely client-side decision making about how to find a route through the graph, and any client can choose to implement their own mechanisms. There is no compatibility issues because only the payer makes routing decisions, and intermediate hops merely forward packets as requested.

If you wish to know the specific details of how LND, c-lightning etc implement it, you will need to dig into the code and documentation for those projects.

As far as I'm aware, the current implementations all use a variant of Dijstra's algorithm, or A*, taking the routing fees as the heuristic to minimize when calculating the weights of each path, and c-lightning uses the Bellman-Ford modification in the link above.

Once a path has been calculated by the payer, there is a standard process by which the path and the packets for it are constructed, defined in BOLT#4.

Mark H
  • 3,304
  • 2
  • 7
  • 14
  • 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 Dec 19 '18 at 10:03
  • Btw, do you agree with **7th** comment in this answer ([HERE](https://bitcoin.stackexchange.com/questions/81895/implementing-an-ad-hoc-like-network-of-payment-channels-on-top-of-bitcoin-netw)) 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 Dec 19 '18 at 13:24
  • Flare 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 Dec 19 '18 at 20:20
  • 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 Dec 20 '18 at 09:55
  • 2
    The 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 Dec 20 '18 at 14:51
  • 1
    Flare 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 Dec 20 '18 at 14:56
  • 2
    IMO, 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 Dec 20 '18 at 14:57
  • 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 Dec 20 '18 at 15:54
  • 1
    (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 Dec 20 '18 at 16:10
  • Thank you very much. so, waiting for your useful feedback on that paper. Thanks again. – Questioner Dec 21 '18 at 09:56
  • ,Hi, this article: [LINK](https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800) claims LN using **hubs** works centrally and in another article claims centralized hubs lead to economic censorship ([LINK](https://www.yours.org/content/clarifying-my-objections-to-the-lightning-network-2f9d3aa154e5)) Do you think this ant routing approach can be an efficient decentralized solution? ([Ant routing](https://arxiv.org/abs/1807.00151)) Or may I need to bring up this as a new question? Thank you – Questioner Jan 14 '19 at 15:20