The Bitcoin Lightning Network is an independent solution that’s heralded as the solution to all problems keeping Bitcoin from mainstream adoption. It claims to solve the bleak scaling problem, make instant transactions, keep transaction fees minuscule, and take your transactions off the blockchain. How can a system independent of core Bitcoin offer these improvements? How can it violate the coventional rules of Bitcoin by offering secure transactions with zero confirmations? What is the Bitcoin Lightning Network?
In this article, we’ll explore what the Bitcoin Lightning Network really is, how it can make the guarantees it provides, and its current state.
Note: This article assumes familiarity with Bitcoin. If you’re unfamiliar with how cryptocurrencies work or need a refresher, read Cryptocurrency for Dummies: Bitcoin and Beyond.
Prerequisite: The Bitcoin Scaling Problem
If you’re aware of the Bitcoin scaling problem, feel free to skip this section, but if you aren’t, or need a refresher, read on.
Bitcoin has a scaling problem. Bitcoin is designed to store all transactions in a data structure called a block. A block contains information about the previous block, miscellaneous data about mining rewards, and most of the block is just transaction data. Blocks are also fixed at a maximum of 1 MB in size. This last bit is where the trouble is.
Because blocks are 1 MB in size, and a block is created every 10 minutes, assuming the transactions are not SegWit (coming up later) the network can process a maximum of between 3.3 and 7 transactions per second. For a currency designed for mass use by billions of humans and their machines, 7 transactions a second just isn’t up to par. Visa, on the other hand, claims to be able to process 24,000 transactions per second.
As the number of transactions starts to increase, your individual transaction competes with every other for inclusion inside a limited block space, and so, the likelihood of having yours included in the block starts to decrease. Since miners can arbitrarily decide which transactions to include in a block, on these occasions, the only way to incentivize the miners to include your transaction is by increasing your transaction fee. However, this starts to make transactions prohibitively expensive—such as this 192 byte transaction for $92.98 where the transaction fee was $14.86.
So, how do we “scale” Bitcoin? There are three major schools of thoughts or—as I like to call them—battles of the Great Scaling Bitcoin Flamewars:
- Increasing block size: 2X, 8X, …, ∞X
- Smaller transactions: SegWit et al.
- Sidechains: the Bitcoin Lightning Network
Increasing Bitcoin Block Size
This one is fairly simple to understand: If the block limit of 1 MB is the problem, make it bigger! The debate on this was fierce and still rages on. Eventually, on August 1st, 2017, Bitcoin (BTC) was forked and Bitcoin Cash (BCH) was born. The major difference between the two is that BCH has 8 MB blocks. This keeps blocks mostly empty and fees very low.
However, 8 MB blocks mean the total BCH blockchain size will likely increase at a much faster rate, making storage costs a significantly higher barrier to entry in the miner scene. The argument is that this would reduce the total number of miners, which also secure the blockchain, reducing decentralization and the overall security of the Bitcoin network.
Another criticism of larger blocks is that doesn’t solve the problem itself; rather, it temporarily patches the problem. There will always be a maximum limit with larger blocks, and the maximum limit will always much less than the target limit we’re trying to achieve: 24,000 transactions per second. Even with its larger 8 MB blocks, BCH has a limit of 61 transactions per second.
Smaller Transactions: Segregated Witness
Other solutions point out that the current transaction format isn’t the most efficient and aim to pack more transactions in the same block. The most notable of these is called Segregated Witness (SegWit), proposed via BIP 91 and activated in block 481824 on August 25th, 2017. SegWit is now a part of Bitcoin, rejoice!
SegWit takes signature data from transactions and stores them in a separate structure from the transaction block, thereby making individual transactions smaller and making better use of the limited space within each block. This structure is then optional when syncing the blockchain, leading to a reduced size on disk omitted.
This also results in a solution to the transaction malleability problem, and transactions that only spend SegWit outputs are no longer vulnerable.
The Bitcoin Lightning Network
The Lightning Network is a second-layer network that transmits signed, but unbroadcast, transactions among peers and relies on the Bitcoin blockchain only for final settlement of funds. This means that transactions aren’t limited to the block size at all, confirmation times are irrelevant, and the Bitcoin blockchain doesn’t need to store every transaction that ever happens.
Who developed the Bitcoin Lightning Network? It was first described in a white paper authored by Joseph Poon and Thaddeus Dryja but has since evolved into a community effort with third-party individuals and even companies contributing to specifications and implementations.
More information later on.
SegWit vs. Increased Blocksize vs. Bitcoin Lightning Network
Which is the best, then? I have no empirical evidence to base my answer on, so this is an opinion: While I do think better use of block space (à la SegWit) is a good thing to have, I think an increase in block size would be like pushing the goalpost to the future. If Bitcoin use were to increase substantially, we’d find ourselves right at the start debating about another increase in block size.
Disagree? Leave a comment below!
With that said, while I think an alternative settlement network like Bitcoin Lightning is a wonderful idea, I’m also waiting to see how it works out in the real world. As of right now, it’s not really in the state my father and I could use.
The Bitcoin Lightning Network Explained
I’ve already mentioned that the Lightning Network is a second-layer network that transmits signed, but unbroadcast, transactions among peers and relies on the Bitcoin blockchain only for final settlement of funds.
Let’s take a look at how this would work in real life.
Lightning Nodes and Channels
A Lightning node runs much like and unlike a Bitcoin node in that it operates in a networked fashion, validates transactions, and communicates with other nodes, but it does things that Bitcoin nodes historically do not: it holds funds, act as an automated financial intermediary, actively monitors Lightning “channels” for malicious behavior and reacts defensively (this is explained in detail later), etc.
To carry out these functions, nodes need money.
Note: These examples initially assume everyone runs a Bitcoin Lightning Network node that’s connected to the internet 24/7, which will obviously not be the case. This assumption will be broken in the Lightning Wallet vs. Lightning Node section.
Creating a Lightning Channel
Suppose you and your friend Bob have a relationship which involves a fair amount of financial transactions. You hang out together every now and then for lunch or watch a movie. Sometimes one of you is short on cash, and sometimes the other and you usually end up Venmo-ing each other afterward.
However, being crypto advocates, you both decide to try Lightning and create a new mutual channel that you fund equally with half a bitcoin each (that’s a lot of lunches).
Creating a new Lightning channel is like creating a multi-signature bitcoin wallet that requires both of your signatures to approve a transaction, but with one difference; you each get a signed, but as-yet unbroadcast, “Commitment Transaction”, as per the Lightning Network white paper, that returns your initial deposits back to you. This way, if your friendship goes through a rough patch, or either of you needs the money, you can unilaterally close the channel by broadcasting this transaction and everyone gets their rightful amounts.
Making Lightning Transactions with People You Have Channels To
Say you go out for lunch again one day and you end up owing Bob the equivalent of 8,000 satoshis (0.31 USD as I write this). At this time, if you use Bitcoin to settle this amount, you’d end up paying 0.10 USD and waiting an hour, making it infeasible.
With Lightning, however, you can do this for free by simply replacing your “Commitment Transaction” with a new transaction for you both to hold on to. Only this time, Bob has 8,000 satoshis more, and you have less. (If you’re thinking of cheating by broadcasting the old transaction at this point, wait until the section on Closing a Channel.)
You could broadcast the transaction and close the channel, however, closing the channel would incur transaction fees, and since neither of you needs the amount immediately, you can simply hold on to the channel and use it to settle future debts.
Making Lightning Transactions with People You Don’t Have Channels To
Say one day, Bob invites another one of his friends, Alice, and after an intense hour of eating sandwiches, you’re both indebted to Alice because the shop only accepted Coinye (a defunct cryptocurrency abandoned after Kanye West sued), which Alice happened to have.
Now, assuming Bob has a channel open with Alice, with Lightning, you can also pay Alice via Bob. Your node calculates the optimal route between you and Alice—in this case, with Bob as the financial intermediary—and the middlemen can all pay money forward, with a small fee if they choose.
Closing a Channel: Two Good Ways and a Bad Way
There are three ways to close a Lightning Channel:
- Collaboratively: Any one of the parties in the channel initiates the closure of a Bitcoin Lightning channel and the other approves. There is no time lock, and the money is ready to spend as soon as the approval is confirmed. This is the “best” way to close a channel.
- Unilaterally: Any one of the parties in the channel can close a Bitcoin Lightning channel when one of the parties desires, even if the other party does not approve. This results in a time-lock where the other party can dispute the closuree with a “Breach Remedy” transaction (see scenario 3 below), but let’s assume that doesn’t happen. After the time-lock expires, the funds are free to use. This is an “acceptable” way to close a channel.
- Breach Remedy: Since lightning transactions are a timestamped list of signed transactions where the split of funds varies, it is possible for one party to attempt to cheat (breach trust) by unilaterally closing a channel with an old transaction where they hold more funds (see scenario 2). This results in a time-lock, and during this period, the aggrieved party can not only recover their own funds but swipe the entire capacity of the channel using a “Breach Remedy” transaction, as described in the Bitcoin Lightning Network white paper.
Lightning Node vs. Lightning Wallet
In the example above, we used the term Lightning “node,” which would make you think you’d have to keep your node up and running 24/7 on the internet. And yes, you’d be correct. The Lightning Network is designed so that nodes are always online, ensuring that the network operates close to maximum capacity. And, if no one is online to monitor a cheating attempt and it succeeds, the channel will close much like a regular unilateral close, leaving you without your funds.
However, the Lightning Network white paper describes a remedy to this problem:
…one should periodically monitor the blockchain to see if one’s counterparty has broadcast an invalidated Commitment Transaction, or delegate a third party to do so. A third party can be delegated by only giving the Breach Remedy transaction to this third party. They can be incentivized to watch the blockchain broadcast such a transaction in the event of counterparty maliciousness by giving these third parties some fee in the output. Since the third party is only able to take action when the counterparty is acting maliciously, this third party does not have any power to force close of the channel.
These third parties are often called watch towers and should remove the always-online burden from users.
The State of the Lightning Network
The Bitcoin Lightning Network as of March 27, 2019:
- Has over 7.5 thousand nodes
- Has almost 40 thousand open channels
- A little over 1 thousand BTC in capacity
It’s growing at a rate of:
- 25 nodes an hour
- 304 channels an hour
There are plenty of Lightning Network node implementations, even an Eclair Lightning Wallets out on the Play Store. It’s still experimental, lacks polish and the important feature of receiving funds, but in my opinion, while the eco-system is small, it is growing healthily.
Specifications and Implementations
The Bitcoin Lightning Network specification is in Request for Comments (RFC) status and is constructed of a series of documents called Basis of Lightning Technology (BOLTS). The BOLTS are constantly changing as of this publication and welcome contribution.
There are also several BOLT compliant implementations of Lightning Network nodes:
- LND: Short for Lightning Network Daemon, this is a primarily Go-based implementation.
- Eclair: A primarily Scala-based implementation.
- C-lightning: A primarily C-based implementation.
For more resources, see the conclusion of this article.
Advantages and Criticisms of the Lighting Network
So what can we achieve with the Lightning Network?
- True micro-transactions (fractions of cents)
- Lowest fees imaginable (fractions of cents)
- A degree of privacy (no blockchain records)
However, as I said before, there are a number of criticisms of the Lightning Network, some of these are valid and present yet unsolved challenges Lightning faces:
- Routing and centralization: Since the Lightning Network is in constant flux with channel states changing, opening and closing every day, and there being centralized store of history to fall back to, payment routes need to be calculated afresh every single time. This is great when the network is small, but when it gets large enough, your small node running on tiny hardware just might not have the processing power to calculate the route. The solution to this problem may be a centralized supernode with advanced knowledge that you can query. This is described in greater detail here.
- Too much lending: Best described in this post, which even got Vitalik Buterin, the co-founder of Ethereum, to chip in. This essentially says that since a chain of 10 hops to pay $10 requires everyone to pay $10 forward, you’d end up moving $100 in funds. At one point, moving large quantities become infeasible. Whether this holds true or not in the real world has yet to be determined, but this is a compelling argument nonetheless.
Did I miss any criticisms? Please let me know in the comments below.
Further Readings & Resources
I hope you finally understand what the Lightning Network really is. Underneath it all, it’s just a messaging system grounded in exchanging cryptographic tokens. It isn’t perfect or widely usable yet, but that doesn’t mean it isn’t an impressive piece of engineering.
I recommend reading the original Bitcoin Lightning Network white paper. I could also recommend a list of further readings and applications, books, and papers, but GitHub user Ben Congdon’s already gone ahead and done that so I recommend checking out
bcongdon/awesome-lightning-network. Thanks Ben! As a Bitcoin developer, you owe it to yourself to read as much as possible about this new technology.
If all that was too much information, let’s end this on a fun note. Here’s a fun video of purported Satoshi Craig Wright attempting to talk about the good ole days of bitcoin.
Understanding the basics
The Lightning Network uses a network of nodes that hold funds in multi-sig wallets (“channels”) and exchange signed, but unbroadcast, transactions.
The Lightning Network is a second-layer network that transmits signed but unbroadcast transactions among Lightning peers, and relies on the bitcoin blockchain only for final settlement of funds.
Yes, it is live and you can see network statistics at 1ml.com
Yes, the Bitcoin Lightning Network is decentralized just as Bitcoin is, with no trusted third parties.
It was first described in a white paper authored by Joseph Poon and Thaddeus Dryja but has since evolved into a community effort with third-party individuals and even companies contributing to specifications and implementations.
I am Satoshi Nakamoto.