Arguments in the Bitcoin Block Size Debate

Wednesday 10 June 2015 - Filed under Decentralization

Ever since Gavin Andresen’s first post about increasing the block size a month ago, a debate has been raging across all Bitcoin discussion forums on whether or not to increase Bitcoin’s block size limit. Actually the debate has been going on for longer than that but the rate and temperature of discussion have been greatly increased since Gavin began to highlight the issue.

There are as many opinions as there are participants in this debate and the sheer volume of discussion is so high that few have time to follow it all. My feeling is that most people with strong technical knowledge of the system have chosen a way forward and would rather argue for that way than summarize the arguments presented by each side. I put together the following to help myself and others make up our own minds.

Technical Background

Before we get to the arguments, here is some technical background on the block reward, fees, miner considerations and the block size limit itself. If you understand them already, feel free to skip to the For and Against sections.

Block Rewards and Fees – Bitcoin miners are currently awarded 25 new bitcoins per block, an amount will halve every 4 years or so until the amount is finally shifted down to zero more than a century from now. Miners are also paid with voluntary fees set by the signatories of each transaction. When a miner finds a block, they collect the fees from each transaction included in their block. A miner is free to choose which, if any, transactions they include in a block as long as the transactions are valid and don’t make the block too big. Miners who wish to increase their income then have an incentive to include transactions with higher fees per kilobyte over ones that provide less.

Add up the block rewards and fees and you have an aggregate budget available to all miners that will go into operating mining nodes, the hashing work that secures the network, and in theory, profit.

Block Size Limit – Bitcoin is the first system in the world to use a block chain, a list of blocks linked together in order by miners running the Bitcoin software. Inside each block are one or more transactions that create and transfer bitcoin, pay fees, and optionally store additional data. These transactions can be created by anyone and as long as they meet certain basic criteria, they are broadcast through Bitcoin’s peer-to-peer network. Miners listen for these transactions and choose which of them they will include in the block they are currently working on.

This entire debate centers on a limit that constrains the size, in bytes, of each new block. That limit, called MAX_BLOCK_SIZE looks like this in the Bitcoin software:

static const unsigned int MAX_BLOCK_SIZE = 1000000;

This constant specifies that no block of more than one million bytes shall be considered valid by nodes with this setting.

Since each transaction takes at least a couple hundred bytes, the block size cap constrains the number of transactions that can be included in each block. With blocks targeted to be found every 10 minutes on average, a limited number of transactions can be recorded in the block chain per second, day, or year. This limit also governs the growth rate of the block chain and the minimum processing power and bandwidth required to run a full node. A full node is one that stores the entire history of transactions and participates completely in the Bitcoin peer-to-peer network.

The transaction rate limit affects how many people can have their transactions confirmed, how quickly, and what minimum fee a rational miner would require to include a transaction in their next block.

The size of a block affects how quickly it can be downloaded, verified, and propagated across the network. Larger blocks take more time to transfer and verify than smaller ones. For most miners, each second taken to download and verify a block is time that they could have been hashing for profit instead of wasting their time building on an old block. For a winning miner, larger blocks increase the likelihood that they will lose what they would have earned if another block is found and propagated to miners who manage a majority of hashing power first.

As you can see there are a lot of variables in play around the block size issue and that a fair amount of background, is required to understand the issues. Now, take a careful look at the arguments below presented in no particular order.

For Block Size Increase:

1. Encourage adoption – Since the block size limits how many transactions can be processed, it places a limit on how many users will be able to use Bitcoin directly. Transaction rates have grown all during Bitcoin’s life and at some point, transaction fees will become an important factor in getting a transaction confirmed in the next few blocks after broadcast. If fees rise too high or transactions must wait too long, this argument posits that users will be driven away from Bitcoin, to some other alternative whether that be another cryptocurrency, a legacy payment system, or an off-chain system that still utilizes the bitcoin currency unit but doesn’t have the same benefits of privacy, irreversibility, and resistance to censorship.

2. Crash landing – This argument describes a scenario where more transactions are broadcast than the Bitcoin network can handle for an extended period of time. Transactions that are not confirmed pile up in each Bitcoin node’s memory pool overloading ones with less memory, thereby degrading the connectivity and performance of the network. Users who want to increase their fee, add even more transactions to the network making the problem worse. Lower performance and the build up would signaling users that Bitcoin is not up to the global payments challenge.

3. Block size is self-correcting – Miners have an incentive to keep blocks small whether there’s a limit or not. Larger blocks are more likely to be orphaned meaning lost revenue for the miner who publishes a large block. For each additional transaction they include, they should be able to calculate and make a decision based on the increased risk of orphaning and the included fee.

4. The limit was temporary – The 1,000,000 byte limit was a temporary spam control measure. When the block size limit was introduced, transaction volumes were very low compared to the limit. The limit was put in place to stop malicious
actors from cheaply inflating the block chain thereby increasing costs forever for users of a new and promising system. Waking up after a week to a block chain requiring tens of gigabytes when very few people used the network could have been disasterous but would be less of a problem today, five years later.

5. Don’t constrain legitimate transactions – The block size limit was not meant to constrain legitimate transactions. While it is difficult to judge whether any transaction is more legitimate than another, miner costs, not a block size limit should be the mechanism relied upon to govern growth in the block chain.

6. Assurance contracts can pay for security – One of the arguments for constraining the block size posits that significant fees will be required to pay for enough hashing to secure the network against a 51% attacker as block rewards halve. An assurance contract is a tool for allowing a set of participants to pay for a good in the face of a the free-rider problem. Participants would then contribute funds to the contract to pay for enough hashing and the network would be secured as necessary by those who are most concerned with security.

Against Block Size Increase

A. Fewer full nodes – As larger blocks are produced, increased costs mean that fewer users will run full nodes. This means they will be placing more trust in those who can run a full node to accurately report on data recorded in the block chain. Users also become more likely to expose details of their bitcoin usage and are more vulnerable to fraud in the form of double-spending or monetary inflation. SPV nodes have no way for example to detect if a node fraudulently reports the receipt of bitcoins to the SPV node’s wallet that don’t exist in the fully-verified block chain.

B. Paying for the hashrate – Bitcoin’s security model depends on honest miners having more hashing power than attackers. From the genesis block on that hashing power has been paid for by block rewards that are scheduled to decrease over the coming years and decades. As that reward goes away, something else must replace or eclipse (depending on the exchange rate and value of transactions that occur) the block reward to secure the network. These fees must pay not only for the cost of transaction verification and any incremental risk of having one’s block orphaned, but must pay for enough hashing by honest miners to defend against an attacker. Fees are the most straightforward way to provide this funding but require that Bitcoin develop a robust fee market and features to enable users to adjust their fee if they are willing to pay to expedite confirmation of their transaction to the next block or so. Assurance contracts as an alternative to fees are untested and may be gamed in a way that reduces their effectiveness.

C. Increased censorship – Larger blocks require higher amounts of bandwidth which would stand out in jurisdictions that monitor network traffic closely. This would make identifying anonymous bitcoin miners easier and enable governments and corporations to coerce miners to enforce censorship on bitcoin transactions. Having some miners be anonymous is not enough as state or corporate controlled mining nodes could ignore blocks produced by those outside the favor of the regulatory regime.

D. No urgency – Transaction volumes today vary quite a bit from hour-to-hour and on average only require 400KB of storage space per block. Some of these transactions are of little economic value and should not be used as justification for a block size increase now. In the time before a change, other options can be explored and implemented to reduce transaction load in trustlesss, decentralized fashion. Even in the absence of such immediate developments, use of centralized off-chain services would be temporary with that volume shifting to trustless, decentralized options once available and competitive.

E. A change would be irreversible – Changing the block size limit requires a hard fork and if the larger block size were to be abused, changing it back may not be possible due to changes in who would still be mining without coersion from outside organizations. The blockchain would then grow at around 1TB per year regardless of the economic utility of that additional transactional data and contribute to a downward spiral of centralization and censorship.

That’s it. Comments about any corrections are welcome.

2015-06-10  »  David Sterry