What is the Lightning Network?
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.
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.
Why is the Lightning Network necessary?
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.
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 yourself 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.
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.
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.
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.
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.
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.
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 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.
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’s 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.
How does the Lightning Network prevent cheating?
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.
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’ll 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 a thing as block space within the Lightning Network.
Users’ balance before and after a transfer of 0.3 BTC from Alice to Frank.
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.
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.
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.
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.
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 April 2020, the Lightning Network looks healthy. It boasts upwards of 12,000 online nodes, 30,000+ active channels, and just over 920 BTC in capacity.
Global distribution of Lightning Network nodes. Source: explorer.acinq.co
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.