The little-known reason why Core developers insist on small blocks

   Imagine asking a Bitcoin developer the following question:

If we could somehow increase block capacity and keep the transaction cap above demand for two years in a row, while being decentralized in a secure way, would you be in favor of doing that?

How do you think they will respond?

If you look at Core’s scaling roadmap, you might think they would answer “yes.” The roadmap does not provide any reason for limiting Bitcoin transaction volume in the short term, other than to prevent immediate risks to decentralization.

When Core developers communicate on the developer mailing list and IRC, they give many other reasons for limiting the block size. Based on these reasons and comments made by developers in more private forums, I believe most people would answer "no" to the question above. Some common arguments are:

1. If we increase the block size, we are making an implicit commitment to keep increasing it. Even if it is safe to increase the block size now, this will not be the case forever. It is better to keep the block size fixed small to prevent users from expecting further capacity increases.

2. At some point in the future we will need to pay for security, so it is important to create a market for it as soon as possible.

3. Keeping transaction capacity capped above demand removes the incentive to build, deploy, and maintain long-term scaling solutions like the Lightning Network, so we should fill up block capacity now.

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

The following quotes are from Core developers who posted on public forums, which indicate that the developers have supported these other arguments for keeping blocks small.

Quoted from a public statement by a core developer

Greg Maxwell posted on #bitcoin-wizards in January 2016:

Greg : There is nothing wrong with blocks being full, blocks are "full" relative to what miners have mined over the years. Full blocks are the natural state of the system: the demand for highly replicated external storage at zero external cost is infinite.

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

Greg : Fee pressure is an intentional part of the system design and is currently the best understood need for the system to survive in the long term. So, um, yes. Fee pressure is good.

In May 2015, Pieter Wuile stated in the Developer Newsletter:

Call me sarcastic, but without real pressure, I doubt change will happen. Increasing block size now just makes it cheap enough to keep the economy the same as before — until there’s pressure to increase transaction fees across the economy .

Grey Maxwell posted on #bitcoin-wizards in August 2015:

gwellen : 2MB initially seemed safe enough, do you really think it is also a radical solution?

Greg : My comment was mainly that nobody would find it radical. I agree that it is not terribly harmful (although perhaps more harmful than you think, since it may go a long way to prevent any market fees over the years - which will reach an increasingly scary and dangerous limit over time)

gwillen : I don't know what Gavin , Mike , and the redditors think, but my hunch is that at least some people would feel more relieved by the immediate change, even if it doesn't have a very good long-term effect.

Greg : Hmm. That doesn't comfort me (e.g. they'll be immediately appeased because they think they can argue later that we promised to make more changes like Jeff did - just like how the US got copyright for limited terms)

In May 2015, Wladimir van der Laan stated in the Developer Newsletter:

Increasing fee pressures lead to a true fee market where transaction competition moves to block competition. This necessitates the urgent need to find decentralized off-chain solutions. I'm afraid that increasing block capacity will slow down for a while, letting people (and large Bitcoin companies) relax until the blockchain is increased again, and then they will join Gavin again , never getting a smart sustainable solution, but instead getting perpetually awkward discussions like this one.

Greg Maxwell posted in #bitcoin-wizards in August 2015:

Let's imagine this most sacred "parameter", the total amount of Bitcoin. Now imagine that 25 years from now, the subsidy (block reward) will be very low, transaction fees will not rise (for example: the fee market fails or is insufficient), the security of the system will be challenged, and the network will be attacked by Byzantine attackers using old mining machines. Security and availability are evaporating.

Matt Corallo, May 2015, posted on the developer mailing list:

Yeah, I mean, by increasing the block size, you're actually going to invalidate the incentives in Bitcoin. Even if you create amazing technologies, nobody will have any reason to use them.

In June 2015, Greg Maxwell and Wladimir van der Laan posted on #bitcoin-wizards:

Grey : [ Lightning Network] could have been implemented in 2013 as well; https://en.bitcoin.it/wiki/User:Aakselrod/Draft but there was no real pressure, these areas were not the most pressing issues, so they would not be invested in. We saw the same thing with CPFP and RBF …CPFP was actually written, and RBF was created in early 2013 when blocks were filled (relative to the soft fork limit), and crashed once the limit was hit.

Wladimir: Actually, more pressure may lead to better solutions.

In May 2015, Mark Friedenbach stated in the Developer Newsletter:

It's a simple fact that blocks can't grow that large to cover every use by every person in the world. We're going to transition to an economy where someone has to pay transaction fees to get confirmations. Whether it's 1MB blocks today or 20MB blocks in the future , we're going to have to deal with this. Frankly, it's going to be a lot easier to do now.

In August 2015, Pieter Wuille stated in the Developer Newsletter:

Why are 8 MB blocks good, and 1 MB bad? To me, they are a small constant that doesn't fundamentally scale the system. I don't like the prospect of a technology being "locked in the same size forever", so I'm suggesting trying to fix that part. It intentionally doesn't try to improve this one small element, because I don't think it's valuable.

As early as January 2013, Greg Maxwell said on BitcoinTalk:

However, before I think we can even discuss increasing [ the block size limit] , I think there has to be evidence that transaction load has exceeded the optimal level for a fee market to be established (e.g., we should already be approaching saturation and still see difficulty increasing or at least remaining stable). This would also be good for further stimulating external fast payment networks, which I think must exist on any blockchain.

Open debate will help

To what extent is Core’s scaling roadmap influenced by opinions like the above? What do Core developers think of these opinions? And how would they answer the questions at the top of this article? These are certainly interesting questions.

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

Openness is particularly important here, as the Bitcoin community is more willing to respect Core’s expertise, such as block propagation latency, than their opinions on user expectations. To the extent that Core does not acknowledge its economic or social opinions and mixes them with technical suggestions, these opinions go unnoticed by most observers and are never questioned.

To make this clearer: imagine that a Core developer is the best expert in the world on topic X, but is just one of many with important opinions on topics Y and Z. If Core recommends a plan based on X, Y, and Z, but is seen as being based only on X, their opinions on Y and Z are blocked from the debate. Core's opinions on Y and Z are not respected as much as his opinions on X.

In the spirit of openly debating these “non-X” perspectives on small blocks: here I explain why it makes no sense to try to set user expectations by allowing fees to rise as quickly as possible. I’ll discuss more of these perspectives in future posts.