The Bitcoin protocol has technical limitations. In A previous article, you were able to discover that limiting the interval, as well as limiting the size of the blocks, are compromises that are essential for the proper functioning of Bitcoin.
For users who want to make small payments on a daily basis, these limitations can be annoying. It is not optimal to have to wait for 6 confirmations when paying for coffee for example. In addition, the limitation on block size means that, sometimes, the fees for making a small transaction are too high.
As Bitcoin was adopted, scalability quickly became a central theme. This is the subject that caused the biggest split among Bitcoin users, in 2017, during the “Block Size War”. Part of the community is proposing to increase the block size limit. Another party refuses to panic and offers to make transactions outside the main chain in order to unclog it. This second proposal is the Lightning Network.
What is the Lightning Network?
The Lightning Network is a payment protocol that allows you to send and receive bitcoins without going directly through the main network. It aims to increase the capacity and speed of transactions, with contained fees, while maintaining the original principles of Bitcoin (decentralization, self-custody...).
Lightning is a so-called overlay, or second layer protocol. That is to say, it relies on the basic Bitcoin system, but does not execute all payments there. All Lightning transactions are done off-chain and only the results of these transactions are published on-chain.
Since the transaction capabilities on the basic Bitcoin system are limited by technical compromises, Lightning is trying to provide a solution for scaling up payments. It may be interesting to use it to make micropayments at a lower cost, to benefit from its instant settlement, or even to avoid Bitcoin congestion during periods of high use.
Unlike most altcoins, which have tried to increase their transaction capacity by directly modifying their main networks, the scale-up of Bitcoin is therefore happening off-chain. This makes it possible not to have to compromise on the security and distribution of the core protocol.
The Lightning Network is built around bi-directional payment channels, allowing two parties to send bitcoin from one to the other. Stakeholders are generally referred to as “Lightning nodes” (not to be confused with Bitcoin nodes).
For example, let's say Alice and Bob want to make off-chain payments between them, using the Lightning Network. To do so, they will need to open a payment channel between their Lightning nodes. The opening of a channel is characterized by the deposit of bitcoins on-chain, on a 2/2 multi-signature address. In other words, to spend the bitcoins locked in this address, you need to produce 2 signatures: one with Alice's key, and the other with Bob's key.
If Alice is at the origin of this opening of the channel, she will ask Bob for his public key, then she will build a deposit transaction to block bitcoins on the multi-signature address. She also asks Bob for a signature on a withdrawal transaction in order to eliminate the need for trust in him as much as possible. Once the communications between the protagonists have been made, Alice can broadcast her deposit transaction on the Bitcoin network.
When the transaction is confirmed on-chain, the Lightning payment channel between Alice and Bob is opened. From Lightning's perspective, you can think of this channel as an abacus. Bitcoins can be freely moved to the side belonging to Bob, or to the side belonging to Alice. On the other hand, bitcoins never leave the channel itself.
In our example, let's imagine that Alice was behind the creation of the channel, and that she deposited 500,000 SATS on it. These satoshis are currently on her side of the canal, since she was the one who put them down.
Alice can now send Bitcoin via Lightning to Bob. For example, let's say she sends him 200,000 sats.
As a result of this Lightning transaction, Bob has 200,000 Sats on his side of the channel, and Alice only has 300,000 Sats left. The total capacity of the channel remains the same. There are still 500,000 SATS blocked on-chain on the multi-signature address that have not moved. However, there was a Lightning payment made off-chain.
Bob can now send satoshis to Alice. For example, let's say he sends her 25,000.
The balance of this channel is now 325,000 SATS for Alice, and 175,000 SATS for Bob.
When Alice and Bob no longer need this channel open, they can choose to close it. This closure takes the form of an on-chain transaction, which will spend the bitcoins blocked on the multi-signature address, and which will send them to normal addresses belonging to Alice and Bob. If everything goes normally, this closure should distribute the funds according to the latest state of the channel.
Using our example again, Alice has a balance of 325,000 sats in the Lightning channel and Bob has 175,000 sats. The closure of the channel will therefore spend the 500,000 SATS available on-chain on the multi-sig address. The outputs of this transaction will be 325,000 sats to a classic address belonging to Alice, and 175,000 sats to an address belonging to Bob.
There are various ways to close a channel. The best is to do it collaboratively with your peer. This makes it possible to quickly recover the funds on-chain and to save on the Bitcoin fees spent during the closing.
If the peer does not respond, it is possible to perform a unilateral closure. This method requires additional waiting time. Finally, if the peer attempts to cheat on the state of the channel during the closure, the other party may use a penalty transaction. This transaction gives all the bitcoin in the channel to the honest party as a penalty for the other party's attempt to cheat.
The use of the Lightning Network therefore requires two on-chain transactions to be carried out: one for the opening of a channel and one for the closure of a channel. In between, users can make a large number of Lightning payments, without needing to use the basic Bitcoin protocol every time.
However, it can be quite tedious to have to open a new channel as soon as you want to make a Lightning payment to a new person. That's why there's a system for routing payments through the Lightning network.
All channels as described in the previous section can be linked to route payments between parties that do not have a direct channel. To do this, it is sufficient that a route is possible between the two protagonists, and that there is sufficient liquidity in the canals on this route.
Let's go back to our example between Alice and Bob, who opened a direct channel together. Let's imagine that from now on, Alice wants to make a payment of 50,000 sats to Frank, without having to open a channel with him.
Some of the participants have already opened channels between them, and there is a road between Alice and Frank.
Alice will be able to make her Lightning payment by going through Bob's nodes, then Charles's, then David's, to finally arrive at Frank's. The amounts in the bi-directional channels will all move in order to route the payment from Alice to Frank.
If you look at each channel individually, their amounts have not changed. It's important to understand that the capacity of a channel alone is constant, despite payment routing. That is, there is always exactly the same number of bitcoins in each channel.
If you look at each intermediate node individually, routing the payment from Alice to Frank has no financial impact. For example, Charles's node received 50,000 sats in his channel with Bob. He then sent 50,000 sats into his channel with David. So it's a blank check for each intermediate node like Charles. None of them won or lost bitcoin. They simply transferred value through their Lightning channels. This method of transmitting payment across nodes is a form of Onion routing.
To simplify, I intentionally overlooked Lightning fees in my popularization. In reality, each intermediary node can claim Lightning transaction fees to route payment from Alice to Frank.
Of course, there are lots of other mechanisms that are used in the Lightning Network. Among these, there are the HTLC (Hashed TimeLock Contracts) which play a key role in avoiding the need for trust between each node when routing a payment. Their operation is quite complex, so I will tell you about them in a future dedicated article.
The Lightning Network is an elegant protocol that allows numerous Bitcoin payments to be made off-chain. It allows instant settlements and transactions to be carried out at a lower cost.
While Lightning has evolved enormously in a few years, its core model isn't perfect. As you have been able to understand with this article, the user must have incoming cash before being able to receive payments. It's very annoying for the user experience. In addition, the very structure of the Lightning Network makes it very complex to have confidentiality with certain payments.
Finally, the liquidity channel system means that there is necessarily an incentive for the user to connect only to a few large entity nodes. Unlike Bitcoin, there is therefore a natural tendency towards centralization in the way Lightning works.
Recently, we are starting to see the arrival of other second layer protocols on Bitcoin with use cases similar to Lightning. This is the case, for example, of the promising protocol Ark, announced in May 2023 by the developer Burak. Even if the developer of this protocol presents it as a complementary system to Lightning, we can't help but think that it is partly the competitor. This shows that it is absolutely possible for new, more efficient second layer systems to emerge and take precedence over the Lightning Network.
.png)
.png)
