Introduction
Cryptocurrencies have some pretty unique properties. They can’t be hacked or shut down easily, and anyone can use them to transmit value around the globe without a third party’s intervention.
To ensure that these features remain, significant trade-offs must be made. Since many nodes are responsible for running a cryptocurrency network, throughput is limited. As a result, the number of transactions per second (TPS) a blockchain network can process is relatively low for a technology that aims to be adopted by the masses.
To overcome the inherent limitations of blockchain technology, a number of scalability solutions have been proposed to increase the number of transactions that a network can handle. In this article, we’ll take a deep dive into the Lightning Network, one such extension of the Bitcoin protocol.
What is the Lightning Network?
The Lightning Network is a network that sits on top of a blockchain to facilitate fast peer-to-peer transactions. It’s not exclusive to Bitcoin – other cryptocurrencies such as Litecoin have integrated it.
You might be wondering what we mean by “sits on top of a blockchain.” The Lightning Network is what’s called an off-chain or layer two solution. It allows individuals to transact without having to record every transaction on the blockchain.
The Lightning Network is separate from the Bitcoin network – it has its own nodes and software, but it nonetheless communicates with the main chain. To enter or exit the Lightning Network, you need to create special transactions on the blockchain.
What you’re actually doing with your first transaction is building a sort of smart contract with another user. We’ll get into the details shortly – for now, just think of the smart contract holding a private ledger with the other user. You can write many transactions to this ledger. They’re only visible to you and your counterparty, but neither of you can cheat due to some peculiar features of the setup.
This mini-ledger is called a channel. Say Alice and Bob put 5 BTC each into the smart contract. In their channel – they’d now both have a balance of 5 BTC. Alice could then write to the ledger pay 1 BTC to Bob. Now, Bob has 6 BTC on his side, and Alice has 4. Then, Bob could send 2 BTC back to Alice at a later date, updating the balances to 6 BTC on Alice’s side and 4 BTC on Bob’s. They can continue to do this for a while.
At any time, either can publish the current state of the channel to the blockchain. At that point, the balances on each side of the channel are allocated to their respective parties on-chain.
True to the name, Lightning transactions are lightning-fast. There are no block confirmations to wait for – payments can be made as fast as your internet connection will permit.
Why is the Lightning Network necessary?
So far, the Lightning Network (or simply, LN) appears to be the most sensible approach to scaling the Bitcoin blockchain. Coordinating changes in such a vast ecosystem is tricky – there’s a risk of hard forks and potentially catastrophic bugs. With so much value at stake, experimentation is incredibly dangerous.
When you move that experimentation away from the blockchain, you have a lot more flexibility. If something goes wrong, it’ll have no impact on the actual Bitcoin network. Layer two solutions don’t undermine any of the security assumptions that have kept the protocol going for 10+ years.
There’s no obligation to switch from the old way of doing things, either. On-chain transactions continue to work as normal for the end-user, but they now have the option of transacting off-chain, too.
There are several benefits to using the Lightning Network. We’ll look at some of the main ones below.
Scalability
Bitcoin blocks are created approximately every ten minutes, and can only hold so many transactions. Block space is a scarce resource, so you must bid against other users to have yours included in a timely manner. Miners care, first and foremost, about getting paid, so they’ll include transactions with higher fees first.
When there aren’t many users trying to send funds at the same time, this isn’t really an issue. You can set a low fee, and you’re likely to have the transaction included in the next block. But when everyone’s broadcasting transactions at the same time, the average fee can rise significantly. On a few occasions, it has exceeded $5. At the height of the 2017 bull market, it exceeded $50.
Average Bitcoin Transaction Fee (in USD)
That might seem insignificant for transactions moving thousands of dollars worth of Bitcoin, but for smaller payments, it’s not sustainable. Who wants to pay for a $3 coffee with a $5 fee attached?
With the Lightning Network, you still pay two fees – one to open your channel, and another to close it. But you and your counterparty can make thousands of transactions for free once the channel is open. Once you’re finished, you just need to publish the final state to the blockchain.
In the grand scheme, if more users rely on off-chain solutions like the Lightning Network, block space will be used more efficiently. Low-value, high-frequency transfers could be carried out in payment channels, while block space is used for larger transactions and channel opening/closing. This would make the system accessible to a vastly wider user base, allowing it to scale in the long run.
Micropayments
There’s a minimum amount of Bitcoin you can send in a transaction – approximately 0.00000546 BTC. At the time of writing, that’s equal to about four cents. It’s a small amount, but the Lightning Network allows you to push the limits to transact the smallest unit currently available – 0.00000001 BTC, or one satoshi.
Lightning is a lot more appealing for micropayments. The fees on regular transactions make it impractical to send tiny amounts on the main chain. Within a channel, however, you’re free to send a fraction of a fraction of a Bitcoin for free.
Micropayments are suited to plenty of use cases. Some speculate that they could be a viable replacement for subscription-based models, where users instead pay tiny amounts each time they use a service.
Privacy
A secondary benefit of the Lightning Network is that it can offer users a high degree of confidentiality. Parties do not need to make their channels known to the broader network. While you may be able to look at the blockchain and say this transaction opened a channel, you won’t necessarily be able to tell what’s going on inside it. If the participants choose to make their channel private, only they will know what transactions are taking place.
If Alice has a channel with Bob and Bob has a channel with Carol, Alice and Carol can send payments to each other via Bob. If Dan is connected to Carol, Alice can send payments to him. You can imagine this expanding into a sprawling network of interconnected payment channels. In such a setup, you couldn’t be sure who Alice has sent funds to once the channel is closed.
How does the Lightning Network work?
We’ve explained how the Lightning Network relies on channels between nodes at a high level. Let’s now take a look under the hood.
Multisignature addresses
A multisignature (or multisig) address is one that multiple private keys can spend from. When creating one, you specify how many private keys can spend the funds, and how many of those keys are required to sign a transaction. For instance, a 1-of-5 scheme means that five keys can produce a valid signature and that only one is needed. A 2-of-3 scheme would indicate that, out of the three possible keys, any two are required to spend the funds.
To initialize a Lightning channel, the participants lock up funds in a 2-of-2 scheme. There are only two private keys capable of signing, and both are needed to move coins. Let’s bring back our friends Alice and Bob at this point. They’ll be making a lot of payments to each other in the coming months, so they decide to open a Lightning Network channel.
This starts with both of them depositing, say, 3 BTC each into the jointly-owned multisig address. It’s worth reiterating that Bob can’t move funds out of the address without Alice agreeing, or vice versa.
Now, they could just keep a sheet of paper that adjusts the balances on each side. Both have a starting balance of 3 BTC. If Alice wants to make a payment of 1 BTC to Bob, why not just make a note that Alice now owns 2 BTC and Bob owns 4 BTC? Balances could be tracked like this until they decided to move the funds out.
That’s possible, but where’s the fun in it? More importantly, doesn’t that make it incredibly easy for someone not to cooperate? If Alice ends up with 6 BTC and Bob with none, Bob loses nothing by refusing to release the funds (except, perhaps, his friendship with Alice).
Hash Timelock Contracts (HTLCs)
The system above is boring and doesn’t offer much over today’s trusted setups. It gets a lot more interesting when we introduce a mechanism that enforces the “contract” between Alice and Bob. If one of the parties decides not to play by the rules, then the other one still has a remedy to get their funds out of the channel.
That mechanism is a Hash Timelock Contract (or HTLC). The term may sound daunting, but it’s actually quite a straightforward concept to grasp. It marries two other technologies (hashlocks and timelocks) to remedy any uncooperative behavior in payment channels.
A hashlock is a condition placed on a transaction dictating that you can only spend funds by proving that you know a secret. The sender hashes a piece of data and includes the hash in the transaction to the receiver. The only way that the receiver can spend it is if they provide the original data (the secret) that matches the hash. And the only way they can provide that data is if the sender gives it to them.
A timelock is a condition that prevents you from spending funds before a certain time. It’s specified either as an actual time, or a specified block height.
HTLCs are created by combining hashlocks and timelocks. In practice, HTLCs can be used to create conditional payments – the receiver has to provide a secret before a certain time, or the sender can reclaim the funds. This next part is probably better explained with an example, so let’s get back to Alice and Bob.
Opening and closing channels
We gave the example of Alice and Bob having just created transactions that fund the multisignature address they’ll share. But those transactions aren’t published to the blockchain yet! We need to do one more thing first.
Three coins from Bob and three coins from Alice.
Remember, the only way those coins can move out of the multisig is if both Alice and Bob jointly sign a transaction. If Alice wanted to send all the six coins to an external address, she would need Bob’s approval. She’d first put together a transaction (six bitcoins to this address) and add her own signature.
She could try to broadcast the transaction right away, but it would be invalid because Bob hasn’t included his signature. Alice must give the incomplete transaction to him first. Once he adds his signature, it becomes valid.
We still haven’t put a mechanism in place to keep everyone playing honestly. As we said earlier, if your counterparty refuses to cooperate, your funds are effectively trapped. Let’s get into the mechanism that prevents this. There are a few different moving pieces, so bear with us.
Each party needs to come up with a secret – let’s just call those As and Bs. They’d be terrible secrets if Alice and Bob revealed them, so they’ll keep them hidden for now. The pair will generate the respective secrets’ hashes – h(As) and h(Bs). So instead of sharing their secrets, they share those hashes with each other.
Alice and Bob share the hashes of their secrets with each other.
Alice and Bob also need to create a set of commitment transactions before they publish their first transactions to the multisignature address. This will give them a remedy in case the other decides to keep funds hostage.
If you think about a channel like the mini-ledger we referenced earlier, then commitment transactions are the updates that you make to the ledger. Any time you create a new pair of commitment transactions, you’re rebalancing the funds between the two participants.
Alice’s one will have two outputs – one that pays an address she owns, and another that’s locked into a new multisig address. She signs it and gives it to Bob.
Alice’s transaction with two outputs – one to her own address, and one to a new multisig. She still needs Bob’s signature to make it valid.
Bob does the same – one output pays himself, the other pays another multisig address. He signs it and gives 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. But you’ll note that these funds are being spent from the 2-of-2 multisig that we haven’t funded yet. It’s a bit like trying to spend a cheque from an account that has zero balance for now. Therefore, these partially-signed transactions will only be usable once the multisig is up and running.
The new multisignature addresses (where the 3 BTC outputs are destined) have some peculiar properties. Let’s take a look at the incomplete transaction that Alice signed and gave to Bob. The multisig output can be spent under the following conditions:
- Both parties can cooperatively sign it.
- Bob can spend it by himself after a certain period of time (due to our timelock).
- Alice can spend it if she knows Bob’s secret Bs.
For the transaction Bob gave to Alice:
- Both parties can cooperatively sign it.
- Alice can spend it by herself after a certain period of time.
- Bob can spend it if he knows Alice’s secret As.
Bear in mind that neither party knows the other’s secret, so 3) isn’t a possibility yet. Another thing to note is that, if you sign a transaction, your counterparty can spend immediately because there are no special conditions on their output. You can either wait for the timelock to expire to spend the funds by yourself, or you can cooperate with the other party to spend them outright.
Okay! Now you can publish the transactions into the original 2-of-2 multisignature address. It’s finally safe to do so because you can retrieve your funds if your counterparty abandons the channel.
Once the transactions confirm, the channel is up and running. That first pair of transactions shows us the current state of the mini-ledger. Currently, it will pay out 3 BTC to Bob, and 3 BTC to Alice.
When Alice wants to make a new payment to Bob, the pair create two new transactions to replace the first set. The drill is the same – they’re only half-signed. However, Alice and Bob first give up their old secrets and trade 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. In this way, the balance is updated.
Either party can sign and broadcast one of the most recent transactions at any time to “settle” it on the blockchain. But whichever party does so will need to wait until the timelock has expired, while the other can spend immediately. Remember, if Bob signs and broadcasts Alice’s transaction, she now has an output with no conditions on it.
Both parties can agree to close the channel together (a cooperative close). This is probably the easiest and quickest way to get your funds back onto the chain. However, even if one party becomes unresponsive or refuses to cooperate, the other can still reclaim their funds by waiting out the timelock.
How does the Lightning Network prevent cheating?
You might have identified an attack vector here. If Bob currently has a 1 BTC balance, what’s to stop him from broadcasting an older transaction where he had more? He’s already got the half-signed transaction from Alice, he just needs to add his signature and broadcast it, right?
Nothing’s stopping him from doing that – except for the fact that he could lose his entire balance. Let’s say he goes through with it and broadcasts an old transaction that pays one coin to Alice and five to that multisig address we mentioned earlier.
Alice receives her coin immediately. Bob, on the other hand, must wait until the timelock expires to spend from the multisig address. Remember the other condition we mentioned that would allow Alice to spend those same funds immediately? She needs a secret that she didn’t have then. She does now – as soon as the second round of transactions were created, Bob gave that secret away.
While Bob sits, unable to do anything as he waits for the timelock to expire, Alice can move those funds. This punishment-based mechanism means that participants are unlikely to even attempt to cheat because the peer will get access to their coins.
Routing payments
We touched on this earlier – channels can be connected. The Lightning Network wouldn’t be that useful for payments otherwise. Are you really going to lock up $500 in a channel with a coffee shop just so you can get your daily fix for the next few months?
You don’t have to do that. If Alice opens a channel with Bob and Bob already has one with Carol, Bob can route payments between the two. This can work across multiple “hops”, meaning that Alice can effectively pay anyone to whom a path exists.
In this scenario, Alice can go through multiple routes to get to Frank. In practice, she will always take the easiest one.
For their role in routing, the intermediaries might take a small fee (though there’s no obligation to). The Lightning Network is still very new, so a fee market has yet to materialize. What many expect to see are fees based on liquidity provided.
On the base chain, your fee is based solely on the space your transaction takes up in a block – the value being transmitted doesn’t matter – $1 and $10,000,000 payments cost the same. In contrast, there’s no such thing as block space within the Lightning Network.
Instead, there’s the idea of local and remote balances. The local balance is the amount that you can “push” to the other end of the channel, whereas the remote balance is that which your counterparty can push to you.
Time for another example. Let’s take a closer look at one of the above paths: Alice <> Carol <> Frank.
Users’ balance before and after a transfer of 0.3 BTC from Alice to Frank.
The Alice <> Carol and Carol <> Frank each have a total capacity of 1 BTC. Alice’s local balance is 0.7 BTC. If they settled 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. Then Carol pushes 0.3 BTC from her local balance in the channel with Frank. As a result, Carol’s balance remains the same: the +0.3 BTC from Alice and -0.3 BTC to Frank cancel each other out.
Carol isn’t losing value from acting as a connection between Frank, but she is making herself less flexible. You see, she can now spend 0.6 BTC in her channel with Alice, but only 0.1 BTC in the channel with Frank.
You can imagine a situation where Alice is only connected to Carol, whereas Frank is connected to a much wider network. Carol could previously send a total of 0.4 BTC to others via Frank, but now she can only push 0.1 BTC because that’s all she has on her end of the channel.
In this scenario, Alice is effectively eating into Carol’s liquidity. Without any kind of incentive, Carol may not want to weaken her own position. So, instead, she might just say I will route every 0.01 BTC at a fee of ten satoshis. In this way, the more of her local balances Carol sacrifices in “stronger” paths, the more she profits.
As mentioned previously, there’s no de facto requirement to charge a fee. Some might not be concerned with the reduction in liquidity. Others might just open channels directly to the receiver.
Limitations of the Lightning Network
It would be fantastic if the Lightning Network proved to be the solution to all of Bitcoin’s scalability troubles. Unfortunately, it has its own shortcomings that may get in the way.
Usability
Bitcoin isn’t the most intuitive system for beginners – addresses, fees, etc. can be confusing to familiarize yourself with. But wallets can abstract away the complicated stuff to give users something that vaguely resembles existing payment systems. You can get someone to download a smartphone wallet, send them coins, and they’re good to go.
For now, that isn’t possible with the Lightning Network. Options are limited when it comes to smartphone apps – generally, Lightning nodes require access to a Bitcoin node to be fully usable.
After a client has been set up, users also need to start opening channels before they can make payments. This can be a time-consuming process, and it could be overwhelming when a newcomer is introduced to concepts like inbound/outbound capacity.
That said, improvements are constantly being made to reduce the barriers to entry, and to provide users with a more streamlined experience.
Liquidity
One of the biggest criticisms of the Lightning Network is that your ability to transact is constrained. You can’t spend more than you have locked into a channel. If you spend all of your funds so that the remote balance has all of the channel’s funds, you’ll have to close the channel. Alternatively, you can wait until someone pays you through it, but that’s not ideal.
Your paths can also be limited by the channel’s total capacity. Take the Alice <> Carol <> Frank example from earlier. If Alice and Carol have a capacity of 5 BTC in their channel, but Carol and Frank only have a capacity of 1 BTC, Alice can never send more than 1 BTC. Even then, the entire balance would need to be on Carol’s side of the Carol <> Frank channel for that to work. This can severely limit the amount of funds that can be passed along LN channels, and thus has a knock-on effect on usability.
Centralized hubs
Because of the issue mentioned in the previous section, there’s some concern that the network will facilitate the creation of massive “hubs.” That is, large, heavily-connected entities with a lot of liquidity. Any significant payments would need to be routed through some of these entities.
Obviously, that wouldn’t be a great situation. It would weaken the system, as these entities going offline would majorly disrupt relationships between peers. There’s also an increased risk of censorship since there are only a few points through which transactions are flowing.
The current state of the Lightning Network
As of March 2022, the Lightning Network looks healthy. It boasts upwards of 35,000 online nodes, 85,000+ active channels, and just over 3,570 BTC in capacity.
Global distribution of Lightning Network nodes. Source: explorer.acinq.co
There are a handful of different node implementations – Blockstream’s c-lightning, Lightning Labs’ Lightning Network Daemon, and ACINQ’s Eclair are some of the most popular. For users that are less technically inclined, many companies offer plug-and-play nodes. The only thing you have to do with these is power up the device and you’re ready to get started with the Lightning Network.
Closing thoughts
Since its mainnet launch in 2018, the Lightning Network has seen impressive growth, in spite of many considering it to still be in beta.
There are still some usability obstacles to overcome, as it currently requires some degree of technical proficiency to operate a Lightning node. But with the amount of development taking place, we may well see the barriers to entry reduced over time.
If the issues can be resolved, the Lightning Network could become an integral part of the Bitcoin ecosystem, greatly boosting scalability and transaction speeds.
