BlockSizeDebate

Adding to this document.

This document is a work in progress. If you are interested in adding to or editing this document please fork it, make your changes and create a pull request.

Argument 1 Pro: Increased Transaction Throughput

The chief argument for the increase in the maximum blocksize is to help the protocol address scalability issues, specifically by raising the total throughput of the Bitcoin network from its current ~3 tps (transactions per second) to something higher. This is most often attributed to an expected spike in adoption.

Counter Argument 1.1: Other Scaling Solutions

1.1a Off-Chain Third Parties

Of the listed solutions, this is the only one that is implemented today. The use of such Third Parties could significanly reduce both the rate of blocksize increase and the average blocksize itself by reducing the number of on-blockchain transactions, and by condensing the number of inputs/outputs used.

1.1a.1 Security Concerns of Off-Chain Third Parties

However, opening up to third parties allows them to potentially steal from you, and have your funds more easily hacked.¹

1.1a.2 Privacy Concerns with Off-CHain Third Parties

This allows for third parties to more easily collect information on you, and leak² it. Not only does this open up Bitcoin to regulatory bodies, but also hackers.

1.1b OpenTransactions

Content pending research...

1.1c Sidechains

Content pending research...

1.1d Lightning Networks/StrawPay

Each of these are decentralized versions of the above, designed to reduce the amount of trust needed. Using payment channels allows it to use much less room on the blockchain, however, leading to a higher overall transaction rate.

1.1d.1 Security Concerns

Like with Off-Chain Third Parties, there are often security concerns sited, such as the ability to steal other parties' funds from Strawpay channels.³

1.1d.2 No Current Implementation

Because there is no current implementation of it, there is no way to be certain this system is a workable solution.

Argument 2 Con: Miners/Full Nodes Cannot Handle Expansion

Pools and Miners in some places of the world have difficulty connecting to some portions of the Internet.⁴ These barriers of entry would grow larger if the maximum bandwidth of the network increases. In some places larger maximum blocksizes may make it so that they never catch up to the network, further pressuring the centralization of nodes and hashrate. Though not a Bitcoin protocol issue, it is unclear how the increase in maximum blocksize might effect existing hardware based on older maximum blocksize assumption.

Counter Argument 2.1: Resource Impact not Immediate

Because the change is only made to the maximum blocksize, it would not introduce an immediate resource impact. This time gap would also give time to implement several bandwidth saving solutions that have been created/theorized specifically to reduce these problems.

Counter Argument 2.2: Decreased node-count is not necessarily increased Centralization

Because we would have to trade this off (currently) with Off-Chain Third Parties, that is also an increase in centralization. So the question is more "Which increases overall decentralization?" instead of "Will this decrease decentralization?".

Counter Argument 2.3: Several Large Miners Have Agreed To Adopt A Change

2.3.1: Several have also spoken against large changes⁵

Counter Argument 2.4: Moore's Law (and its companion laws) will support this in the future

2.4.1: Trusting future hardware innovation is a risky move

Especially as Bitcoin is supposed to serve all, some of which has not yet experienced the growth in bandwidth predicted by Nielsen's Law. This argument may work for storage (and thus far has seemed to), but propogation time of blocks, as well as total download time, will likely outstrip Nielsen's law with any major increase.

Counter Argument 2.5: Satoshi Predicted Node Centralization⁶

2.5.1: Should we really trust the opinion of one person from 5 years ago?

Argument 3 Pro: The Limit Was Intended As A Temporary Measure

Counter Argument 3.1: The Limit Will Provide Fee Pressure

Counter Argument 3.2: Nothing has been done to fix the original problem since⁷

Argument 4 Con: Hardforks Are Difficult

The less notice there is before a hard fork, the more likely it is to fracture the network into competing chains.

Counter Argument 4.1: The last hardfork increasing the block size to 1 MB was performed with merely 2 months notice.⁷

Counter Argument 4.2: The Hardfork Can Be Used To Make Other Useful Changes

Argument 5 Pro: Increases Cost Of Transaction Flooding Block Monopolization Attack

The attack considered here is one in which the attacker generates a large number of transaction fees with high enough transaction fees so that the attack transactions will use all avaliabl;e block space preventing non-attacker transactions from being confirmed. The bitcoin wiki refers to this attack as a transaction flooding⁸.

This can be shown with the following scenario:⁹

Assume blocks are currently 90% full, and fees are 1 unit per kB. At the current blocksize it would take 1,200 units/hour to block 10% of transactions, and 10,000 units/hour to block all transactions.

Under a new blocksize (let's assume 20MB), it would take 115,200 units/hour to block 10% of transactions, and 120,000 to block all transactions.

This is a simplified model that does not take fee markets into account, but it would make transacting much more difficult whether fee markets were used or not.

Counter Argument 5.1: Reduces the cost of a UTXO-based DoS Attack

Increasing the blocksize would allow faster bloating of the UTXO database.⁹ Because the ability to change this scales roughly linearly to block size, increasing the blocksize increases the potential bloat rate from a bad actor. This reduces the ability to run a full node significantly, as RAM is an expensive resource to use compared to disk space.

5.1.1 The effect of this can be dramatically reduced by storing the UTXO database on disk,¹¹ and by storing it more efficiently.

Argument 6 Con: When Would A Hardfork Occur?

Nearly any automated solution will have problems with it, so how can we solve those problems?

Counter Argument 6.1: Predefined block number

After a certain block number, raise the maximum blocksize to X. This allows for a step function as well, but that is not what is being discussed here.

6.1.1 This has no way to measure if it would fracture the network

Counter Argument 6.2: Adoption threshold

If X% of the previous 1000 blocks have a "v.new" flag, raise the limit.

6.2.1 This puts a lot of power into the hands of miners

Counter Argument 6.3: A Combination Approach

If the block number is greater than X, and Y% of the previous 1000 blocks have the "v.new" flag, raise the blocksize limit¹⁰.

Argument 7 Meta: Dynamic Block size limits

Allow the ability for Bitcoin to dynamically determine block size limits in a method similar to how Bitcoin dynamically regulates hash rate¹².

Counter Argument 7.1: Formula Manipulation

Any set formula can be manipulated by attackers and miners, making the network more fragile.

Counter Argument 7.2: Fine Tuning

Any formula will by definition create political decisions. Most proposed formulas are using the median block size, making a simple majority decide to raise or lower the block size. Problem with this is that because most blocks are found in less than ten minutes¹³, the median block size will by necessity be smaller than the mean block size (blocks after more time are more likely to have a transaction backlog).

If you use the proposed multiplier (Max_size = 2 * median (last 144 blocks)), then you have more pressure to smaller blocks (rather than the 50% + 1 it was proposed as).

Counter Argument 7.3: Possible Disagreements Caused By Short-Term Forks

There is a small possibility of the following scenario:

A node accepts a block which pushes the new Max_size down to 749kB. This node then recieves a longer chain (2 blocks) where the first has a size of 750kB. The node would then reject the longer chain because of the Max_size from the first node, making the possibility of automatic, accidental hard forks.

7.3.1: Calculate based on previous blocks

Simple solution to the above would be to calculate the hashrate based on [x-6,x-150), where x is the current height.

Argument 8 Con: A Block Size Increases Would Lead to a Maximum Cap Increase

Source: 1, 2, 3

Increasing the block size with the goal of scaling the blockchain is the same reasoning someone would argue for an increase in the maximum 21 million block limit.