A Beginner’s Guide to Bitcoin’s : Key Takeaways :- Layer 2 solutions were created to address the inherent scalability limitations of blockchain technology.
Lightning Network is a layer 2 scaling solution that offers fast transactions without the need for block confirmation, enabling efficient micropayments.
It ensures secure and scalable payments via multisignature addresses and Hash Timelock Contracts.
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 runs on top of a blockchain to facilitate fast peer-to-peer transactions. It’s not exclusive to Bitcoin – other cryptocurrencies have integrated it.
You might be wondering what we mean by “runs 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 for you and another 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 15+ 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 too many users broadcast transactions simultaneously, the average fee can rise significantly. There were multiple occasions where it exceeded $10. At the height of the 2017 bull market, it exceeded $50. In April 2021, the average Bitcoin transaction fee surpassed $60.
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 $10 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 38 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.
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 secrets 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 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.
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 condition 3 is not 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 are confirmed, 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.
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. Otherwise, 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 caffeine 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.