Key points
Layer-2 solutions were created to address the scalability limitations inherent in blockchain technology.
The Lightning Network is a layer-2 scalability solution that provides fast transactions without the need for block confirmation, enabling efficient micropayments.
It ensures secure and scalable payments through multisignature addresses and Hash Timelock Contracts.
Introduction
Cryptocurrencies have some unique properties. They are very unlikely to be hacked or have their systems shut down, and anyone can use them to transfer value globally without third-party intervention.
To keep these features running, some limitations are necessary. Since many nodes are responsible for running a cryptocurrency network, the throughput is limited. Therefore, the number of transactions per second (TPS) that a blockchain network can process is relatively low for a technology that aims to be adopted globally.
To overcome the inherent limitations of blockchain technology, several scalability solutions have been proposed to increase the number of transactions a network can process. In this article, we will talk about the Lightning Network, one of the extensions of the Bitcoin protocol.
What is the Lightning Network?
The Lightning Network is a network that operates on top of the blockchain and facilitates peer-to-peer transactions. It is not a Bitcoin-only network – other cryptocurrencies have integrated with it.
You may be wondering what we mean by “operating on top of the blockchain.” The Lightning Network is what we call an off-chain or layer-2 solution. It allows users to conduct transactions without having to record them all on the blockchain.
The Lightning Network is separate from the Bitcoin network – it has its own nodes and software, but it still communicates with the main blockchain. To join or leave the Lightning Network, you need to create special transactions on the blockchain.
When you make your first transaction, you are effectively creating a type of smart contract with another user. We’ll go into more detail shortly – for now, just understand that the smart contract maintains a private ledger for you and another user. On this ledger, you can record many transactions. They are visible only to you and your counterparty, but neither of you can cheat due to some unique features of the setup.
This mini-ledger is known as a channel. Suppose Alice and Bob each put 5 BTC into the smart contract. In their channel, they would both have a balance of 5 BTC. Alice can write to the ledger “pay 1 BTC to Bob.” Now Bob has 6 BTC and Alice has 4. Later, Bob could send 2 BTC back to Alice, updating the balances to 6 BTC for Alice and 4 BTC for Bob. They can keep doing this for some time.
At any time, either of them can publish the current state of the channel to the blockchain. At that time, the balances of each are allocated to their respective parts of the blockchain.
As the name suggests, Lightning transactions are extremely fast. There’s no need to wait for block confirmations – payments can be made very quickly, depending on your internet connection.
Why is the Lightning Network necessary?
So far, the Lightning Network (LN) seems to be the most sensible approach to scaling the Bitcoin blockchain. Coordinating changes across such a large ecosystem is tricky – there’s the risk of hard forks and potentially catastrophic bugs. With so much value at stake, experimentation is extremely dangerous.
By removing this type of experimentation from the blockchain, there is much more flexibility. If something goes wrong, the actual Bitcoin network will not be impacted. Layer-2 solutions do not compromise any of the security measures that have kept the protocol running for over 15 years.
There is also no obligation to change the traditional way of operating. On-chain transactions continue to work as normal for the end user, but now they also have the option to conduct off-chain transactions.
Using the Lightning Network offers many benefits. Let's look at some of the main ones.
Scalability
Bitcoin blocks are created every ten minutes and can only contain a few transactions. Space in each block is scarce, so you must bid against other users to get your transaction included in a timely manner. Miners’ main concern is getting paid, so they include transactions with the highest fees first.
When there aren’t many users trying to send funds at the same time, this isn’t necessarily a problem. You can set a low fee and your transaction is likely to be included in the next block. However, when many users are broadcasting transactions simultaneously, the average fee can increase significantly. There have been several occasions when it has exceeded $10. At the peak of the 2017 bull market, it exceeded $50. In April 2021, the average Bitcoin transaction fee exceeded $60.
This may seem insignificant for transactions that move thousands of dollars in Bitcoin, but for smaller payments, it’s unsustainable. Who wants to pay for a $3 coffee with an additional $10 fee?
With the Lightning Network, you still have to pay two fees – one to open your channel and one to close it. But once you open the channel, you and your counterparty can make thousands of transactions for free. When you’re done, you just publish the final state to the blockchain.
In general, if more users rely on off-chain solutions like the Lightning Network, block space will be used more efficiently. Low-value, high-frequency transfers can be made through payment channels, while block space is used for larger transactions and channel opening/closing. This would make the system more accessible to a much wider user base, allowing for long-term scalability.
Micropayments
There is a minimum amount of Bitcoin you can send in one transaction – approximately 0.00000546 BTC. Currently, this equates to around $0.38. It’s a small amount, but the Lightning Network allows you to go beyond the limits to make transactions with the smallest unit currently available – 0.00000001 BTC, or one satoshi.
Lightning is much more interesting for micropayments. Regular transaction fees make it impossible to send small amounts on the main blockchain. Within a channel, however, you can send a small fraction of a Bitcoin for free.
Micropayments are suitable for many use cases. Some speculate that they could be a viable replacement for subscription-based models, where users pay small amounts each time they use a particular service.
Privacy
Another benefit of the Lightning Network is that it offers users a high degree of confidentiality. Parties do not need to disclose their channels on the network. You can query the blockchain and say that a transaction has opened a channel, but you will not be able to tell what is happening inside it. If users opt for a private channel, only they will have access to the transactions that have taken place.
If Alice has a channel with Bob and Bob has a channel with Carol, Alice and Carol can send payments to each other through Bob. If Dan is connected to Carol, Alice can send payments to him. We can imagine this scaling up to a large network of interconnected payment channels. In such a setup, once the channel is closed, it is not possible to be certain who Alice sent the funds to.
How does the Lightning Network work?
We explain how the Lightning Network depends on channels between nodes. Let's check out more details.
Multisignature addresses
A multisignature (or multisig) address allows the use of multiple private keys for transactions/spending. When you create one, you specify how many private keys can spend the funds and how many of those keys are required to sign a transaction. For example, a 1-of-5 scheme means that five keys can produce a valid signature and only one is required. A 2-of-3 scheme indicates that out of three possible keys, two are required to spend the funds.
To initialize a Lightning channel, participants lock up funds in a 2-of-2 scheme. There are only two private keys capable of signing, and both are required to move coins. Let’s use our friends Alice and Bob as an example again. They’re going to be making a lot of payments to each other over the next few months, so they decide to open a Lightning Network channel.
First, the two deposit, say, 3 BTC each into the jointly owned multisig address. It is worth reiterating that Bob cannot transfer resources from the address without Alice agreeing, and vice versa.
Now, they can just keep notes and adjust the balances on each side. They both have a starting balance of 3 BTC. If Alice wants to make a payment of 1 BTC to Bob, why not simply note that Alice now has 2 BTC and Bob has 4 BTC? The balances can be tracked this way until they decide to transfer the funds to another address.
This is possible, but it’s not the ideal scenario. More importantly, with this method it’s incredibly easy for one of them to not cooperate, right? If Alice ends up with 6 BTC and Bob has none, Bob doesn’t lose anything by refusing to release the funds (except maybe his friendship with Alice).
Hash Timelock Contracts (HTLC)
The system mentioned above doesn’t have much to offer, considering today’s reliable configuration options. It gets much more interesting when we introduce a mechanism that enforces the “contract” between Alice and Bob. If one of the parties doesn’t follow the rules, the other still has a way to withdraw their funds from the channel.
This mechanism is the Hash Timelock Contract (or HTLC). The term may sound scary, but it is actually a fairly simple concept to understand. It combines two other technologies (hashlocks and timelocks) to remedy any uncooperative behavior in payment channels.
A hashlock is a condition placed on a transaction that dictates that you can only spend funds if you can prove that you know a secret. The sender hashes a set of data and includes the hash in the recipient's transaction. The recipient can only spend the funds if they provide the original data (the secret) that matches the hash. And the only way to get that data is to receive it from the sender.
A timelock is a condition that prevents you from spending funds before a specific time. This is either a specific time or a specific block height.
HTLCs are created by combining hashlocks and timelocks. In practice, HTLCs can be used to create conditional payments – the recipient must provide a secret before a certain deadline or the sender will be able to recover the funds. This next part is probably easiest to explain with an example, so let’s go back to the Alice and Bob example.
Opening and closing channels
In the Alice and Bob example, they have created transactions that fund their shared multisignature address. But these transactions have not yet been published to the blockchain! Before that, however, we need to do one more thing.
Three coins from Bob and three coins from Alice.
Remember, the only way to transfer these coins from the multisig is if Alice and Bob jointly sign a transaction. If Alice wanted to send all six coins to an external address, she would need Bob’s approval. First, she would create a transaction (six bitcoins to this address) and then add her own signature.
She could try to broadcast the transaction immediately, but it would be invalid because Bob did not include his signature. Alice must deliver the incomplete transaction to him first. Once Bob adds his signature, the transaction becomes valid.
We haven’t yet established a mechanism to ensure that everyone is acting honestly. As we said before, if your counterparty refuses to cooperate, your funds will effectively be frozen. Let’s take a closer look at the mechanism that prevents this from happening. There are a lot of moving parts, so let’s take it slow.
Each party needs to create a secret – let’s call these secrets “As” and “Bs”. They would be terrible secrets if Alice and Bob revealed them, so they keep them hidden for now. The pair will generate respective hashes of the secrets – h(As) and h(Bs). Then, instead of sharing their secrets, they share these hashes with each other.
Alice and Bob share the hashes of their secrets with each other.
Alice and Bob must also create a set of commitment transactions before publishing their first transactions to the multisignature address. This will ensure that both parties have some assurance in case the other decides to keep the funds locked.
If you think of a channel as the mini-ledger we mentioned earlier, commitment transactions are the updates made to the ledger. Whenever you create a new pair of commitment transactions, you are rebalancing the funds between the two participants.
Alice’s transaction will have two outputs – one that pays an address she owns and one that is locked in a new multisig address. She signs the transaction and passes it to Bob.
Alice’s transaction has two outputs – one to her own address and one to a new multisig. She still needs Bob’s signature to validate the transaction.
Bob does the same – one output pays to himself, the other pays another multisig address. He signs the transaction and passes it to Alice.
We have two incomplete transactions that are very similar.
Normally, Alice could add a signature to Bob's transaction to make it valid. However, you'll notice that these funds are being spent on the 2-of-2 multisig scheme that we haven't funded yet. It's like trying to clear a check from an account with no funds. So these partially signed transactions will only be usable once multisig is up and running.
The new multisignature addresses (destination of the 3 BTC outputs) have some peculiar properties. Let’s take a look at the incomplete transaction that Alice signed and sent to Bob. The multisig output can be spent under the following conditions:
Both parties can sign the transaction cooperatively.
Bob can spend the output value on his own after a certain period of time (due to the timelock).
Alice can spend the amount if she knows Bob's secret Bs.
Regarding the transaction that Bob sent to Alice:
Both parties can sign the transaction cooperatively.
Alice can spend the amount on her own after a certain period of time.
Bob can spend the amount if he knows Alice's secret As.
Keep in mind that neither party knows the other’s secret, so condition 3 is not yet a possibility. Another important note is that if you sign a transaction, your counterparty can spend the amount immediately, as there are no special conditions for the output. You can either wait for the timelock to expire to spend the funds yourself, or cooperate with the other party to spend them immediately.
Ok! You can now publish transactions to the original 2-of-2 multisignature address. It is finally safe to do so, as you can recover your funds if your counterparty leaves the channel.
Once the transactions are confirmed, the channel will be up and running. This first pair of transactions shows us the current state of the mini-ledger. Currently, it will pay 3 BTC to Bob and 3 BTC to Alice.
When Alice wants to make a new payment to Bob, they create two new transactions that replace the first set. The process is the same—the transactions will be partially signed. First, however, Alice and Bob discard their old secrets and use new hashes for the next round of transactions.
If Alice wanted to pay 1 BTC to Bob, for example, the two new transactions would credit 2 BTC to Alice and 4 BTC to Bob. This way, the balance would be updated.
Either party can sign and broadcast one of the most recent transactions at any time to “settle” it on the blockchain. But the party doing so will have to wait until the timelock expires, while the other can spend it immediately. Remember, if Bob signs and broadcasts Alice’s transaction, she will have an output that involves no conditions.
Both parties can agree to close the channel together (a cooperative closure). This is probably the easiest and quickest way to recover funds on the blockchain. However, even if one party refuses to cooperate, the other can still recover their funds by waiting out the timelock.
How does the Lightning Network prevent cheating?
Perhaps you’ve identified an attack vector in this process. If Bob currently has a balance of 1 BTC, what’s to stop him from broadcasting an older transaction from when he had a larger balance? He already has Alice’s partially signed transaction, he just needs to add his signature and broadcast it, right?
There’s nothing stopping him from doing this – except that he could lose his entire balance. Let’s say he broadcasts an old transaction that pays one coin to Alice and five to that multisig address we mentioned earlier.
Alice receives her coins immediately. Bob, on the other hand, must wait until the timelock expires to spend the amount from the multisig address. Remember the other condition we mentioned that would allow Alice to spend the same funds immediately? To do so, she needed a secret that she didn’t have at the time. But now she has that information – as soon as the second round of transactions was created, Bob revealed his secret.
While Bob sits around, unable to do anything while waiting for the timelock to expire, Alice can move the funds. This “punishment” mechanism makes it very unlikely that participants will try to cheat, since the counterparty will have access to their coins.
Transaction routing
We talked about this earlier – it’s possible to connect channels. If it weren’t possible, the Lightning Network wouldn’t be as useful for payments. Would you lock $500 in a channel with a coffee shop just to get your daily coffee fix for the next few months?
You don't have to do this. If Alice opens a channel with Bob and Bob already has one with Carol, Bob can route payments through both of them. This mechanism also works across multiple hops, meaning Alice can effectively pay anyone who is connected to one of these routes.
In this scenario, Alice can use multiple routes to get to Frank. In practice, she will always use the easiest one.
Intermediaries may charge a small fee for their routing role (although it is not an obligation). The Lightning Network is still very new, so a fee market has not yet materialized. And many expect to see rates based on the liquidity provided.
Typically, on the blockchain, your fee is based solely on the space your transaction takes up in a block – the amount of the transaction doesn’t matter – the fee for payments of $1 or $10,000,000 will be the same. On the other hand, on the Lightning Network, there is no such thing as block space.
Instead, there is the concept of local balance and remote balance. The local balance is the amount you can “push” to the other end of the channel, while the remote balance is the amount your counterparty can send to you.
One more example. Let's look at one of the routes mentioned above: Alice <> Carol <> Frank.
User balance before and after a 0.3 BTC transfer from Alice to Frank.
The Alice <> Carol and Carol <> Frank routes have a total capacity of 1 BTC each. Alice’s local balance is 0.7 BTC. If they consolidate their balances on the blockchain now, she would receive 0.7 BTC and Carol would receive the remote balance (i.e. 0.3 BTC).
If Alice wants to send 0.3 BTC to Frank, she “pushes” 0.3 BTC to Carol’s side of the channel. Carol then sends 0.3 BTC from her local balance to her channel with Frank. As a result, Carol’s balance remains the same: +0.3 BTC from Alice and -0.3 BTC from Frank.
Carol doesn’t lose out by acting as a connection between Frank and Alice, but she does lose out in terms of flexibility. Notice, she can now spend 0.6 BTC on her channel with Alice, but only 0.1 BTC on the channel with Frank.
Imagine that Alice is only connected to Carol, while Frank is connected to a much wider network. Previously, Carol could send a total of 0.4 BTC to other people through Frank, but now she can only send 0.1 BTC, as that is the remaining amount she has in the channel.
In this scenario, Alice is consuming Carol’s liquidity. Without any incentive, Carol may not want this less favorable position. Therefore, she can simply charge a fee of 10 satoshis for every 0.01 BTC transferred. In this way, the more local balances Carol sacrifices on “stronger” routes, the more she profits.
As mentioned earlier, there is no requirement to charge fees. Some users may not care about the reduced liquidity. Others may simply open channels directly with the recipient.
Lightning Network Limitations
It would be fantastic if the Lightning Network proved to be the solution to all of Bitcoin's scalability problems. Unfortunately, it has its own shortcomings and limitations.
Usability
Bitcoin isn’t the most intuitive system for beginners—addresses, fees, and other aspects can be confusing at first. Additionally, once a Lightning user is set up, the user must open channels before making payments. This can be a time-consuming and complicated process for a newcomer with little knowledge of concepts like inbound/outbound capacity.
That said, improvements are constantly being made to reduce barriers to entry and provide a more streamlined experience for users.
Liquidity
One of the biggest criticisms of the Lightning Network is its limited transaction capacity. You cannot spend more than what is locked in a channel. If you spend all your funds until the remote balance represents all the funds in the channel, you will need to close the channel. Alternatively, you can wait until someone pays you, but this is not the ideal option.
Routes can also be limited by the total capacity of the channel. Consider the previous example of Alice <> Carol <> Frank. If Alice and Carol’s channel has a capacity of 5 BTC, but Carol and Frank’s channel only has a capacity of 1 BTC, Alice will never be able to send more than 1 BTC. Even then, the entire balance would need to be on Carol’s side of the Carol <> Frank channel for the transaction to work. This can drastically limit the amount of funds that can be sent through LN channels, and thus has a knock-on effect on usability.
Centralized hubs
Due to the problem mentioned in the previous section, there is a concern that the network will facilitate the creation of giant “hubs”. That is, hubs of large organizations/entities, strongly connected and with a lot of liquidity. In this scenario, any payments with significant amounts would need to be routed through these entities.
Obviously, this would not be a good situation. It would weaken the system, because if some of these entities went offline or had problems, the vast majority of connections between peers would be interrupted. There is also a higher risk of censorship, since there are only a few points through which transactions are flowing.
The Current State of the Lightning Network
Currently, as of March 2024, the Lightning Network is operating well. The network has over 13,000 online nodes, 52,000 active channels, and over 4,570 BTC of capacity.
Global distribution of Lightning Network nodes.
There are several different node implementations out there – Blockstream’s c-lightning, Lightning Labs’ Lightning Network Daemon, and ACINQ’s Eclair are some of the most popular. Many companies offer plug-and-play nodes for less technical users. All you need to do is plug in your device and you’re ready to start using the Lightning Network.
Final considerations
Since its mainnet launch in 2018, the Lightning Network has seen significant growth. There are still some usability hurdles to overcome, as currently a certain level of technical proficiency is required to operate a Lightning node. But with the rapid development we are seeing, the barriers to entry will become increasingly lower.
Further reading
Blockchain Scalability - Sidechains and Payment Channels
What are we??
What are smart contracts?
Disclaimer: This content is presented to you “as is” for informational and educational purposes only, without warranty of any kind. The content should not be construed as financial, legal, or other professional advice, and is not intended to recommend the purchase of any specific product or service. You should seek your own advice from professional advisors. In the case of contributions and articles submitted by third-party contributors, please note that the views expressed are those of the respective author and do not necessarily reflect the views of Binance Academy. For more details, please read our disclaimer here. Prices of digital assets can be volatile. The value of your investment may go down as well as up, and you may not get back the amount invested. You are solely responsible for your investment decisions and Binance Academy will not be liable for any of your possible losses. This material should not be construed as financial, legal, or other professional advice. For more information, please refer to our Terms of Use and Risk Warning.