Lesser known reasons to keep blocks small, in the words of Bitcoin Core developers

Imagine asking Bitcoin Core developers the following question:

If we could somehow increase the block size to a level that would keep transaction capacity above demand for two years, in a way that was safe for decentralization during this period, would you be in favor of doing so?

How do you think they would respond?

If you read Core’s scaling roadmap, you might think they’d answer “yes.” There is nothing in the roadmap suggesting any reason to limit Bitcoin’s transaction capacity in the short term other than to prevent direct risks to decentralization.

When Core developers talk among themselves on the developer mailing list and on IRC, they give many other reasons to restrict block size. Based on these and on comments made in more private forums by Core developers, I believe most would answer “no” to the question above. Some common arguments are:

1. If we increase the block size, we create an implicit promise that we will keep increasing it indefinitely. Even if increasing the block size is safe now, this won’t always be true. It’s best to hold firm on keeping blocks small to prevent users from expecting further increases.
2. We will need fees to pay for security at some point in the future, so it’s important to create a fee market soon.
3. Keeping transaction capacity ahead of demand removes the incentive to build, deploy, and maintain more long term scaling solutions such as the Lightning Network, so we should let blocks fill up now.

Note that the above arguments for small blocks do relate to decentralization and security, but in an indirect way via user expectations and incentives.

Below are some quotes by Core developers in public forums which suggest that they once endorsed these other arguments for keeping the block size small.

Quotes from Core Developers

Greg Maxwell in #bitcoin-wizards, January 2016:

Greg: There is nothing wrong with full blocks, and blocks have been “full” relative to what miners would produce for _years_. Full blocks is the natural state of the system: The demand for externalized-cost highly replicated external storage at price zero is effectively infinite.

bsm117532: Are you arguing “fee pressure is good” and therefore small blocks and zero growth are desirable?

Greg: fee pressure is an intentional part of the system design and to the best of the current understanding essential for the system’s long term survival. So, uh, yes. It’s good.

Pieter Wuille on the dev mailing list, May 2015:

Call me cynical, but without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while- while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.

Greg Maxwell in #bitcoin-wizards, August 2015:

gwillen: the 2MB initial seems harmless enough; do you really think it would not be a useful peace offering?

Greg: My comment was basically that no one would find it a useful peace offering. I agree it’s not so harmful (though perhaps more than you’re thinking as it forestalls any fee market further, perhaps by years — which makes running into a limit more scary and dangerous as time goes on)

gwillen: I can’t read the minds of gavin/mike/redditors but my intuition is that at least some people will be more pacified by an immediate bump even if it has no long-term consequence

Greg: hm. that doesn’t exactly comfort me (e.g. would they be immediately appeased because they believe that they can later argue that we’re committed to make further bumps as jeff has? — — like how US has copyright with limited terms)

Wladimir van der Laan on the dev mailing list, May 2015:

A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I’m afraid increasing the block size will kick this can down the road and let people (and the large Bitcoin companies) relax, until it’s again time for a block chain increase, and then they’ll rally Gavin again, never resulting in a smart, sustainable solution but eternal awkward discussions like this.

Greg Maxwell in #bitcoin-wizards on August 2015:

Lets imagine the most ‘sacred’ parameter, the supply of coins. Now imagine a future 25 years from now where subsidy is very low, and TX fees are not picking up the slack (e.g. fee market has failed or is insufficient) and the security of the system is failing, the network is being reorged by byzantine attackers with generation old hashpower. Security and usability are evaporating. Something must be done. With bitcoin’s utility failing, saying you now need to pay fees when you haven’t the last 10 years may not be a credible argument.

Matt Corallo, dev mailing list, May 2015:

Yes, I am arguing that by increasing the blocksize the incentives to actually make Bitcoin scale go away. Even if amazing technologies get built, no one will have any reason to use them.

Greg Maxwell and Wladimir van der Laan in #bitcoin-wizards, June 2015:

Greg: [Lightning] also could have been implemented in 2013; https://en.bitcoin.it/wiki/User:Aakselrod/Draft but absent actual pressure, these areas are not the most pressing concerns and they do not get investment. We also have seen this with CPFP and RBF… CPFP was actually written up and RBF was invented back at the beginning of 2013 when blocks were full (relative to the soft limit) and then went dead once the limits were bumped.

Wladimir: more pressure may be better to actually get solutions out there

Mark Friedenbach on the dev mailing list, May 2015:

It is a simple fact that the block size cannot increase so much as to cover every single use by every single person in the world, so there is no getting around the reality that we will have to transition into an economy where at least one side has to pay up for a transaction to get confirmation, at all. We are going to have to deal with this issue whether it is now at 1MB or later at 20MB. And frankly, it’ll be much easier to do now.

Pieter Wuille on the dev mailing list, August 2015:

why is 8 MB good but 1 MB not? To me, they're a small constant factor that does not fundamentally improve the scale of the system. I dislike the outlook of "being forever locked at the same scale" while technology evolves, so my proposal tries to address that part. It intentionally does not try to improve a small factor, because I don't think it is valuable.

Greg Maxwell on bitcointalk, way back in January 2013:

But before I think we can even have a discussion about increasing [the block size limit] I think there must be evidence that the transaction load has gone over the optimum level for creating a market for fees (e.g. we should already be at some multiple of saturation and still see difficulty increasing or at least holding steady). This would also have the benefit of further incentivizing external fast payment networks, which I think must exist before any blockchain increase

Open debate would help

It would be interesting to know: to what extent is Core’s scaling roadmap influenced by beliefs like those above? What do individual Core developers think of these arguments and how would they answer the question at the top of this article?

There is nothing inherently wrong with making block size decisions based in part on indirect risks like these, but if we do so we should be open about it.

Openness is especially important here because the Bitcoin community is more willing to defer to Core’s expertise on things like block propagation latency than on their beliefs about user expectations. To the extent that Core folds their economic or social beliefs into their technical recommendations without acknowledging them, these beliefs go unnoticed by most observers and are never challenged.

To make the point more abstractly: imagine Core developers are the world’s best experts on topic X, but just one of many groups with valuable insights on topics Y and Z. If Core recommends a plan which is based on all of X, Y, and Z but is viewed as being only based on X, then their beliefs about Y and Z will be shielded from debate. Core’s beliefs about Y and Z will without justification inherit the deference given to Core’s beliefs about X.

In the spirit of openly debating these “non-X” arguments for smaller blocks: here I explain why trying to set user expectations by allowing fees to rise soon doesn’t make sense. In future posts I’ll address more of these arguments.