Catching Lightning In a Bottleneck: A Breakdown of the Practical Limits on Bitcoin Payment Channels

In this article, I’m going to analyze the best-case scenario for Bitcoin and the Lightning Network (LN) assuming that the ~1MB (really ~2MB with 100% SegWit adoption) block-size limit doesn’t change.

I will be making some assumptions in order to conduct this analysis, but each will be stated clearly. If you disagree with my analysis or find a mistake in it, please let me know so that I can improve/correct it.

Note that I’m not analyzing the merit of the Lightning Network or off-chain scaling in general as a trustless, censorship-resistant scalability solution. The point of this article is simply to find out what would happen in the future if both Bitcoin and the Lightning Network were to achieve significant mainstream adoption with the current block size.

If you aren’t familiar with how the Lightning Network works, read this article before continuing: Lightning Network, Explained.

Ready? Alright, let’s start with some context.

Current State of Bitcoin, the Lightning Network, and the Scalability Debate

The Lightning Network initially launched with some fanfare in March 2018. It grew very slowly at first, but has started to really pick up steam of late, reaching $2 million capacity in November.

Meanwhile, Bitcoin Cash has gone through a bit of a rough patch, to put it kindly. Thanks to the hash war initiated by Craig Wright and Calvin Ayre, BCH has hit a new all-time low value relative to BTC as of writing.

While the ABC camp won the BCH ticker, make no mistake about it: both sides lost in this war.

Examining these recent events in a vacuum, one would think that the “small blocks” argument is winning out. And, indeed, it may be.

However, the bear market has taken its toll on transaction volume, and Bitcoin is not being used as much today as it was a year ago.

Supposing that the trend of gradually increasing transaction volume that began around April continues, how much longer will it be before the memepool is filling up and transaction fees are rising again?

Also considering that it’s been 18 months since the last time that less than $500 million worth of BTC was transferred in a day, the Lightning Network’s $2 million capacity is still far from being able to make a noteworthy difference in reducing the load of on-chain transactions.

But let’s forget about all that short-term thinking for a while, and imagine a scenario in which the Lightning Network has grown into a robust and widely adopted solution for private, instantaneous, and cheap transactions.

On-Chain Burden of a Robust Lightning Network

Alright, now comes the fun part: the analysis.

The question we need to answer first is: How often would the typical person need to open and close payment channels (i.e. transact on-chain) if they used the Lightning Network for all retail and small day-to-day transactions?

Let’s start by laying out some assumptions for the best-case scenario of the LN.

• Assumption 1: Almost every Bitcoin merchant and user is connected to the Lightning Network and the network of payment channels is robust enough to facilitate just about every small and moderate-sized transaction people would want to use it for. This is not very realistic… at least not for the next couple of years.
• Assumption 2: Anybody who doesn’t live “paycheck-to-paycheck” would not store the majority of their Bitcoin in a Lightning Network wallet/channel.

Keeping those 2 assumptions in mind, I think that it’s reasonable to guess that the average person would need to open and close a payment channel about twice per month. The other factor that led me to settle on that figure is the reality that most people are paid twice per month by their employers.

Paydays seem like a convenient time to distribute funds between savings/investments (i.e. Bitcoin, tokenized securities, other cryptocurrencies, etc.) and spending money (i.e. Lightning Network).

Assuming that those paydays themselves are also occurring on-chain with Bitcoin because they are rather large transactions, that brings the total transactions per month per person up another 2.

So for the sake of performing this analysis, I’m going to assume that the typical person opens and closes payment channels twice per month and has 2 other on-chain transactions, for a total of 6 on-chain transactions each.

I still see this as an extremely low estimate for a number of reasons, including that many other larger-value transactions (e.g. mortgage or rent payments) would also more likely occur on-chain. But I’m analyzing what I see as the absolute best-case scenario, so I’m going to go with 6 tx/month as my baseline figure.

Finally, to determine how that transaction volume translates to block-size requirements, we need to make a couple more assumptions:

• Assumption 3: The average transaction is 250 bytes (see Gavin Andresen’s comment in this bitcointalk thread). This is a best case scenario assumption, as transactions to open and close payment channels are larger than 250 bytes in reality.
• Assumption 4: A block with only 1 transaction (the block reward) is 260 bytes (see this empty block mined by AntPool).

Below, you’ll find a table calculating the Estimated Block Size Requirement for various active user numbers ranging from 1 million to 1 billion.

“Transactions per Block” = (On-Chain Txs/Second)*(60sec)*(10min)

“Estimated Block Size Requirement (MB)” = [260 + (Transactions per Block)*250]/106

Note that these assumptions seem to be extremely generous when compared with real-world transaction data.

When Bitcoin’s blocks were completely full and the memepool was growing at the end of 2017, the average transactions per block peaked at just under 2,750.

Average block size at the time was around 1.1MB, which indicates that approximately 2,500 transactions can fit per MB of the block. However, a look at more recent data indicates that a 1.2MB block with more SegWit adoption holds just under 2,500 transactions (compare November 21, 2018 here and here).

That’s simply to say that the assumptions I’ve made may not have been very good, and that a block-size requirement estimate based on recent data would likely be about twice as high as the estimates in the table.

On the other hand, there is a lot of innovation happening that I also haven’t accounted for.

For example, a paper titled Scalable Funding of Bitcoin Micropayment Channel Networks describes a method that could potentially reduce the amount of on-chain transactions needed for a large population to use the Lightning Network through off-chain channel funding.

Just as people struggled to conceptualize how the internet could possibly scale in the early 90’s, it’s quite difficult to look far into the future for Bitcoin and conceptualize how it will scale by means other than block-size increases and 2nd-layer solutions that are already known… but that doesn’t mean that new solutions won’t be created in the future that change everything.

With all of that being said, I’ll continue with my 2x-too-low estimates. After all, I’m analyzing the best-case scenario.

So… where does that leave us?

What Happens if the Bitcoin Block Size Never Increases?

Remember, in our hypothetical future world, the Lightning Network is working marvelously.

Millions of people use it everyday for small transactions and microtransactions, and just about all such transactions can be facilitated through major hubs in the payment channel network.

If we assume that each one of those happy, active users only transacts on-chain 6 times per month and that nobody else is using Bitcoin, we wouldn’t need a block-size increase above 2MB until there are about 5 million active users.

By the time there are 10 million active LN users, the block size would need to be around 4MB minimum. The jump to 8MB would need to happen around 20 million active LN users.

Continuing on, the increase from 8MB to 16MB would need to happen before there are 50 million active LN users, and the next one to 32MB would need to happen before there are 100 million LN users.  

It is possible that people would only open and close channels once per month or even less frequently. But I think this analysis illustrates that even with some very favorable assumptions, the Lightning Network will not prevent a block size increase from being necessary in the future if Bitcoin achieves mass adoption.

If that block size increase never occurs? Well, fees will skyrocket, the memepool will get deeper than the depths of the Pacific Ocean, and nobody will be able to afford to open and close payment channels to use the Lightning Network in the first place.

More importantly, the high cost and wait times for closing channels will wreak absolute havoc on the trustlessness of the Lightning Network due to the game theory involved.

Whenever somebody closes a payment channel, there’s a waiting period before the settlement occurs on-chain in which the other party from the channel can verify that the most recent balance has been posted. If an outdated balance is posted, the other party can post a more recent balance and claim the full value of the channel.

This is a mechanism that disincentivizes people from posting outdated balances. But, if it’s extremely difficult to get a transaction confirmed within that waiting period, more people will have the incentive to try posting outdated balances so that they can double-spend their coins.

In other words, the importance of low wait times and fees for on-chain transactions is only amplified further by a large population using the Lightning Network.

Ultimately, if that scenario plays out, Bitcoin will lose market share to cryptocurrencies that scale more effectively.

Looking to the Future (Opinion)

It’s possible that many of you reading this haven’t seen an analysis of block-size requirements before. But I’m confident that none of this is new to Bitcoin developers, and especially not to anybody in the Bitcoin Cash community.

A block size increase appears inevitable so long as more people continue to use Bitcoin, and I’d guess that the increase will likely occur by 2020.

Personally, I’d like it to occur as soon as possible in anticipation of the 2020 block-reward halving and the next big bull run, as that will most likely be a critical time in achieving mainstream adoption if Bitcoin is ever going to do so.

Both the Bitcoin and Bitcoin Cash communities are full of many brilliant people, and it’s a shame that some from both sides waste their mental equity attacking each other.

In particular, I hope that anybody who has been calling Bitcoin Cash a scam can realize that on-chain scaling is inevitable even if LN works well, and that — however you feel about them personally — most Bitcoin Cash supporters simply wanted it to happen before fees and wait times got outrageously high.

Many compelling arguments have also been made for why LN simply won’t work, and while I disagree with them, I do think everybody who participates in the discussion ought to seek some of the arguments out and consider the points being made.

How Bitcoin will scale to serve millions and eventually billions of people remains uncertain, but I’m optimistic that it will happen, just as the internet scaled against all odds in the decades past.

In the end, the market will determine which scaling solutions win, as the market decides all.

What do you think about the Lightning Network as a scaling solution for Bitcoin? Is a block size increase inevitable for Bitcoin’s mass adoption? Share your thoughts with us in the comments below.