For large blocks

Fees

High transaction fees have many negative effects

There are many negative effects and potential effects of high fees.

In a world of high fees:

Users paying high fees directly reduces the value they get from each transaction

• If a user is sending a transaction that he'd pay $1 to send but Bitcoin's fees are only 5 cents, then the user gets 95 cents worth of value every time he sends such a transaction. If fees rise to 90 cents, then the user only gets 10 cents of value from the transaction -- about 10% of the value he got before. Over many transactions among many people, this lost value can become very significant.

Some Bitcoin use cases become nonviable, so transactions that would have otherwise benefited people won't happen

• If a user is sending a transaction that he'd pay 50 cents to send but Bitcoin's fees are 5 cents, then the user gets 45 cents worth of value every time he sends such a transaction. If fees rise to 90 cents, then the user won't make the transaction (or will find another way to do so). The user loses 45 cents worth of value because Bitcoin's fees are too high. Over many potential transactions among many people, this lost value can become very significant.

Experimentation with new Bitcoin use cases is discouraged

• The easier it is to try out new ideas, the faster innovation occurs. High fees will result in some use cases being nonviable, meaning that potentially useful variations on those ideas (which may have worked even with high fees if tried initially) never get discovered and improved. Entrepreneurs can't properly experiment with products using Bitcoin's test network, because most useful experimentation requires participating in real markets and interacting with real customers.
• Even if fees are not high now, the expectation of future high fees or capacity limits can also discourage businesses from building services that use Bitcoin. To the extent that firms expect Bitcoin's capacity will remain small, they be less willing to invest in using it.

Fewer users makes Bitcoin more vulnerable to regulations that cause users significant harm

• A Bitcoin with fewer users is more vulnerable to the type of regulation that either ban Bitcoin outright or significantly reduce its usefulness, because regulators face less public pressure from smaller groups. For an example of this effect in action, see Uber.

While block rewards exist, the security of the network is greater with a higher exchange rate

• More people using Bitcoin to transact will increase the exchange rate, all else being equal. This is implied by the equation of exchange. A higher exchange rate results in higher security as long as block rewards exist, because block rewards are denominated in Bitcoin. Gavin makes this argument here.

Security is more sustainable with lots of users paying low fees, vs. few users paying high fees

• Given the same level of security, it's better that it be paid for by many users paying small fees as opposed to few users paying high fees:
  • Higher fees mean there is more pressure for any given user to switch to an alternative currency. Users switching to different currencies lowers security and reduces Bitcoin's network effect.
  • Because money has network effects, a money that has more users is more stable than one with fewer users all else being equal.

At a lower block size, a sudden increase in demand is more likely to result in high fees than at a larger block size

Here's a toy model to illustrate the point. Assume blocks can hold 2000 transactions (txns) per MB. Before the new use case is discovered, demand looks like this:

500 txns will pay $1 fees
1000 txns will pay 50 cent fees
2000 txns will pay 5 cent fees
8000 txns will pay 2 cent fees
15,000 txns will pay 1 cent fees
100,000 txns will pay 0.01 cent fees

So at a block size of 1MB, fees are 5 cents.
At a block size of 8 MB, fees are 1 cent.

Now a new use case comes into play and this is added to demand:

3000 txns will pay $5 / txn

That demand changes the scenarios like such:

At 1 MB fees jump to $5.
At 8 MB, fees would stay at 1 cent.

This shows how an increase in demand could result in a huge fee increase at a low block size, but result in no fee increase at a higher size. Larger blocks provide protection against large fee increases.

Growth

Money has network effects, so Bitcoin's growth disproportionately depends on lack of friction in its early stages

Because of money's network effects, it is very hard for a young currency to gain wide adoption. The more people use Bitcoin the more useful it is and vice versa. People already have so little incentive to use a currency which almost no one else uses that adding even more roadblocks to Bitcoin's use could stop or reverse adoption. Once lots of people are using Bitcoin and deriving value from it, there is more leeway to add friction in the form of higher fees. Purposely increasing the user's pain points before they have much of a good reason to use Bitcoin sabotages the virtuous cycle of network effects.

There's a reason why tech startups in markets with network effects don't try to monetize too early. In its early stages a system that depends on network effects is extremely fragile.

Bitcoin's security depends on its usage winning a race against its reward halving schedule

Remaining secure after block rewards run out is one of the toughest challenges that Bitcoin faces. It's unclear whether users who send transactions will be willing to shoulder 100% of Bitcoin's security burden. However we have reason to believe that Bitcoin has a better chance of remaining secure after block rewards run out the more users it has at that time. While block rewards still exist, more users will help security remain high despite block reward halvings.

Putting Bitcoin on a growth path where it can take advantage of these two effects gives it a much better chance of remaining secure. We should be concerned that anything we do to slow Bitcoin's growth in the short term is endangering its long term survival.

Gavin makes this argument here.

Timing

We need temporary protection against high fees until Lightning is available

Having to pay high fees to transact using Bitcoin is only a concern for a brief period of time between now and when Lightning is released. Fees were cheap in the past, and they'll be cheap in the future (after Lightning). Any period of high fees now or in the near term will not be representative of Bitcoin fees in the future, so it makes sense to deploy a short term solution. This argument is made in more detail here.

Full blocks are coming soon, so we should act fast

In this essay, Mike Hearn argues that based on Bitcoin's historical traffic pattern, it's likely that after the winter of 2015/2016, blocks will start to regularly fill to capacity. Mike believes that this will cause lots of problems for Bitcoin -- a claim that is analyzed here.

Expectations/Continuity

An increase is part of the social contract

Gavin and Mike Hearn point to quotes from Satoshi which show that he seemed pretty nonchalant about increasing block sizes (see Gavin here, Mike here).

Here's Satoshi in November 2008:

"Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal."

Satoshi is laying out a vision where most people use SPV nodes, and Bitcoin processes 100 million transactions per day. It seems like he thinks this is a good thing and a natural course for Bitcoin.

Here's Satoshi in August 2010:

"It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore."

Satoshi is endorsing the idea of blocks growing very large. He calls it "the" eventual solution.

Does this show that large blocks are part of the social contract? Many people who joined the Bitcoin community were likely influenced by Satoshi's writings and wanted to contribute to the vision of Bitcoin that he laid out. That vision apparently involved lots of users making lots of transactions, and very large blocks.

Counterarguments

• It is possible that Satoshi did not realize the extent to which centralization pressures would constrain his vision. Someone posting from one of Satoshi's old email addresses and claiming to be Satoshi says that he didn't foresee mining pools, and this changes his analysis about large blocks.
  • There is a lot of dispute about the authenticity of this message.

• Greg Maxwell notes that Satoshi said both "Piling every proof-of-work quorum system in the world into one dataset doesn't scale" and "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices" in a post in December 2010. This suggests he was at least imagining the possibility that blocks may not grow extremely large as in his earlier descriptions. Satoshi seems neutral about this possibility, but it implies that he was open to Bitcoin users steering the system in a different direction than he initially described. The post was also after the other two Satoshi posts, so he could have changed his views on the issue.
  • Neither of the December 2010 quotes is inconsistent with with Satoshi's earlier quotes. The first doesn't preclude Bitcoin processing a huge number of financial transactions -- it's about whether to combine Bitcoin with non-financial networks. Because Satoshi seems neutral in the second quote, he may still prefer the vision he originally described and just be describing a hypothetical possibility. This quote is only four months after his quote about "the eventual solution."

Increasing the block size is the status quo approach -- doing nothing is a bigger change to the system

Jeff Garzik makes the point here.

Up to this point, there has been almost no fee pressure in Bitcoin. If we let blocks get full we'll introduce fee pressure and this will be a major economic change. Users have come to expect a lack of fee pressure, and suddenly experience it would be a painful shock to them as fees rise. Their experience would be very different than it is now.

In short. from the POV of users doing nothing would result in a big change, and raising the block size would not result in a noticeable change. Even though raising the block size changes the code and doing nothing does not, stability in user experience is more important than stability of code. Moreover, the code change to raise the block size is very simple.

Further, pretty much all developers agree with raising the block size at some point. So if we're just going to relieve fee pressure in the future anyway, forcing users to experience a sudden change in economics now only to restore the current environment in the future serves no purpose.

Counterarguments

• We need a fee market eventually, so it's good for one to develop now. Not letting one develop is just delaying the inevitable.
  • See counterarguments at the above link.
• Devs who are against a near term increase but for one in the future don't want to completely remove fee pressure with future increases. So letting a fee market develop now then raising the block size later isn't pointless.
  • It's OK that fee pressure develops, but we shouldn't encourage it to happen in a sudden and unplanned manner.

• Devs should not be in the position of setting economic policy. If economic policy changes based on conditions in the market, that's outside of the scope for Core devs.
  • Almost everyone agrees that block size should be raised eventually. Such a change will always impact the system's economics. So the decision to not raise the block size now but do it later is an economic policy being decided on by the devs. It's no less of an economic policy than raising the block size now.
  • The recognition that high fees are worse than low fees, all else being equal, is an economic position. If the core devs could magically make a change that lowers fees significantly but doesn't impact any other variables (decentralization, whether a fee market develops in the future, etc) it would be crazy not to make it, even though such a change would be purely economic.

• If users believe that cheap transactions will continue well into the future, then they don't understand that Bitcoin as it exists now doesn't scale. It's a problem is that users believe something that isn't true, so we should disabuse users of the notion that they'll be able to make plentiful free transactions forever by allowing a fee market to develop now.
  • The argument that Bitcoin can't scale is questionable. It depends on how fast usage grows in comparison to how fast technology improves.
  • We don't know ourselves that cheap fees won't last well into the future. Maybe increasing block size to 32 MB over the next 5 years and while buying time for layer 2 networks to develop on top of Bitcoin will result in fees being low indefinitely. We can't be confident enough that that won't happen to justify causing harm to our users now with high fees.

Layer 2

Lightning has many drawbacks

Mike Hearn lists several drawbacks to Lightning here, which make primarily by migrating users onto Lightning channels undesirable. The drawbacks are:

• Lightning adds complexity, making it harder to create Bitcoin wallets, so only large organizations with lots of resources can create fully featured Bitcoin wallets. This adds centralization to the wallet space.
• It's possible for people to steal your funds if you don't broadcast your transactions at the right time, which could happen for a variety of reasons (like a dead cell phone).
• If one party loses data, the other party can potentially steal some of their funds.
• Intermediate Lightning nodes need to keep funds in hot wallets, making them risky to secure.
• Lightning hubs are harder to run than Bitcoin nodes, because they are stateful.
• Lightning requires lots of communication between nodes, which may be slow.

Counterarguments

• Blockstream seems to be developing their Lightning implementation in a completely open source way, meaning that wallets should be able to use their code. So wallet development should not get that much more complex. Also, several people seem to be writing Lightning implementations on their own (including Rusty), so it's not that resource intensive. Especially once people can look at other people's implementations.

• Lightning will allow you to outsource the broadcasting of these time-sensitive transactions to 3rd parties in such a way that they can't steal your funds, and are also paid a fee for helping ensure you aren't ripped off. The time in which you need to broadcast these transactions can also be made as long as you and your counterparty agree to.

• It's much less important for there to be lots of Lightning hubs than it is for there to be lots of Bitcoin nodes. Things might work fine with 30 Lightning hubs. So if they need to be run more professionally than Bitcoin nodes, it's not a big deal.

• 0-confirmation transactions in Bitcoin are dangerous, so even if it takes half a second to send a Lightning transaction, it's still much better than the alternative.

Confirmations

Limited block space will result in a painful transaction backlog

Mike Hearn's has written an essay containing a detailed description of this argument. The high level outline is:

• As blocks become consistently full, confirmation times become huge. Mike cites an analysis by Dave Hudson which looks at what happens when more transactions than there is space for are sent.
  • Dave's analysis assumes everyone pays the same fee (or miners don't prioritize by fee).
• Full nodes are not currently designed to handle an ever increasing pool of unconfirmed transactions, so they'd eventually get extremely slow and/or crash.
• Users will become frustrated when their transactions don't confirm. They'll think the people running the network are incompetent. This will sour them on Bitcoin, and cause users to abandon it until usage plummets and fees fall back down to around zero.
• Even if changes to Bitcoin Core were made to limit the size of the mempool so full nodes didn't slow/crash, the user experience will still be horrible because
  • If a user submits a txn and the mempool is full, their txn will be rejected, frustrating the user.
    • This hinges on Mike's claim that a fee market wouldn't work, otherwise the user could immediately re-send with a higher fee.
  • Even if a txn appears to be accepted by other nodes, some other nodes may reject it because each node has their own potentially unique mempool. So a user won't really know how far their txn is propagating and thus how likely it is to be accepted in a reasonable time frame.
  • If there were a fee market and a user sent a txn with a high fee to break into the 'full' mempools of other nodes, then those nodes would kick out some other txn that had been previously accepted into their mempool. The user who sent the txn that got kicked out would have a bad experience.
• A fee market wouldn't solve the problem, because:
  • We currently lack the infrastructure for wallets to choose appropriate fees.
  • There's an effect where people will send a txn, notice the fee wasn't high enough, then send another txn bumping up the fee slightly. But since everyone else will be doing the same thing, their new txn will still have a too low fee, so they'll need to bump the fee again, etc. This will cause many more txns to be sent than necessary.

Counterarguments

• A fee market would result in reliable transactions for those paying high enough fees.
• Peter Todd points out that if the block size were increased, a fee market could still develop if demand increased enough. For example assume we did increase the block size to 20 MB, then adoption took off and we figured that we needed to bump up block size to 500 MB to prevent a fee market from developing. Would the response be that we must increase the block size to 500 MB?
  • I expect that Mike would reply as follows: there is some threshold at which blocks above that threshold would cause even more harm than allowing a fee market to develop, but 20 MB (or 8 MB) is lower than that threshold, whereas 500 MB is above it.