Scaling Bitcoin: The Great Block Size Debate

Brian Armstrong
The Coinbase Blog
Published in
10 min readJan 3, 2016

Bitcoin has been roughly doubling each year (in terms of the number of transactions). But in its current form, the network can only support up to 7 transactions per second. Paypal does about 100 transactions per second and Visa does about 4,000 per second, so some changes will need to be made if bitcoin is to reach these levels.

Luckily, bitcoin has a built in upgrade mechanism with an elegant design. If a majority of bitcoin miners “vote” for a particular upgrade then by definition this is the new version of bitcoin. The number of votes each miner gets is proportional to the amount of computational power they are adding to the network (so votes can’t be faked).

Although Coinbase is not a miner (the only real “vote” we have is perhaps in the court of public opinion), we decided to start experimenting with some of the proposed upgrade paths since we will need to be ready in the event one of them is used. We also did it to show our support for scaling bitcoin, and encourage things to move forward, since we’d like to see a solution sooner rather than later.

Why so angry?

Some people didn’t like this. For some reason, scaling bitcoin has become a hot button issue in the community. My tweet, which was being discussed on the bitcoin sub-reddit, was censored by the mods there (since it seems they don’t like the particular solution we were experimenting with), and Coinbase was even removed from the bitcoin.org site by an anonymous contributor to that project.

This was a bit surprising to me and I think really hurt the credibility of those sites, but perhaps in hindsight I shouldn’t have been surprised. What’s happening right now is an election in the bitcoin space, and like all elections (the U.S. presidential race being one prime example) things can get a bit heated even if they are overall a good thing.

Why did I tweet about BitcoinXT?

There are a variety of decent proposals out there being discussed about how to scale bitcoin. We had a goal to choose one and start experimenting with it by the end of the year to get educated on it. BitcoinXT seemed like a good place to start — for starters it is one of the only ones actually implemented in code — so we did.

I think BitcoinXT is one of several good proposals that we’d be happy with, but people shouldn’t read much into it beyond that (we are running a variety of node types in production including bitcoin core, XT, a custom node we wrote which works at our scale, and we will probably add others in the future like BitcoinUnlimited).

A number of bitcoin companies made a similar statement in October expressing a desire to upgrade, and I hope we will see that happen.

I care less about which proposal actually wins. The bigger issue is which team of people and which fork we should support. The block size is one of many decisions that will have to be decided in the future as bitcoin evolves. We should care more about having a team with a clear leader (or decision making process) and track record of shipping code which makes reasonable trade offs than the topic de jour: block size.

In the remaining part of this article I’ll discuss:

  1. How bitcoin can scale
  2. How bigger blocks will affect decentralization

Let’s take each one in order.

How should bitcoin scale?

In computer science the general approach to scaling is to look for low hanging fruit that can buy you some time (if you’re in danger of having things fall over soon) and then, as you use up all the low hanging fruit, start trying more complex solutions. You could think of this as sorting your options by the ratio of estimated improvement over estimated cost in descending order, working your way down the list. Cost could be measured however you’d like (time to implement, added complexity, dollars, etc).

In bitcoin, the lowest hanging fruit is probably increasing the block size. Then there are more complex solutions being proposed (such as segregated witness). Most of the debate seems to focus on what the true costs are of increasing the block size (such as increased centralization) so I will focus there.

As an aside, I think the segregated witness proposal is a clever idea, but people may be overestimating its ability to help with scalability. As I understand it, segregated witness only offers a scalability benefit to nodes which do not fully validate the blockchain. Fully validating nodes will have to still download and store the same amount of data (whether it is in the block or not). It may still be a good idea to implement it for its other benefits, but I don’t see it as a great scaling option if you care about fully validating nodes.

Will bigger block sizes hurt decentralization of bitcoin?

The answer here is clearly yes (at least at some point). But perhaps a better question we can ask is:

What is a reasonable upper bound on block size (now and in the future) that would get us the scaling benefits without putting the decentralization of bitcoin at risk?

Here are a few ways I’ve thought about this in case it is helpful.

1. Moore’s Law

If you think Moore’s law and it’s corollaries (which show similar trends for bandwidth, storage, etc) will continue for some time then this means you could approximately double the block size every two years without impacting decentralization.

Let’s say $1,000 worth of hardware is sufficient today to run a fully validating node on the bitcoin network. Moore’s law (and again the corollaries) suggests that in two years anyone with $1,000 could buy hardware that would handle blocks of twice that size. This trend has been going on for about 100 years (with various speed ups and slow downs over shorter periods).

Some areas are growing a bit faster or slower than a two year cycle, so this is approximate. Storage, for example, seems to have slowed over the previous ~4 years. But I think we have some room to play with in either direction on decentralization — for example doubling or halving the block size is unlikely to have a major impact (more on this later) — so doubling every two years is an approximation.

Whether you believe it should double every 18 months or 4 years doesn’t really matter: the broader point is still true that we could continue to double the block size at some rate and not impact decentralization at all. This is good news because going from 7 to 4,000 transactions per second (Visa levels) is only about nine doublings away.

If you believe that, then the next question is whether we’ve chosen the right starting point for today (should we use 1, 2, 4, 8, 16, 32MB blocks?). Exponential growth will solve it either way, but for example if we started at 8MB today then we’re only 6 doublings away (or 12 years if we doubled every 2 years) from Visa throughput levels on the bitcoin network. This is assuming zero other improvements are made. We should be thrilled with this result; it means that scaling bitcoin is a tractable problem

(For the record, I think we could actually get there faster but this is just an example.)

And of course, if Moore’s law stops working or slows down, we can always make another change, so it wouldn’t have to be set in stone.

2. Mining is way more centralized, so why are we focused on the number of full nodes?

Today there are about 5,500 full nodes on the bitcoin network. People seem concerned that this might fall if the cost of running a bitcoin node increases.

Let’s say for a moment that the number of nodes fell by one order of magnitude to 550. Would this be a major threat to the bitcoin network?

It certainly wouldn’t be ideal, but it still wouldn’t bring us anywhere near the risk we already have today with centralized mining. Just 4 or 5 mining pools control about 80% of the hashing power. By comparison, this makes the number of full nodes seem much less important.

Some excellent survey work done by J. Toomin

To be clear, I don’t have dire concerns about how centralized bitcoin mining is (I think if those pools were shut down, others would come up to fill their place, and a variety of other arguments) but I think it goes to show that a little decentralization goes a long way. You get more benefit going from 1 to 5 entities than you do going from 5 to 10 (and so on). That is to say, the benefit of decentralization asymptotically approaches some line (or has diminishing returns).

Having fewer full nodes is certainly not good, but a safe lower bound on that number could be a lot less than people think.

3. We already doubled the block size over the past year and it turned out ok

The average block size (and the space to store the entire blockchain) grew by about 100% over the past year.

And the number of bitcoin nodes fell by about 14%.

Actually, most of the drop happened around Oct 6th, which was apparently due to spam transactions and stress testing. If you ignore this (which isn’t entirely clear whether you should) the change was closer to a 6% drop.

So the block size doubled and the number of full nodes fell by 6%. Can we use this as a proxy for what will happen if we raise the block size more? Maybe.

There could be other factors which impact the number of bitcoin nodes such as the price of bitcoin, overall bitcoin interest, and the availability of better web and mobile wallets. It could also be that anything under 1MB has a small impact, whereas larger sizes would have a bigger impact. There is really no way to know for sure.

So full disclaimer: this is a very rough and un-scientific analysis. But I think it can still be helpful in making a ballpark estimate.

To me, this data suggests that doubling the block size again would approximately cause a 10% drop in the total number of nodes (down to about 5,000 nodes or so total). I’ll leave it up to you whether you think this trade off is worth it or not (I’m just trying to estimate it).

To stretch things a bit, it suggests that with 8MB blocks (which are completely full mind you) you’d still have about 4,000 full nodes on the network as of today. Of course, things get fuzzier the farther you try to extrapolate it.

It is really difficult to say for sure. One could even make the argument that raising the block size would allow bitcoin to scale to Paypal or Visa levels and cause an increased interest in bitcoin leading to more nodes. What if every bank and accounting firm needed to start running a bitcoin node? In any event, I think we can draw a fence around the downside of doubling the block size right now, since we already tried this experiment in 2015 and saw what happened (a 6% drop in nodes).

4. Maybe a free market solves this for us

There is a healthy market dynamic where miners trade off the additional transaction fee they get vs the delay in relaying a larger block (which reduces their chances of winning that block). In other words, no matter that the cap is on the block size, miners may choose to mine much smaller blocks until transaction fees go up, and this is 100% their choice (as it should be).

We should consider the maximum block size to be a DDOS prevention measure, and not a goal of what the average block sizes should be. People often confuse their desired average block size with what the maximum could be for any given block. Keeping the maximum much higher than the average is useful in dealing with surges of transactions during holidays or people trying to spam the network, for example.

So in summary…

  1. If you believe in Moore’s law then we can double the block size every N months, without harming decentralization
  2. Mining is already much more centralized (so perhaps the number of full nodes is not very close to a dangerous level)
  3. We already tried doubling the block size last year, and it didn’t materially hurt decentralization (a 6% drop in full nodes)
  4. And if we raise the block size maximum there is still the market forces on transaction fees to keep things in check

Which fork should we vote for?

In my other article I talked about why I think miners should vote. Please read it if you haven’t yet.

It is up to each miner out there to do their own research and vote (after all, they are the ones who primarily have the votes).

But a few thoughts I will share:

  • Mining profitability is closely linked to the price of bitcoin. The best way I can think of to make the price of bitcoin go up long term is to ensure it can scale to approach the levels of Paypal or Visa. This will make bitcoin more valuable.
  • The block size debate is just one issue today. We should be more concerned with choosing the right team with the right leader (or decision making framework) than any particular block size solution. The right team will have many decisions like this to make over the years. They should have a track record of consistently shipping improvements to the protocol (not getting bogged down in discussion).

I have my own views on which fork I’d like to win, but I think the voting process will help bitcoin choose a new fork and scale.

If you’re a miner, the time to vote is now :)

Btw, to the trolls censoring the debate on the /r/bitcoin sub-reddit and bitcoin.org, you are not helping your cause. I suggest people change their links to /r/btc and bitcoin.com to browse censorship free until those organizations have ousted the bad actors.

Update: I’ve changed my

--

--

Brian Armstrong
The Coinbase Blog

Co-Founder and CEO at @Coinbase. Increasing economic freedom in the world. Join us: https://www.coinbase.com/careers