Specific block size proposals

Gavin's proposal, BIP 101

Gavin Andresen's BIP 101 proposes the following:

• Change the maximum block size to 8 MB
• Every two years, double the block size
• When blocks reach 8 GB in the year 2036, stop increasing the block size

The change is activated two weeks after 750 out of the last 1,000 blocks indicate support for it by encoding a special message in their blocks, unless this activation would occur before January 11th 2016, in which case activation occurs on January 11th 2016.

The advantage of this proposal is that it gives Bitcoin a lot of room to grow, which is extremely important as described here, and is also more likely than other proposals to avoid the negative effects of high fees. Most objections stem from people worrying that it errs too far on the growth side of the growth/decentralization trade-off, and poses too big of a risk to decentralization.

Criticisms

• The initial 8 MB limit is a large jump from 1 MB. We should increase the block size smoothly from 1 MB instead of all at once.
  • Since blocks aren't usually full at 1 MB, it's likely that there will not actually be a sudden jump in actual block sizes unless the network is being flooded as part of some attack or "stress test."
• The block size limit eventually will get too large. 8 GB blocks are insanely large and would almost completely centralize Bitcoin.
  • It's important to keep in mind when certain sizes would be reached. 8 GB would be crazy right now, but BIP 100 doesn't result in such large blocks until 20 years from now. People have a hard time imagining the magnitude of technological change over a long period of time. Computers are far more capable today than they were 20 years ago in 1995, so it's not crazy to think that an equivalent increase in technology could occur over the next 20 years.
  • If technology did not keep pace with block size growth, it would be possible to do another hard fork to put block sizes on a slower increase schedule.
    • There is probably an effect where the "default" action will be easier, so if the decision of whether or not to hard fork to slow block size growth is controversial, those in favor of larger blocks will have some advantage if no action would result in blocks continuing to increase according to their preferred schedule. This is similar to how in the current environment those favoring small blocks have an advantage because small blocks are the default behavior.
• It's very hard to predict the future. Who knows what technology will be like in 10 years or what kind of improvements to Bitcoin will have been made by then. Given the uncertainty, we shouldn't try to predict so far ahead.
  • This sort of argument suggests that it'd be better for BIP 101 to be changed to stop increases in 4 years at 32 MB. If at the time it looked like continuing the same sort of block size increases was prudent, we could do another hard fork.
    • BIP 101 advocates would argue that even with the existing BIP 101 code, we could do a hard fork in 4 years if we wanted to. As mentioned above, the difference is that whatever behavior is considered the default will likely give some advantage of uncertain magnitude to its advocates in getting their preferred block size solution adopted.

Pieter's proposal

Pieter's proposal has a similar structure to BIP 101, but is much more conservative in the trade-off it selects on the growth/decentralization continuum.

The initial max block size is 1 MB instead of 8 MB, and it grows at 17.7% per year instead of the ~40% annual growth of BIP 101. Being more conservative than BIP 101, the risks to decentralization are lower with this proposal, although it's unclear how significant the difference in those risks is.

Criticisms

• Gavin points out that under this proposal we would not get to 2 MB blocks until 2021. This means that if demand for transactions increases significantly between now and then we'll have to either suffer the consequences of high fees or do another hard fork.
• If we do experience high fees due to increased demand combined with the slow block size growth of this proposal, Bitcoin will likely grow at a slower pace, risking its long term security.

Jeff's proposal, BIP 100

Jeff Garzik's BIP 100 is often seen as a compromise between an overly aggressive proposal by Gavin and an overly conservative proposal by Pieter. Here's a good summary article. See Jeff's original PDF for more of the reasoning behind it. The main components of BIP 100 are:

• The block size will start at 1 MB and can fluctuate between 1 MB and 32 MB as described below.
• Every two weeks, votes from miners are tallied to determine a change in the block size which can't reduce or increase it more than 20%.
• The block size change is computed by directly using the value of the 20th percentile vote over the previous three months for a block size increase, or the 80th percentile vote for a block size decrease. If the 20th percentile vote is not larger than the current size or the 80th percentile vote is not smaller than the current size, the block size remains the same.

This proposal could be considered more conservative than BIP 101 because:

• The max block size is 32 MB instead of 8 GB
• Block size starts from 1 MB instead of 8 MB
• Miners might not increase the block size as fast as it'd be increased in BIP 101, especially because 80% of miners need to agree to any block size increase

It could also be considered more dangerous in some respects:

• Miners have the power to get us to 32 MB blocks much more quickly than in BIP 101. It could be done 9 months after adoption, as opposed to 4 years after adoption with BIP 101.
  • This can only happen if 80% of miners vote for it to happen. This might be unlikely.
• It introduces a new system miner voting whose effects are uncertain.

Miner voting scheme

BIP 100 introduces the new mechanism of miner voting, which has several effects:

Easier for miners to collaborate

Without BIP 100, if miners wanted to enforce a block size that was lower than a hard upper limit, at least 51% of hash power would need to somehow communicate outside of the Bitcoin protocol and agree to orphan blocks that were larger than their agreed upon limit. BIP 100 gives miners an easy collaboration mechanism which they can use within the protocol, without having to solve the problem of communication with each other. This is either good or bad depending on whether you think miners are likely to help or hurt Bitcoin when they collaborate.

Legitimizes only certain types of miner collaboration

As mentioned above, 51% of miners are always able to form a group and enforce block limits lower than the maximum. In fact, these miners can enforce any sort of rule that they want, as long as the resulting blocks are valid. If Bitcoin users did view it as legitimate for a 51% cartel to enforce a lower block limit (maybe it was viewed as good for Bitcoin by protecting decentralization), then it may be less clear when this 51% cartel was abusing their power.

In effect, if you don't give miners some way to easily collaborate yet you view their collaboration as good in some cases, then you're encouraging a 51% cartel to form. For a 51% cartel to form, miners need some way of communicating outside of the protocol. Yet having a 51% cartel that communicates outside of the protocol could be dangerous, because it might lead to them enforcing other rules that hurt Bitcoin as a whole.

By giving miners a community-approved way to collaborate, users can still get whatever benefit they expect from this sort of legitimate collaboration, while not setting a precedent of accepting block-orphaning as a legitimate strategy of a 51% cartel. In such a world, evidence of orphaning behavior by a cartel would be easier to call out and punish (perhaps via an anti-miner hard fork).

Gives miners the power to create and fine tune a fee market

Once 1 MB blocks are consistently full, BIP 100 puts miners in charge of whether a fee market should exist and what it should look like. Miners could vote to set the block size to a level that maximizes total fee revenue. This would not necessarily be in the interests of Bitcoin as a whole, as miners' incentives are not perfectly aligned with users' incentives. Meni Rosenfeld describes this here and here.

There is a good chance that a fee market will not be needed for at least 10 years, and that security could be paid for adequately via block rewards during that time. In that case a fee market would cause fees to be higher than they otherwise would be without much benefit. In addition to harming users, this would hurt growth and potentially make it more difficult to secure Bitcoin in the long term.

Some argue that miners would not try to maximize their fee revenue in the short term because it's in their interest to keep Bitcoin valuable for as long as possible so they can continue collecting mining rewards and fees for as long as possible. This ignores that some miners may not be planning to mine for the long term and may only care about the health of Bitcoin over a span of a few years or less. Miners may also be mistaken about the long term effects of fees. Some miners may believe that 15 cent fees are not significantly worse than 1 cent fees, and therefore they can constrain block size to move fees from 1 cent to 15 cents without long term negative effects. Miners may also feel that it's appropriate to increase fees because some Core developers argue that creating a fee market now would be good.

Another thing to keep in mind is that miners don't necessarily benefit in the long term by increasing the value or usage of Bitcoin, because the value up for grabs via block rewards and fees will be competed away as miners try to capture this value. It is therefore unclear whether a miner will judge it to be in his interest to maximize short term fee revenue.

The argument that miners won't use their power to make fees higher is also questionable because it prompts the question: why give miners a power right now if we all agree it'd be bad if they used it right now? Why not wait until we need a fee market, then give miners the power to maintain one? Giving them this power now creates risks without apparent benefits.

Protects 20%+ of hash power from increases that they can't handle

Because 80% of miners need to approve any block size increase, if a large group of miners were trying to push block sizes higher to get an advantage over miners less able to handle large blocks, they'd need a pretty large coalition for this to work.

It's unclear that miners in the 20th-30th percentile of ability to handle large blocks would participate in purposely excluding the bottom 20%, because once the bottom 20% was excluded, the old 20th-30th percentile miners might be next to be pushed out via a block size increase. They'd probably only partake in the initial exclusion of the bottom 20% if their ability to handle large blocks was much higher than that of the bottom 20%.

Moves us closer to block size being determined by the free market(?)

Jeff's initial PDF contains a lot of discussion about BIP 100 moving us toward a free market. The github also lists moving toward a free market as the first motivation.

Although BIP 100 puts the block size limit under the control of miners instead of being hard coded, it is unclear why this is described as being more free market. The block size limit would not be determined as some emergent property of free exchange between buyers and sellers. It's simply a vote by some participants in the Bitcoin network. It allows miners to act like a cartel.

Wikipedia defines a free market as:

a market economy system in which the prices for goods and services are set freely by consent between vendors and consumers, in which the laws and forces of supply and demand are free from any intervention by a government, price-setting monopoly, or other authority.

In BIP 100, supply is not free from intervention because it is being controlled by a cartel.

One could argue that supply being set by a cartel is closer to a free market than having a fixed supply. However the supply of block space has several externalities that likely make a simple free market suboptimal even if each miner were somehow able to offer as much block space to users as he wanted. First, miners don't bear the direct costs to the network of including a transaction. They also don't bear the full costs to decentralization that large blocks could pose. Miners also don't bear the full costs of blocks that are too small, resulting in slowed growth and high fees.

Jeff might mean that instead of BIP 100 moving us toward a free market system, it moves us toward a system where the aggregated preferences of Bitcoin participants are fulfilled. As noted above, miners' incentives are not completely aligned with those of users (see here and here), so a cartel of miners will not necessarily enact the block size preferred by Bitcoin participants in general.

One way in which aggregated user preferences can actually determine the block size is via the process of the economic majority aligning behind their preferred hard fork. In this case, demand from Bitcoin users will result in coins on each fork having a price, and therefore allow the market to determine the block size that satisfies the demand of those wanting to use Bitcoin.

It could be argued that even if the incentives of miners don't align with those of users, miners would still vote for a block size that users would support in a hard fork situation because users have the power to punish miners. Miners would try to appease users with their block size votes in order to avoid a miner-punishing hard fork. There is some level of miners acting against the interests of users that would bring about such a hard fork, although it's unclear how much users would let miners get away with before supporting such a fork.

Alternative forms of miner voting

BIP 100's voting mechanism can be generalized to require X% of miners to agree to a block size increase, and Y% to agree to a block size decrease, as long as X + Y >= 100. BIP 100 uses the value 80 for X and 20 for Y, making it much easier to decrease the block size than to increase it. Other proposals could require 80% agreement for both an increase or decrease (this is one popular interpretation of BIP 100).

If X and Y are both greater than 51, then in some sense this scheme makes it harder to change the block size than it would be without an explicit voting mechanism. The reason is that 51% of miners can always collude to raise and lower the effective block size by orphaning other blocks. If a BIP 100 style voting mechanism that required 80% miner agreement in either direction were used, it'd take 80% of miners to agree on a change instead of 51%.

As described above, 51% of miners could still get 80% of votes by orphaning blocks that didn't vote along with them. However if there was a culture of this being illegitimate and punishable by anti-miner hard forks, users may be able to force miners into not doing this. When a fee market is needed, this sort of scheme gives users the ability to dictate to miners what the rules of cooperation should be, instead of relying on the decisions of a 51% cartel.

Criticisms

• As described above, giving miners the power to create a fee market so early (or otherwise adjust the block size to benefit themselves) could harm Bitcoin without any real upside. Miner voting might be valuable in the future, but we shouldn't introduce it before we need a fee market.
• If miners chose to set the block size just above current usage and then demand increased suddenly, the block could not react fast enough because each increase is capped at 1.2x the previous size, and we must wait 2 weeks per increase. A system that has more "slack" like BIP 101 (where blocks might average 1.5 MB with a limit at 8 MB) is much better for handling sudden demand spikes.
• As noted above, the claim that a miner vote on the block size is in some sense allowing the block size to be determined by a free market is questionable.
• 21% of hash power could veto any block size increase indefinitely. This could be pretty bad for Bitcoin if the 21% is an attacker, although one can also imagine situations where the 21% are honest miners trying to preserve decentralization and the 79% are trying to centralize Bitcoin. If this were an attack, it could only be stopped (other than via another hard fork) by a 51% cartel forming and orphaning the blocks of the 21%. However it may be a mistake to rely on the behavior of 51% cartels to save us from attacks.
• It allows miners to cause 32 MB blocks to be created within 15 months of adoption if 80% of hash power wants to do that, which would be too large of a risk to decentralization.
• Giving miners the power to determine the block size makes the future state of the system less predictable. The block size may fluctuate as different groups of miners struggle for control. Bitcoin based services may become unworkable if the block size moves from 20 MB to 2 MB and fees skyrocket. See here for more on these points.

Flexible block size proposals

Greg Maxwell and Meni Rosenfeld have each proposed ideas for how to make the max block size limit somewhat flexible. These proposals aren't meant as ways to scale Bitcoin, but to make hitting the block size limit less jarring for the network. They will not be analyzed in depth here, just listed for reference.

Greg's idea is here. The idea is that a miner can make a block larger than the max block size if he's willing to pay for it by hitting a more challenging difficulty target. Presumably this would only be worthwhile if the extra transactions that get included are paying enough fees to compensate for the increased difficulty.

Meni's idea is here. It's similar to Greg's idea, except instead of paying with extra difficulty to include more transactions, miners pay some amount of bitcoins into a pool which gets paid out to miners of future blocks. In exchange they get the right to make blocks larger than the maximum block size.

Both proposals suggest that the cost function be quadratic, so that miners can't increase the block size much without huge cost.