<p>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.</p>

<p>If you wish to know the specific details of how <a href="https://github.com/lightningnetwork/lnd/blob/master/routing/pathfind.go" rel="noreferrer">LND</a>, <a href="https://medium.com/@rusty_lightning/routing-dijkstra-bellman-ford-and-bfg-7715840f004" rel="noreferrer">c-lightning</a> etc implement it, you will need to dig into the code and documentation for those projects.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2018-12-19T10:03:36.220Z
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
CC BY-SA 4.0
2018-12-19T13:24:39.883Z
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
CC BY-SA 4.0
2018-12-19T20:20:48.540Z
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
CC BY-SA 4.0
2018-12-20T09:55:37.150Z
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
CC BY-SA 4.0
2018-12-20T14:51:52.023Z
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
CC BY-SA 4.0
2018-12-20T14:56:08.540Z
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
CC BY-SA 4.0
2018-12-20T14:57:50.443Z
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
CC BY-SA 4.0
2018-12-20T15:54:33.720Z
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
CC BY-SA 4.0
2018-12-20T16:10:13.880Z
(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
CC BY-SA 4.0
2018-12-21T09:56:19.817Z
Thank you very much. so, waiting for your useful feedback on that paper. Thanks again.
Questioner
CC BY-SA 4.0
2019-01-14T15:20:55.503Z
,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
CC BY-SA 4.0
2018-12-18T23:06:43.273Z
2018-12-18T23:11:53.410Z
2018-12-18T23:11:53.410Z
Mark H
<p>Here is all we can find in the <a href="https://www.bitcoinlightning.com/wp-content/uploads/2018/03/lightning-network-paper.pdf" rel="nofollow noreferrer">Lightning Network whitepaper</a> about payment routing process that it is completely unclear to me (at least it is not enough to know <strong>what happens exactly</strong> at time of finding the <strong>best optimized path for a payment between two users</strong>):</p>

<blockquote>
  <p>"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."</p>
</blockquote>

<p>I am looking for a document explaining <strong>step by step</strong> the <strong>current</strong> routing process used in current Lightning Network to know the <strong>steps</strong> for finding the <strong>best optimized path</strong> when user <strong>A</strong> wants to send an off-chain payment to user <strong>B</strong>. </p>

<p><strong>P.S.</strong> I know that it is possible to use any other routing algorithm as a <strong>plug-in</strong>; however, I would like to know the <strong>current</strong> routing protocol used in the <strong>current</strong> Lightning Network <strong>in details (step by step)</strong>. I also appreciate it if you could <strong>propose a document</strong> explaining the <strong>current</strong> routing algorithm in Lightning Network. Thank you </p>

<lightning-network><lightning-routing>
Routing in Bitcoin Lightning Network
Questioner
# Routing in Bitcoin Lightning Network

(Asked by: username_0 on 2018-12-18)

Here is all we can find in the [Lightning Network whitepaper](https://www.bitcoinlightning.com/wp-content/uploads/2018/03/lightning-network-paper.pdf) 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

**Tags:** lightning-network, lightning-routing


---

## 1 answers

### Answer by username_1 on 2018-12-18. Score: 9 | Accepted answer

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](https://github.com/lightningnetwork/lnd/blob/master/routing/pathfind.go), [c-lightning](https://medium.com/@rusty_lightning/routing-dijkstra-bellman-ford-and-bfg-7715840f004) 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.

> **Comments:**
> **username_0**: 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  
> **username_0**: 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.  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_1**: 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.  
> **username_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.  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_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.  
> **username_0**: Thank you very much. so, waiting for your useful feedback on that paper. Thanks again.  
> **username_0**: ,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  

---

