mrb's blog

The case for increasing Bitcoin's block weight limit

Keywords: bitcoin blockchain blocksize scalability debate

March 2017 was a significant moment for Bitcoin: the average block size bumped into the 1MB limit, stunting the growth of the transaction rate ever since. Many arguments are made about how to increase capacity (changing the limit, developing off-chain solutions, etc.) However very rarely are discussions centered around facts and data such as estimating the impact of the stunted growth so far and the urgency of the situation. Also troubling is the widespread misconception that the activation of segwit on August 24th has given Bitcoin short-term relief.

In reality, I estimate Bitcoin missed the opportunity to process over $20 billion of transactions. Low segwit adoption keeps the network seriously congested to this day: over 90% of blocks are over 90% full. And given the current rate of increase of segwit adoption, the network will likely remain congested for the foreseeable future.

This post is not about segwit2x, a grassroots change initially proposed by Sergio Demian Lerner on bitcoin-dev to double the block weight, and which is supported by signatories of the New York Agreement. Although I support it myself, segwit2x is a complex topic that deserves its own blog post. Rather, the goal of this post is only to demonstrate the impact of congestion and the urgent need to increase the block weight limit in one way or another (not necessarily segwit2x.)

Average block size

Let’s start with a chart showing the average block size over the last 3 years:

Stunted growth

Up until March 2017 the transaction rate growth was predictible. Had there not been a 1MB limit, it seems the market demand for transaction capacity would have been for approximately 1.2MB blocks today. By failing to capture an extra 0 to 0.2MB of transactions, that is 0 to 20% extra transactions through the period March to October (daily transaction volume of $300-1000 million) Bitcoin failed to capture $20 billion worth of transactions over the last 7 months.

Mempool

I have to touch the subject of the mempool because the human—not technical—dynamics that affect its functioning are often misunderstood.

It is a mistake to think that “if the mempool is not growing, then Bitcoin is not congested.” When congestion begins, the mempool starts growing, some transactions in it are delayed 1 day, 2 days, 4 days… eventually some users lose patience and avoid sending transactions (Bitcoin fails to capture them), hence reducing pressure on the mempool, which starts shrinking until it is back to normal or even empty. And the cycle repeats immediately: users send more transactions, the mempool grows, they lose patience, and avoid Bitcoin, etc.

Under perpetual congestion conditions the mempool will never grow indefinitely.

Segwit

I hear you say “but segwit allows up to 4MB blocks, so the problem is solved, right?

No! Segwit replaced the 1MB size limit with a 4M weight limit. Therefore the size of blocks in bytes is no longer relevant to estimate the level of congestion. Instead we need to look at the weight of blocks in weight units. For example average blocks of 1MB/4M weight would indicate congestion, while larger blocks of 1.5MB/3M weight would indicate no congestion.

The weight of blocks is a crucial metric, yet I am not aware of any Bitcoin statistics site that charts it. Not even segwit.party (even though weight data is present in their JSON file.) It is almost as if segwit proponents who believe segwit will solve scalability wanted to hide how congested the network really is…

So I charted the data for the last 1000 blocks as I am typing this (blocks 490698 through 491697, roughly October 19th-25th):

Over 90% of blocks are over 90% full

913 out of the last 1000 blocks have a weight greater than 3.6M (90% of 4M), in other words over 90% of blocks are over 90% full. This is a clear sign that congestion is still seriously impacting Bitcoin. And the direct cause of this congestion is low segwit adoption which sits at only 8% two months after activation:

Segwit adoption rate

(Opinions abound as to why it peaked at 17% and fell to 8%. Some claim a group was faking segwit adoption by spamming the network.)

An argument I sometimes hear is that “there is no severe congestion, because if there was, segwit adoption would increase more sharply.” This is flawed reasoning because other factors—independent of congestion—slow down segwit adoption: wallet software and services are not upgraded to use segwit by default, users are unaware of how to use segwit or why they need it, etc.

As a result, the average block size was only able to grow by a paltry few percents from 1MB to 1.02-1.04MB in two months, significantly undersupplying the market demand (which seems to be for approximately for 1.2MB blocks, see above.)

Market share

So Bitcoin blocks have been full since March. What else happened in March?

Bitcoin market dominance

Bitcoin lost market share, from 85% down to 55%. In my humble opinion, the coincidence of the drop starting exactly in March is a sign that the congested network was the direct cause of Bitcoin’s loss.

This could be explained by one theory: users being fed up with the congested network and high transaction fees, and moving to altcoins with less congestion and lower fees.

Altcoins

Interestingly, data points seem to support this theory. The transaction rate of Ethereum, Litecoin, and Dash (and maybe others) also started increasing in or around March 2017:

Ethereum transaction rate

Litecoin transaction rate

Dash transaction rate

If anything, this is more evidence potentially validating the theory that some users are abandoning Bitcoin for altcoins due to congestion.

Another explanation about why Ethereum’s transaction rate went up so sharply is because of the ICO boom. However ICOs are hardly responsible for all of it, and they do not explain the rise in Litecoin and Dash which are much less often used to fund ICOs.

Notice that Ethereum already processes 450k transactions daily, which is 70% more than the 260k processed by Bitcoin… This might be a slightly unfair comparison because unlike Ethereum, some Bitcoin transactions are batched. To be more correct we should compare the number of Ethereum transactions to the number of Bitcoin transaction outputs (and for transactions with 2 or more outputs, subtract 1 because one of them is likely the change output.) However batching is not that common so the comparison between the number of Ethereum and Bitcoin transactions is mostly valid.

Pragmatism vs. idealism

How do we resolve Bitcoin’s congestion? Instead of increasing the block weight limit, I think we all agree more ideal solutions would be the Lightning Network, Mimblewimble, transaction batching, etc.

However these solutions are either not ready or not practically usable at scale today.

In essence this is the root cause of the scaling debate: the community is divided between big blockers who want a pragmatic quick fix, and small blockers who are more idealistic.

Decentralization

Will increasing the block weight limit hamper decentralization? I do not believe so.

Firstly, the amortized cost of running a full node is only $5 per month, an amount small enough that running one is within reach of enough individuals to protect decentralization.

Fun comparison: the average transaction fee right now is over $3, therefore running a full node costs less than the fees for sending 2 Bitcoin transactions a month.

Secondly, history shows that as blocks have grown over the last 2 years from 0.5 MB to 1.0 MB the number of full nodes has in fact increased, helping decentralization. That is because bigger blocks = more Bitcoin adoption = more individuals interested to and able to run full nodes. Generally speaking we can expect the number of full nodes to increase as blocks become bigger (up to a certain point.)

Increased node count

Conclusion

It is easy to get distracted by all the good news Bitcoin has been receiving lately: all-time-high price around $6000, a lot of venture capital injected into Bitcoin companies, etc. However this rapid success could disappear just as quickly if Bitcoin fails to increase its capacity soon.

Segwit is too little too late: some users not adopting it are causing congestion for all users. We needed solutions to scale in March 2017. We needed segwit activated a year ago so adoption would be at 50%+ today. We needed all this before Bitcoin already failed to capture $20 billion worth of transactions, lost 30% of market share, and lost hundreds of thousands of transactions daily to altcoins…

Bitcoin needs a pragmatic fix, a one-time reasonable increase of the block weight in order to relieve congestion right away and give us some breathing room. We can do this while keeping the costs to run a full node low ($5/month) and the network decentralized.

Comments

mugen wrote: Well-written and supported with hard data. Thank you for sharing. 26 Oct 2017 23:26 UTC

fresheneesz wrote: This article has good points, but its analysis of decentralization is woefully unthoughtful. It completely ignores the primary argument of block propagation time. I wrote about that here: https://np.reddit.com/r/Bitcoin/comments/74t4ua/an_explanation_of_why_the_block_size_debate_is/ 27 Oct 2017 04:27 UTC

cryptohawk wrote: Great write-up. Dumped BTC for BCH a while ago... 27 Oct 2017 11:12 UTC

mrb wrote: fresheneesz: Block propagation is a non-issue. Most discussions about it (including yours) ignore or predate Compact Blocks which pretty much solved the problem. A nominal 1 MB block is propagated in a compact block as small as 15 kB. See BIP 152 27 Oct 2017 15:17 UTC

nucino wrote: As you say real cause is low segwit adoption, and many major exchanges didn't even implemented segwit, also current mempool statistics doesn't seem to fit this narrative. 29 Oct 2017 22:33 UTC

mrb wrote: nucino: the point is we can't artificially increase segwit adoption, so some users not adopting it are causing congestion for all... Also your exact mempool argument is already refuted, read the Mempool section. 30 Oct 2017 17:51 UTC

fmarcosh wrote: Is the best article I've read in bitcoin scaling issues. Thank you for sharing. 02 Nov 2017 18:39 UTC