Bitcoin 101: The Lightning Network
If you’re already familiar with the Lightning Network, you’ve witnessed its development unfold at breakneck speed.
If you’re not yet familiar with the Lightning Network, this edition of Bitcoin 101 will explain all the basics and give you one more reason to be excited about Bitcoin’s future.
While Bitcoin is a revolutionary technology, it has received heavy criticism regarding certain design choices. Perhaps the most frequently mentioned criticisms are Bitcoin’s ability to only process a handful of transactions per second, its approximate 10-minute transaction confirmation time (block time), and its potential for high transaction fees.
The Lightning Network is a payment system that sits on top of Bitcoin, and it offers solutions to many of these criticisms. We say “on top of” because the Lightning Network can transfer ownership of bitcoin without immediately being reflected on its base blockchain. These off-chain transactions are what allow for improvement in Bitcoin’s scalability, faster transaction finalization times, and lower transaction fees.
Off the Chain
When you hear “on-chain” or “off-chain,” this is in reference to the main Bitcoin blockchain.
An on-chain Bitcoin transaction is standard and straightforward. Party A sends bitcoin to Party B’s address in a transaction, miners propose a block containing that transaction to be added onto the blockchain, then the global network of Bitcoin nodes accept and validate the new block.
Every single on-chain transaction is subject to an average ten-minute block time. If I want to send you 1 BTC, it’ll take about ten minutes for first confirmation. If you want to send it back to me immediately after, it’ll still take about ten more minutes. Imagine paying for your coffee and then standing at the register for ten minutes hoping your transaction confirms.
While Bitcoin is amazing for storing and transferring value trustlessly, it’s not exactly conducive to quick payments. So how do we make faster payments while maintaining Bitcoin’s core security?
A Quick Detour to Metaphorville
The Lightning Network uses payment channels, which are somewhat similar to a bar tab.
When you are at a restaurant and you order a drink, you are opening a tab with the bartender (similar to a Lightning payment channel opening). You can then keep ordering drinks and adding to your bill regularly without final payment. When you’re ready to leave the restaurant, you settle your tab with the bartender and pay the final amount (similar to settling a final balance and closing your Lightning payment channel).
With the Lightning Network, the only transactions recorded on-chain are the transactions to open a new channel or close and settle an existing payment channel.
This is accomplished through the participation of Lightning nodes, and these nodes also serve as full Bitcoin nodes for validation. In fact, that’s what the network is—a system of interconnected Lightning nodes.
A payment channel is opened when one party’s Lightning node connects to another’s. To make a connection, one of the parties must first establish the maximum amount of bitcoin that can be sent within the channel at one time, sort of like a credit limit. This is what’s referred to as the channel capacity. The Lightning Network is still in development and currently limits individual channel capacity to 0.16 BTC. This limit will be removed in the future once the system is proven stable enough.
Once two nodes have established a connection, the owners of the nodes involved may begin sending funds back and forth at will, only limited by the channel capacity.
A More Practical Example
Bob wants to open a channel with Alice, so he connects to her node and sets a channel capacity of 0.1 BTC. Provided Bob has sufficient funds in his on-chain wallet, his node will broadcast a transaction of 0.1 BTC to the Bitcoin blockchain. As soon as that block is mined and the channel is opened, both Bob’s and Alice’s nodes see the balance like this:
Bob: .1 BTC
Alice: 0 BTC
If Bob sends Alice .05 BTC, their nodes will record a new balance of:
Bob: .05 BTC
Alice: .05 BTC
Now that Alice has bitcoin in this channel, she can start sending it back to Bob within that same channel. She might pay him .02 BTC, in which case their nodes would take note of the new balance:
Bob: .07 BTC
Alice: .03 BTC
Neither party can send more bitcoin than their current channel balance. I.e., if Bob sends Alice his remaining .07 BTC, he isn’t able to send more within that same channel until Alice sends some back his way (this is something that will be improved in the future, but that’s a topic for another post).
When one of the parties wants to stop transacting, their Lightning node will broadcast the latest balance to the Bitcoin network, and once that block is mined, the channel is closed. Since the latest balance was broadcasted to the network, each user’s bitcoin will show up in their respective Lightning node’s on-chain wallet.
Let's Recap
We just ran through a detailed explanation of how Lightning Network works. Let’s break down what just happened:
- Bob requests to open a channel with Alice by connecting to her node and specifying a channel capacity.
- The initial channel balance is broadcasted to the blockchain as an on-chain transaction.
- Bob and Alice begin transacting off-chain via their Lightning Network channel.
- Bob and Alice are finished transacting and request to close the channel.
- The final balance is broadcast to the blockchain as an on-chain transaction.
An Even More Practical Example
Two users sending bitcoin back and forth isn’t actually a very common scenario at this point in time. What’s more common is the type of example you’ll see many other explanations start out with: the classic coffee shop scenario.
In this example, Alice opens a channel with her local coffee shop and begins exchanging bitcoin for coffee on a daily basis until she reaches the limit defined by the channel capacity. This is all well and good, but what if I told you Alice doesn’t actually need to open a direct channel between herself and the coffee shop in order to pay for her coffee? This is where the real magic of the Lightning Network comes into play.
Indirect Payments
The Lightning Network is able to route payments through any sequence of pre-established channels. Let’s pretend, for example, that Alice does NOT have a channel open with the coffee shop. Instead, Alice has a channel open with Bob, who has a channel open with Eric, who has a channel open with the coffee shop.
Alice can still pay the coffee shop because the Lightning Network will route her payment through Bob, on to Eric, and finally to the coffee shop. Each time a payment is routed through a new channel is known as a hop, and the protocol will automatically look to route a payment using the fewest amount of hops.
The best part is: you don’t have to know the node owners facilitating the transfer of your payment. Alice may not know or care who Eric is—all she cares about is that the network successfully routed her payment to the coffee shop. This is all handled with built-in encryption that keeps Eric or Bob from knowing the exact details of Alice’s coffee shop purchase, so Alice’s privacy is maintained.
With the right channels open, you can pay almost anyone in the Lightning Network! That means no worrying about requesting a direct connection, setting a channel capacity, or waiting for that initial on-chain transaction to confirm your channel opening. As long as there’s a path from point A to point Z with a great enough channel capacity to handle your payment, it’ll make it there in a matter of seconds.
How cool is that?
The Lightning Network makes using bitcoin for smaller transactions exponentially more realistic by alleviating issues of scalability and costliness. This article only skims the surface. Stay tuned for more articles diving even deeper into the Lightning Network!