Progress pill
A Liquidity Network

Lightning Network

Lightning Network Theory

Lightning Network

  • The Network of Payment Channels
  • Calculation of the Route and Liquidity Limits
  • Routing Fees
  • Onion Routing
In this chapter, we will explore how payments on the Lightning Network can reach a recipient even if they are not directly connected by a payment channel. Lightning is, indeed, a network of payment channels, which allows funds to be sent to a distant node through the channels of other participants. We will explore how payments are routed across the network, how liquidity is transferred between channels, and how transaction fees are calculated.

The Network of Payment Channels

On the Lightning Network, a transaction corresponds to a transfer of funds between two nodes. As seen in previous chapters, it is necessary to open a channel with someone to perform Lightning transactions. This channel allows for an almost infinite number of off-chain transactions before it is closed, reclaiming the on-chain balance. However, this method has the disadvantage of requiring a direct channel with the other person to receive or send funds, which implies an opening transaction and a closing transaction for each channel. If I plan to make a large number of payments with this person, opening and closing a channel becomes cost-effective. Conversely, if I only need to perform a few Lightning transactions, opening a direct channel is not advantageous, as it would incur two on-chain transactions for a limited number of off-chain transactions. This case might occur, for example, when wanting to pay with Lightning at a merchant without planning to return.
To solve this problem, the Lightning Network enables routing a payment through several channels and intermediary nodes, thus allowing for a transaction without a direct channel with the other person.
For example, imagine that:
  • Alice (in orange) has a channel with Suzie (in gray) with 100,000 satoshis on her side and 30,000 satoshis on Suzie's side.
  • Suzie has a channel with Bob in which she owns 250,000 satoshis and where Bob has no satoshis.
If Alice wants to send funds to Bob without establishing a direct channel with him, she will need to go through Suzie, and each channel will have to adjust its liquidity accordingly. The sent satoshis remain within their respective channels; they don't actually "cross" the channels, but the transfer is made via an adjustment of the internal liquidity in each channel.
Suppose Alice wants to send 50,000 satoshis to Bob:
  • Alice sends 50,000 satoshis to Suzie in their common channel.
  • Suzie replicates this transfer by sending 50,000 satoshis to Bob in their channel.
Thus, the payment is routed to Bob via a movement of liquidity in each channel. At the end of the operation, Alice ends up with 50,000 sats. She has indeed transferred 50,000 sats since initially, she had 100,000. Bob, on the other hand, ends up with an additional 50,000 sats. For Suzie (the intermediate node), this operation is neutral: initially, she had 30,000 sats in her channel with Alice and 250,000 sats in her channel with Bob, totaling 280,000 sats. After the operation, she holds 80,000 sats in her channel with Alice and 200,000 sats in her channel with Bob, which is the same sum as at the start.
This transfer is thus limited by the available liquidity in the direction of the transfer.

Calculation of the Route and Liquidity Limits

Let's take a theoretical example of another network with:
  • 130,000 satoshis on Alice's side (in orange) in her channel with Suzie (in gray).
  • 90,000 satoshis on Suzie's side and 200,000 satoshis on Carol's side (in pink).
  • 150,000 satoshis on Carol's side and 100,000 satoshis on Bob's side.
The maximum Alice can send to Bob in this configuration is 90,000 satoshis, as she is limited by the smallest liquidity available in the channel from Suzie to Carol. In the opposite direction (from Bob to Alice), no payment is possible because Suzie's side in the channel with Alice contains no satoshis. Therefore, there is no route usable for a transfer in this direction. Alice sends 40,000 satoshis to Bob through the channels:
  • Alice transfers 40,000 satoshis to her channel with Suzie.
  • Suzie transfers 40,000 satoshis to Carol in their shared channel.
  • Carol finally transfers 40,000 satoshis to Bob.
The satoshis sent in each channel remain in the channel, so the satoshis sent by Carol to Bob are not the same as those sent by Alice to Suzie. The transfer is made only by adjusting the liquidity inside each channel. Moreover, the total capacity of the channels remains unchanged.
As in the previous example, after the transaction, the source node (Alice) has 40,000 satoshis less. The intermediate nodes (Suzie and Carol) retain the same total amount, making the operation neutral for them. Finally, the destination node (Bob) receives an additional 40,000 satoshis.
The role of intermediate nodes is therefore crucial in the functioning of the Lightning Network. They facilitate transfers by offering multiple payment options. To encourage these nodes to provide their liquidity and participate in routing payments, routing fees are paid to them.

Routing Fees

The intermediate nodes charge fees to facilitate payments passing through their channels. These fees are set by each node for each channel. The fees consist of 2 elements:
  • "Base fee": a fixed amount per channel, often 1 sat by default, but customizable.
  • "Variable fee": a percentage of the transferred amount, calculated in parts per million (ppm). By default, it is 1 ppm (1 sat per million satoshis transferred), but it can also be adjusted.
The fees also differ depending on the direction of the transfer. For example, for a transfer from Alice to Suzie, Alice's fees apply. Conversely, from Suzie to Alice, Suzie's fees are used.
For example, for a channel between Alice and Suzie, we could have:
  • Alice: base fee of 1 sat and 1 ppm for variable fees.
  • Suzie: base fee of 0.5 sat and 10 ppm for variable fees.
To better understand how fees work, let's study the same Lightning Network as before, but now with the following routing fees:
  • Channel Alice - Suzie: base fee of 1 satoshi and 1 ppm for Alice.
  • Channel Suzie - Carol: base fee of 0 satoshi and 200 ppm for Suzie.
  • Carol - Bob Channel: base fee of 1 satoshi and 1 ppm for Suzie 2.
For the same payment of 40,000 satoshis to Bob, Alice will have to send a little more, as each intermediary node will deduct its fees:
  • Carol deducts 1.04 satoshis on the channel with Bob:
  • Suzie deducts 8 satoshis in fees on the channel with Carol:
The total fees for this payment on this path are therefore 9.04 satoshis. Thus, Alice must send 40,009.04 satoshis for Bob to receive exactly 40,000 satoshis.
The liquidity is therefore updated:

Onion Routing

To route a payment from the sender to the recipient, the Lightning Network uses a method called "onion routing". Unlike the routing of classical data, where each router decides the direction of the data based on its destination, onion routing works differently:
  • The sending node calculates the entire route: Alice, for example, determines that her payment must go through Suzie and Carol before reaching Bob.
  • Each intermediary node knows only its immediate neighbor: Suzie only knows that she received funds from Alice and that she must transfer them to Carol. However, Suzie does not know if Alice is the source node or an intermediary node, and she also does not know if Carol is the recipient node or just another intermediary node. This principle also applies to Carol and all other nodes on the path. Onion routing thus preserves the confidentiality of transactions by masking the identity of the sender and the final recipient. To ensure the transmitting node can calculate a complete route to the recipient in onion routing, it must maintain a network graph to know its topology and determine possible routes. What should you take away from this chapter?
  • On Lightning, payments can be routed between nodes indirectly connected through intermediary channels. Each of these intermediary nodes facilitates the relay of liquidity.
  • Intermediary nodes receive a commission for their service, consisting of fixed and variable fees.
  • Onion routing allows the transmitting node to calculate the complete route without intermediary nodes knowing the source or final destination.
In this chapter, we explored payment routing on the Lightning Network. But a question arises: what prevents intermediary nodes from accepting an incoming payment without forwarding it to the next destination, with the aim of intercepting the transaction? This is precisely the role of HTLCs that we will study in the following chapter.
Quiz
Quiz1/5
How does the Lightning Network allow sending funds to a node that is not directly connected?