Progress pill
A Liquidity Network

Finding Your Way

Lightning Network Theory

Finding Your Way

  • The Problem of Routing in Lightning
  • Network Map Update
  • Routing a Payment
  • Payment Execution
In the previous chapters, we saw how to use other nodes' channels to route payments and reach a node without being directly connected to it via a channel. We also discussed how to ensure the security of the transfer without trusting the intermediary nodes. In this chapter, we focus on finding the optimal route to reach a target node.

The Problem of Routing in Lightning

As we have seen, in Lightning, it is the payment-sending node that must calculate the complete route to the recipient, because we use an onion routing system. The intermediary nodes are unaware of either the point of origin or the final destination. They only know where the payment originates and to which node it must be transferred next. This means that the sending node must maintain a dynamic local topology of the network, including existing Lightning nodes and the channels between them, taking into account openings, closures, and state updates.
Even with this topology of the Lightning Network, essential information for routing remains inaccessible to the sending node, specifically the exact distribution of liquidity in the channels at any given moment. Indeed, each channel only displays its total capacity, but the internal distribution of funds is known only to the two participating nodes. This poses challenges for efficient routing, as the success of the payment depends notably on whether its amount is less than the lowest liquidity on the chosen route. However, the liquidity is not all visible to the sending node.

Network Map Update

To keep their network map up to date, nodes regularly exchange messages through an algorithm called "gossip". This is a distributed algorithm used to disseminate information in an epidemic manner to all nodes in the network, enabling the exchange and synchronization of the global state of the channels within a few communication cycles. Each node propagates information to one or more neighbors, chosen at random or not; these, in turn, propagate the information to other neighbors, and so on, until a globally synchronized state is achieved.
The 2 main messages exchanged between Lightning nodes are as follows:
  • "Channel Announcements": messages signaling the opening of a new channel.
  • "Channel Updates": update messages on the state of a channel, particularly on the evolution of fees (but not on the distribution of liquidity).
Lightning nodes also monitor the Bitcoin blockchain to detect transactions that close channels. The closed channel is then removed from the map since it can no longer be used to route our payments.

Routing a Payment

Let's take an example of a small Lightning Network with 7 nodes: Alice, Bob, 1, 2, 3, 4, and 5. Imagine that Alice wants to send a payment to Bob, but must go through intermediary nodes.
Here is the actual distribution of funds in these channels:
  • Channel between Alice and 1: 250,000 sats on Alice's side, 80,000 on 1's side (total capacity of 330,000 sats).
  • Channel between 1 and 2: 300,000 sats on 1's side, 200,000 on 2's side (total capacity of 500,000 sats).
  • Channel between 2 and 3: 50,000 sats on 2's side, 60,000 on 3's side (total capacity of 110,000 sats).
  • Channel between 2 and 5: 90,000 sats on side 2, 160,000 on side 5 (total capacity of 250,000 sats).
  • Channel between 2 and 4: 180,000 sats on side 2, 110,000 on side 4 (total capacity of 290,000 sats).
  • Channel between 4 and 5: 200,000 sats on side 4, 10,000 on side 5 (total capacity of 210,000 sats).
  • Channel between 3 and Bob: 50,000 sats on side 3, 250,000 on side Bob (total capacity of 300,000 sats).
  • Channel between 5 and Bob: 260,000 sats on side 5, 100,000 on side Bob (total capacity of 360,000 sats).
To make a payment of 100,000 sats from Alice to Bob, the routing options are limited by the available liquidity in each channel. The optimal route for Alice, based on the known liquidity distributions, could be the sequence Alice → 1 → 2 → 4 → 5 → Bob:
But since Alice does not know the exact distribution of funds in each channel, she must estimate the optimal route probabilistically, taking into account the following criteria:
  • Probability of success: A channel with a higher total capacity is more likely to contain sufficient liquidity. For example, the channel between node 2 and node 3 has a total capacity of 110,000 sats, so it is unlikely to find 100,000 sats or more on the side of node 2, although it remains possible.
  • Transaction fees: In choosing the best route, the sending node also considers the fees applied by each intermediate node and seeks to minimize the total routing cost.
  • Expiration of HTLCs: To avoid blocked payments, the expiration time of HTLCs is also a parameter to consider.
  • Number of intermediate nodes: Finally, more broadly, the sending node will seek to find a route with the fewest possible nodes to reduce the risk of failure and limit Lightning transaction fees.
By analyzing these criteria, the sending node can test the most probable routes and attempt to optimize them. In our example, Alice could rank the best routes as follows:
  • Alice → 1 → 2 → 5 → Bob, because it's the shortest route with the highest capacity.
  • Alice → 1 → 2 → 4 → 5 → Bob, because this route offers good capacities, although it is longer than the first.
  • Alice → 1 → 2 → 3 → Bob, because this route includes the channel 2 → 3, which has very limited capacity, but remains potentially usable.

Payment Execution

Alice decides to test her first route (Alice → 1 → 2 → 5 → Bob). She therefore sends an HTLC of 100,000 sats to node 1. This node verifies that it has sufficient liquidity with node 2 and then continues the transmission. Node 2 then receives the HTLC from Node 1 but realizes it does not have enough liquidity in its channel with Node 5 to route a payment of 100,000 sats. It then sends an error message back to node 1, which transmits it to Alice. This route has failed.
Alice then attempts to route her payment using her second route (Alice → 1 → 2 → 4 → 5 → Bob). She sends an HTLC of 100,000 sats to node 1, who then transmits it to node 2, and so on, to node 5, and finally to Bob. This time, the liquidity is sufficient, and the route is functional. Each node unlocks its HTLC in cascade using the preimage provided by Bob (the secret s), which allows Alice's payment to Bob to be successfully finalized.
The search for a route is conducted as follows: the sending node starts by identifying the best possible routes, then attempts payments successively until a functional route is found.
It's worth noting that Bob can provide Alice with information in the invoice to facilitate routing. For example, he can indicate nearby channels with sufficient liquidity or reveal the existence of private channels. These indications enable Alice to avoid routes with little chance of success and to attempt the recommended paths first.
What should you take away from this chapter?
  • Nodes maintain a map of the network topology through announcements and by monitoring channel closures on the Bitcoin blockchain.
  • The search for an optimal route for a payment remains probabilistic and depends on many criteria.
  • Bob can provide indications in the invoice to guide Alice's routing and save her from testing unlikely routes.
In the following chapter, we will specifically study the functioning of invoices, as well as other tools used on the Lightning Network.
Quiz
Quiz1/5
Why is it difficult for a transmitting node to estimate the exact liquidity of a channel?