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. 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 three months, votes from miners are tallied to determine a change in the block size which can't reduce it more than 50% and can't raise it more than 100% (in other words, the new block size results from the old block size multiplied by some constant between 0.5 and 2).
 * The block size change is computed by directly using the value of the 20th percentile vote over the previous three months.

There was some confusion over the last point because the text of BIP 100 is unclear, but Jeff has clarified this as described here.

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, depending on how they vote

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 15 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 maximized 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. In other words, because mining is a competitive market, long term profits will be zero. 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.

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. There would be at least three months during which users experienced high fees. If block size needed to increase more than 2x then the period of unnecessary user pain would last at least 6 months. 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.
 * 21% of hash power could reduce the block size from any starting point down to 1 MB. This could be very 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, 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.