Introduction
Cryptocurrencies have some rather distinctive properties. They cannot be hacked or turned off easily, and anyone can use them to transmit value globally without the need for third-party intervention. In this article, we will dive into the Lightning Network, an extension of the Bitcoin protocol.
To ensure that these features remain, significant trade-offs are required. Since many nodes are responsible for operating a cryptocurrency network, throughput is limited. As a result, the number of transactions per second (TPS) that a blockchain network can handle is relatively low for a technology that aims to gain public acceptance.
To overcome the inherent limitations of blockchain technology, several scalability solutions have been proposed to increase the number of transactions that a network can handle.
What is Lightning Network?
Lightning Network is a network that sits on top of the blockchain to facilitate fast peer-to-peer transactions. It’s not exclusive to Bitcoin – other cryptocurrencies like Litecoin have it built in.
You may be wondering what we mean by “on a blockchain”. Lightning Network is known as an off-chain or layer two solution. It allows transactions 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 still communicates with the main chain. To enter or exit Lightning Network, you need to create special transactions on the blockchain.
What you’re really doing with your first transaction is building a kind of smart contract with other users. We’ll get into the details shortly – for now, just think about smart contracts that keep a private ledger with other users. You can write multiple transactions to this ledger. They are only visible to you and your partner, but none of you can cheat due to some special features of the setup.
This mini ledger is named channel. Let’s say Alice and Bob put 5 BTC each in the smart contract. In their channel – now both have a balance of 5 BTC. Alice can then write to the ledger, paying 1 BTC to Bob. Bob now has 6 BTC on his side and Alice has 4. Bob can then send 2 BTC back to Alice at a later date, updating the balance to 6 BTC for Alice and 4 BTC for Bob. They may continue to do this for a while.
At any time, the current state of the channel can be published to the blockchain. At that point, the balance on each side of the channel is allocated to their respective parties in the chain.
As the name suggests, Lightning transactions happen lightning fast. No block confirmations to wait – payments can be made as quickly as your internet connection allows.
What benefit does Lightning Network have?
By far, the Lightning Network (or simply LN) seems to be the most logical approach to scaling the Bitcoin blockchain. Coordinating changes in such a vast ecosystem is difficult – there is a risk of hard forks and potentially catastrophic failures. With so much value at stake, experimentation is extremely dangerous.
When you move that experiment off the blockchain, you have a lot more flexibility. If something goes wrong, it won’t affect the actual Bitcoin network. Layer two solutions do not undermine any of the security assumptions that have kept the protocol working for over 10 years.
There is also no obligation to switch from the old way of doing things. On-chain transactions continue to function normally for end users, but they now also have the option of off-chain transactions.
The benefits of using Lightning Network are as follows:
Scalability
Bitcoin blocks are generated about every 10 minutes and can only contain so many transactions. Block space is a scarce resource, so you have to bid against other users to get yours in a timely manner. Miners care, first and foremost, about getting paid, so they will cover higher fee transactions first.
When there are not many users trying to deposit at the same time, this is not really a problem. You can set a low fee and it is likely that you will have the transaction included in the next block. But when everyone broadcasts the transaction at the same time, the average fee can go up significantly. In a few cases, it exceeded $5. In 2017, at the height of the bull market, it exceeded $50.
That may seem insignificant for transactions that move thousands of dollars worth of Bitcoin, but for smaller payments, it’s unsustainable. Who wants to pay a $3 coffee with a $5 fee attached?
With Lightning Network, you still have to pay two fees – one to open the channel and another to close it. But yourself and your partner can make thousands of transactions for free once this channel opens. Once done, you just need to publish the final state to the blockchain.
In the grand scheme of things, if more users rely on off-chain solutions like Lightning Network, block space will be used more efficiently. High frequency, low value transfers can be made in payment channels, while block space is used for larger transactions and channel opening/closing. This will make the system accessible to a wider user base, allowing it to scale in the long run.
Micropayments
There is a minimum amount of Bitcoins that you can deposit in a transaction – around 0.00000546 BTC. At the time of writing, that equates to about 4 cents. It’s a small amount, but the Lightning Network allows you to push the limits to trade the smallest unit available – 0.00000001 BTC or one satoshi.
Lightning is a lot more attractive for micropayments. Fees on regular transactions make it impractical to send small amounts on the main chain. However, in a channel you can send a fraction of Bitcoin for free.
Micropayments are suitable for many use cases. Some speculate that they could be a viable alternative to subscription-based models, where users instead pay a small amount each time they use a service.
Privacy
The side benefit of Lightning Network is that it can provide users with a high level of security. Parties do not need to make their channels known to the wider network. While you could look at the blockchain and say this transaction opened a channel, you wouldn’t be able to tell what was going on inside it. If participants choose to make their channel private, only they will know what transactions are going on.
If Alice has a channel with Bob, then Bob has a channel with Carol. At that time, Carol and Alice can send payments to each other via Bob. If Dave is connected to Carol, Alice can send him payments. You can imagine this expanding into a vast network of interconnected payment channels. In such a setup, you cannot know for sure to whom Alice sent money after the channel is closed.
How does the Lightning Network work?
We explained how the Lightning Network relies on channels between nodes at a high level. Now look under the hood.
Multi-signature address
An address multisignature (or multisig) is one in which many private keys can be reserved from. When generating a key, you specify how many private keys can use the funds and how many of them are needed to sign a transaction. For example, a 1/5 scheme means that five keys can generate a valid signature and only one key is needed. A 2-in-3 diagram will show that, of the three possible keys, any two are required to spend the money.
To initiate the Lightning channel, participants lock funds in a 2-in-2 scheme. Only two private keys have the ability to sign, and both are needed to move coins. Let’s bring our friends Alice and Bob back to this point. They will be making more payments to each other in the coming months, so they decided to open a Lightning Network channel.
This starts with both people sending, for example, 3 BTC each to a jointly owned multisig address. It should be repeated that Bob cannot move money out of the address without Alice’s consent or vice versa.
Now, they can only keep one sheet of balance adjustment paper on each side. Both have an initial balance of 3 BTC. If Alice wants to pay Bob 1 BTC, why not just note that Alice now owns 2 BTC and Bob owns 4 BTC? Balances can be tracked like this until they decide to move the money out.
That could happen, but where’s the fun? More importantly, does that make it incredibly easy for someone to not cooperate? If Alice ends up with 6 BTC and Bob doesn’t, Bob has nothing to lose by refusing to release the money (except perhaps his friendship with Alice).
Hash Timelock Contract (HTLCs)
The above system is boring and doesn’t offer much compared to today’s reliable setups. It will be much more interesting when we introduce a mechanism to enforce the “contract” between Alice and Bob. If one of the parties decides not to play by the rules, the other party still has the remedy to get their money out of the channel.
That mechanism is the Hash Timelock Contract (or HTLC). This term may sound difficult, but it is actually a fairly simple concept to grasp. It combines two other technologies (hashlocks and timelocks) to overcome any uncooperative behavior in payment channels.
A hashlock is a condition placed on a transaction that states that you can only spend money by proving that you know a secret. The sender hashes part of the data and includes the hash in the transaction for the receiver. The only way the receiver can use it is if they provide the original (secret) data that matches the hash. Besides, the only way they can provide the data is if the sender gives it to them.
A peg is a condition that prevents you from spending money before a certain time. It is specified as real time or specified block height.
HTLC is created by combining hashlocks and timelocks. In fact, HTLCs can be used to create conditional payments – the receiver must provide the secret by a certain time or the sender can claim the money back. This next section is probably better explained with an example, so let’s go back to Alice and Bob.
Channel opening and closing
We have given the example of Alice and Bob just creating funding transactions for the multi-signature address they will share. But those transactions are yet to be published to the blockchain! First, we need to do one more thing.
Remember, the only way those coins can move out of the multiblock is if both Alice and Bob sign the same transaction. If Alice wants to send all six coins to an external address, she will need Bob’s approval. She first made a transaction (six bitcoins to this address) and added her own signature.
She can try to broadcast the transaction immediately, but it won’t be valid because Bob hasn’t included his signature. Alice must give him the unfinished transaction first. It will become valid once he adds his signature.
We still haven’t put in place a mechanism to keep people honest. As we said earlier, if your partner refuses to cooperate, your money is literally stuck. Let’s explore the mechanism that prevents this. There are a few different moving parts, so bear with us.
Each side needs to come up with a secret – let’s call those As and B. They’ll be terrible secrets if Alice and Bob reveal them, so they’ll hide them now. This pair will generate ‘secret’ hashes – h(As) and h(Bs) respectively. Therefore, instead of sharing secrets, they share those hashes with each other.
Alice and Bob also need to create a set of committed transactions before they publish their first transactions to the multisig address. This will provide them with a remedy in case the other decides to hold the money hostage.
If you think of a small ledger-like channel we mentioned earlier, committed transactions are the updates you make to the ledger. Whenever you create a new committed trading pair, you rebalance the amount between the two participants.
Alice’s one will have two outputs – one that returns to an address she owns and another that is locked to a new multi-character address. She signed it and gave it to Bob.
Bob does the same – one output pays for itself, the other pays for another multisig address. He signed it and gave it to Alice.
Normally, Alice can add a signature to Bob’s transaction to make it valid. But you will note that these funds are being spent from 2 of the 2 blocks that we have not funded yet. It’s a bit like trying to spend a check from an account with no balance right now. Therefore, these partially signed transactions will only be usable when multisig is up and running.
The new multi-signature addresses (where destined for 3 BTC outputs) have some special properties. Let’s see the unfinished transaction that Alice signed and gave to Bob. The multisig output can be used under the following conditions:
- Both parties can cooperate to sign.
- Bob can use it on his own after a certain amount of time (due to our timing).
- Alice can spend it if she knows Bob’s secret B.
For the transaction Bob gives to Alice:
- Both parties can cooperate to sign.
- Alice can spend it alone after a certain time.
- Bob can spend it if he knows Alice’s secret As.
Remember that neither party knows the other’s secret, so 3) is not a possibility yet. Another thing to keep in mind is that, if you sign a transaction, your counterparty can spend it immediately as there are no special conditions on their output. You can wait for the time to expire to spend the coins on your own, or you can partner with the other party to spend them outright.
Okay! You can now publish transactions to the address with 2 of the original 2 signatures. It’s safe in the end because you can get your money back if your partner abandons the channel.
The channel will be up and running once the transactions are confirmed. That 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, the pair creates two new transactions to replace the first set. So did the drills – they were only half signed. However, Alice and Bob first give up their old secrets and trade the new hashes for the next round of transactions.
Either party can sign and broadcast one of the most recent transactions at any time to process it on the blockchain. But whichever party does so will need to wait until the time expires, while the other party can spend it immediately. Remember, if Bob signs and broadcasts Alice’s transaction, she will now have an output with no conditions.
Both parties can agree to close the channel with each other (close cooperation). This is probably the easiest and fastest way to get your money back on the chain. However, even if one party does not respond or refuses to cooperate, the other party can still claim their money back by waiting for the timeout.
How does Lightning Network prevent cheating?
You may have identified an attack vector here. If Bob currently has a balance of 1 BTC, what could prevent him from broadcasting an older transaction that he has more of? He got half signed transaction from Alice, he just need to add his signature and broadcast, right?
There’s nothing stopping him from doing that – except for the fact that he could lose his entire balance. Let’s say he completes it and broadcasts an old transaction that pays one coin to Alice and five coins to the multi-character address we mentioned earlier.
Alice gets her coin immediately. Otherwise, Bob has to wait until the time expires to spend from the multisig address. Remember the other condition we mentioned that would allow Alice to spend the same amount immediately? She needed a secret that she didn’t have at the time. She does it now – right after the second round of transactions was created, Bob gave out that secret.
While Bob sits, doing nothing while waiting for the time to expire, Alice can transfer the money. This penalty-based mechanism means that the participants don’t even intend to cheat as the peers will have access to their funds.
Routing Payments
We mentioned this earlier – channels can be connected. Otherwise, the Lightning Network will not be useful for payments. Do you really want to lock up $500 in a channel with a cafe 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 a channel with Carol, Bob can route payments between the two. This can work on multiple “hops,” meaning Alice can effectively pay anyone with a path.
For their role in routing, intermediaries may charge a small fee (although no obligation to pay). Lightning Network is still in its infancy, so the fee market has yet to materialize. What many expect to see are fees based on the liquidity on offer.
On the base chain, your fees are based solely on the space your transaction takes up in a block – the value transmitted doesn’t matter – the $1 and $10,000,000 payments are the same. In contrast, there is no such thing as block space in the Lightning Network.
Instead, get the idea of local and remote balances. The local balance is understood as the amount that you can “push” to the other end of the channel, while the remote balance is the amount that your partner can push to you.
Time for another example. Let’s take a closer look at one of the paths above: Alice <> Carol <> Frank.
The Alice <> Carol and Carol <> Frank each had a total capacity of 1 BTC. Alice’s local balance is 0.7 BTC. If they pay on the blockchain now, she will receive 0.7 BTC and Carol will receive the remote balance (i.e. 0.3 BTC).
If Alice wants to send 0.3 BTC to Frank, she will push 0.3 BTC to the Carol side of the channel. Carol then pushes 0.3 BTC from her local balance in the channel with Frank. As a result, Carol’s balance remains the same: +0.3 BTC from Alice and -0.3 BTC to Frank eliminate each other.
Carol doesn’t lose her value as Frank’s conduit, but she’s making herself less flexible. You see, she can currently spend 0.6 BTC in her channel with Alice, but only 0.1 BTC in her channel with Frank.
You can imagine a situation where Alice is only connected to Carol, while Frank is connected to a much broader network. Carol was previously able to send a total of 0.4 BTC to others through Frank, but now she can only push 0.1 BTC because that’s all she has at the bottom of her channel.
In this case, Alice is effectively eating into Carol’s liquidity. Without any form of incentive, Carol might not want to undermine her position. So instead, she could just say I would route every 0.01 BTC for a fee of 10 satoshi. This way, the more local balance Carol sacrifices in “stronger” paths, the more profit she makes.
As mentioned before, there is no actual requirement to charge. Some may not be interested in reducing liquidity. Others may just open the channel directly to the receiver.
Limitations of the Lightning Network
It would be great if the Lightning Network proves to be the solution to all of Bitcoin’s scalability problems. Unfortunately, it has its own cons that can get in the way.
Usability
Bitcoin is not the most intuitive system for beginners – addresses, fees, etc. can be confusing for you. But wallets can remove the complexities to offer users something akin to existing payment systems. You can have someone download a smartphone wallet, send them coins, and they can use it.
Currently, that is not possible with the Lightning Network. Options are limited when it comes to smartphone apps – in general, Lightning nodes require access to a Bitcoin node to be fully usable.
Once a customer has been set up, users also need to start opening channels before they can make payments. This can be a time consuming process and can be overwhelming when a newbie is introduced to concepts like inbound/outbound capacity.
That said, improvements are constantly being made to reduce barriers to entry and provide users with a more streamlined experience.
Liquidity
One of the biggest criticisms of the Lightning Network is that your ability to transact is limited. You cannot spend more than you have locked the channel. If you spend all your money so that the remote balance has all the channel funds, you will have to close the channel. Alternatively, you can wait until someone pays you, but that’s not ideal.
Your path may also be limited by the total capacity of the channel. Take the previous Alice <> Carol <> Frank example. If Alice and Carol have 5 BTC capacity in their channel, but Carol and Frank only have 1 BTC capacity, then Alice can never send more than 1 BTC. Even then, the entire balance would need to be on the Carol side of the Carol <> Frank channel for that to work. This can severely limit the amount that can be transferred along LN channels and therefore has a direct effect on usability.
Centralized hubs
Due to the problem mentioned in the previous section, there is some concern that the network will facilitate the creation of large “hubs”. That is, large, tightly connected entities with lots of liquidity. Any significant payments will need to be routed through some of these entities.
Obviously, that wouldn’t be a great situation. It will weaken the system, as these entities going offline will break the relationship between peers. In addition, the risk of censorship also increases because there is only a certain point where transactions are taking place.
Lightning Network Current Status
As of April 2020, Lightning Network should work fine. It boasts over 12,000 online nodes, over 30,000 active channels, and a capacity of just over 920 BTC.
There are several different node implementations – Blockstream’s c-lightning, Lightning Labs’ Lightning Network Daemon, and ACINQ’s Eclair are some of the most popular. For less technical users, many companies offer plug-and-play buttons. The only thing you have to do with these is power on the device and you are ready to go with the Lightning Network.
Closing thoughs
So far the mainnet launched in 2018, Lightning Network has seen impressive growth, despite many considerations it’s still in beta.
There are still some usability hurdles to overcome, as it currently requires some level of technical proficiency to operate a Lightning node. But given the level of development going on, we can see the barriers to entry have diminished over time.
If the issues can be solved, the Lightning Network could become an integral part of the Bitcoin ecosystem, significantly boosting scalability and transaction speed.