The way the bitcoin ecosystem will play out is written in the mathematics of its consensus rules; we should all know the three phases it will go through.
First Era: Satoshi’s Free Offer (2009–2014)
In the early years of bitcoin, it was obscure and unvaluable. Demand was so tiny you could send any amount for free. There was no real congestion, so software didn’t handle it, nor did business plans: gambling service Satoshidice famously sent a 1-satoshi payment to losing bets, using the infinite-capacity blockchain as a signaling layer. It was all free money.
Bitcoin was a new, barely-understood technology. It was hard enough to comprehend the interactions of its constituent parts, let alone extrapolate to what this would mean in future. Several factors made this worse:
- The pseudonymity and lack of central authority was deeply attractive to scammers, who became pervasive enough to make the permeation of real information extremely difficult and also lead to widespread distrust.
- The success of the system brought others who tried to replicate it (often with the main goal of simply generating money) and almost always with minimal understanding of the system.
- The early adopters had not only the normal tribalism of an emerging clique, but a concrete financial self-interest in adoption. The resulting boosterism meant it was extremely difficult for any awkward facts to permeate the wider ecosystem.
The result there was surprisingly low awareness that this phase of “free money” was not the natural state of bitcoin. The developers were aware, so added some configurable settings in the reference client to minimize the worst abuses. These rules did not change bitcoin, just the default behavior: they added a minimum fee, stopped relaying tiny payments, and enhanced the scripting language to reduce the size taken up by unspent outputs.
Second Era: Satoshi’s Subsidy (We Are Here)
“Bitcoin is shifting to a new economic policy, with possibly higher fees.”
The bursty statistical nature of block production, combined with the volatile market of bitcoin, began to produce intermittent capacity issues. These had been previously dealt with by code optimizations and tweaking settings by miners; now they became more regular and significant, causing rising awareness that the First Era was at risk.
Inevitably, many people wanted to prolong the free ride. This pressure was exacerbated by software and services unprepared for dynamic fee conditions, and the difficult nature of such fee conditions themselves: reliably guessing what fee would allow a transaction into the next block turned out to be difficult at best, and extremely difficult to present to users.
The developers’ general reluctance to support a naive increase stemmed from several factors:
- Previous increases on the network had driven significant centralization pressure, including a period where over half the network was under control of a single pool.
- This would be the first backwards-incompatible change since Bitcoin’s introduction.
- Providing a “one-off” bump risks moral hazard, as lobbying for expansion is seen as cheaper and easier than engineering improvements.
- Despite being expected, neither software nor services were preparing for the transition. This may have been because they didn’t really believe the transition would occur.
- The developers generally want to follow the community, not lead. Changes which are economically significant or contentious feed a narrative of developer reliance.
- Transitions in a large, complex system need to be as gradual as possible to avoid unintended side effects. As the Third Era approaches, the Second Era provides that gradual transition, with time for software and services to gain experience with bitcoin as it will eventually be.
The developers implemented several improvements to address congestion. First among them was wide-ranging and significant optimizationsdesigned to handle the network now running at capacity. Block propagation was improved by a global network of node relays and new strategies for better propagation. Fee estimation algorithms became more sophisticated, along with restoring the ability to replace transactions (by increasing the fee) and having the recipient boost transactions.
Despite centralization fears of larger blocks, an opt-in block expansion was added which will eventually double the network throughput as software is updated to use it. Work is ongoing on packing more transactions into blocks, which increases throughput without the centralization risks of block expansion.
It is not surprising that such efforts were seen for what they were: insufficient to maintain the First Era. Bitcoin’s use as a payment network, always awkward due to block time variance, became even harder: a whole class of payments below $20 were no longer viable. Businesses and users established in the First Era began looking longingly at alternate coins still in their own First Era, and also lobbied for relief. A significant mining monopoly had formed at this stage, and it joined these efforts.
Though these efforts failed, it’s important to note that while some who wanted the First Era to continue considered the Third Era avoidable, many just felt it shouldn’t happen now. The most convincing argument was that it would harm adoption, which is a major factor for both usefulness and regulatory resistance. Unfortunately this argument never becomes less compelling, and carries all the hazards enumerated above.
It is undeniable that an increase in transaction capacity reduces the eventual burden of fees, and is the main motivation for the growth plans which were implemented in this era.
Third Era: Self Sufficiency (2028? onwards)
“Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.”
— Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System
Once the “free money” bootstrap phases of bitcoin are complete the system enters the phase of self-sufficiency, where users bear the cost of securing the network against double-spending (currently billions of USD each year). This is phased in by halving the block subsidy every four years.
Current levels suggest fees will be comparable with the subsidy at the 2024 halving, and consistently dominate from 2028 onwards.
User-facing businesses established in the First Era who flourished into the Second Era will find the Third Era extremely difficult. One large business claims to be responsible for 25% of the bitcoin transactions: in 10 years they would be paying $700M per year to secure the network at current levels. Yet no business is telling their investors about this impending cost, nor that they plan on reducing their on-chain percentage nor suggesting that they are depending on significant bitcoin appreciation to offset these costs.
Miners will find the Third Era equally difficult. Directly supported by users, they will be in constant tension with them over fee levels, and in danger of having their income squeezed by large businesses or cliques of users. This may lead to further centralization, as miners consolidate under revenue pressure. This centralization may be offset by businesses choosing to invest directly in mining, however.
The Third Era Will Start With Civil War
The mathematics of this situation seem inevitable: The miners and businesses with large transaction volume will both decide to (re)introduce inflation. For the large-volume businesses this will externalize their costs, and for miners it’s simply “free money”. The battle lines will be similar to the early Second Era New York Agreement, but this effort will be more nuanced and far broader, with mainstream arguments such as:
- The founder was not an economist; Economists recommend inflation around 1% to encourage spending.
- The support burden of the network should be shared by the wealthy bitcoin holders, not just those actually using their bitcoin.
The counter-arguments are:
- The 21 million bitcoin limit was a key reason for bitcoin’s success,
- The system’s founder made a conscious and deliberate choice for bitcoin to be a store-of-value over subsidizing payments, by eschewing inflation, and
- Changing the rules now is stealing from early adopters (notably, but not mainly, the anonymous founder).
The main resistance to this change would come from the developers themselves (who feel this limit is non-negotiable) and long-term bitcoin holders. Businesses will be divided: those which cater to the latter (insurers, vaults) will be against the change, and those with high onchain volume (exchanges, wallet providers) will be for it.
Although this crisis is entirely predictable from first principles, and laid in the bedrock of bitcoin, it may yield surprising results. And even if bitcoin’s supply remains capped, the drama it can produce is limitless.
Footnotes, Containing Further Reading
 Some of the complexity with building a cryptographic currency are detailed in https://download.wpsoftware.net/bitcoin/alts.pdf
 The default “mintxfee”: the fee below which normal transactions would not be accepted by nodes; this reduced spam from tiny transactions. As a compromise, transactions which were spending old bitcoins were exempt from this (so-called “priority transactions”) as they are by nature a finite resource. https://en.bitcoin.it/wiki/Transaction_fees#Settings
 The default “dust limit”: tiny payments below this would not be accepted by nodes; this avoided creating tiny payments which would never be economical to spend in future. It was considered a controversial restriction on Bitcoin, as demonstrated by https://bitcointalk.org/index.php?topic=196138.0. This foreshadows the confusion to be felt later.
 Pay-to-script-hash moves the “what do I need to prove to spend this bitcoin?” script to the spender. Before this, the whole network has to remember those exact requirements for spending each coin (which adds up to quite a lot over time). https://en.bitcoin.it/wiki/Pay_to_script_hash
 The fee depends on the size of the transaction, and not the amount transferred. It’s analogous to a courier charging by weight: sending 1000 pennies is going to be more expensive than sending a $100 bill. That makes engineering sense, but it’s deeply counterintuitive for a user who doesn’t know if they are holding pennies or bills.
 The blocksize default limit increased to 750 kilobytes around this time https://blockchain.info/charts/avg-block-size?timespan=all. Miners complained of their “orphan rate” increasing: blocks losing the race to extend the blockchain because they took too long to reach the other miners. This problem is less for larger miners, who are more likely to find the next block as well. This seems to be the main force behind Ghash.io’s rise: orphaning will be rarest on the largest pool of miners. https://www.coindesk.com/bitcoin-mining-detente-ghash-io-51-issue/
 As November 2017 neither blockchain.info nor Coinbase (both of which claim large transaction volumes) have adopted Segregated Witness, despite the technology being finalized at the end of 2015.
 This trend was begun by the anonymous founder Satoshi Nakamoto leaving the project.
 Unfortunately growth has fairly evenly tracked improvements, meaning new nodes don’t synchronize with the network any faster than they did a few years ago. https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
 It’s actually difficult to get older nodes to synchronize to the modern network, but with small fixes it’s possible. It takes about 30 seconds per block on a fast machine, however. https://medium.com/provoost-on-crypto/historical-bitcoin-core-client-performance-c5f16e1f8ccb#874c
 Matt Corallo both releases code to run your own global high-performance relay network, and runs one himself. http://bitcoinfibre.org/
 Since most transactions contained in a block have already been seen, nodes save a lot of bandwidth and time by sending a summary. Average block propagation is now faster than transaction propagation, in fact. https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/
 An excellent summary of evolving techniques and challenges: https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72
 Bitcoin originally supported upgrading transactions which weren’t in blocks yet using a sequence number, but this was removed as it allowed users to flood the network with transactions. Replace-by-fee restores this ability, but only if the fee increases significantly. https://bitcoincore.org/en/faq/optin_rbf/
 Instead of just considering the fees paid by a transaction, software also considers the fees paid by any transactions which spend this it, which might make it worth including both in the block: so-called “child-pays-for-parent”. https://bitcoincore.org/en/faq/optin_rbf/#what-is-child-pays-for-parent-cpfp
 Segregated Witness moves signatures of transactions which support it to elsewhere in the block. The design counts those signatures (which are not seen by older nodes) as if they were 1/4 of the size; on current transactions patterns this would mean an average block of about 2MB if all users were to use such transactions. https://bitcoincore.org/en/2016/01/26/segwit-benefits/
 While each transaction takes time to validate, even low-end CPUs are now powerful enough: the main capacity constraints are network bandwidth and long-term storage requirements. https://bitcoincore.org/en/2016/06/24/segwit-next-steps/#schnorr-signatures and https://bitcoincore.org/en/2016/06/24/segwit-next-steps/#mast
 The most serious effort was Digital Currency Group’s New York Agreement: https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
 The argument that “maybe someone else will pay for it” instead of bitcoin users seems unsupportable by a reality in which Santa Claus does not exist. https://medium.com/@octskyward/hashing-7d04a887acc8
 At current levels, and 1c transaction fees, it would take 1 million transactions per block to support the network, or a 225MB block size (median transaction size). With current block size, it would require $20 transaction fees.
 52,560 blocks per year, 12.5 bitcoin subsidy and 2 bitcoin fee per block, $8000 USD/BTC = 6 billion USD.
 The “halvening” happens every 210,000 blocks. Bitcoin was launched with a 50BTC block reward in January 2009, becoming 25BTC in November 2012 and 12.5BTC in July 2016. You can follow the excitement at http://www.thehalvening.com/
 This assumes fee levels of 3 BTC per block, which is slightly higher than the average current levels. That corresponds to about 450 BTC a day on this chart: https://blockchain.info/charts/transaction-fees?timespan=all#
 This assumes only that miners are receiving the same USD income as now, but half is from fees.
 The current trend seems to be the opposite: companies raising funds brag about how dominant they are on the network in terms of transactions.
 If the bitcoin price rises significantly, then miners may be fine with smaller fees. However, if your business plan relies on a significant bitcoin price increase, wouldn’t investors just buy bitcoin instead of investing in your business?
 Given the exposure of bitcoin businesses to extortion by a mining cartel (who could profitably censor their transactions), investing in mining makes sense, as does development of fungibility improvements to make targeting companies more difficult. Neither has yet occurred from large businesses, though.
 I would oppose such a proposal, too, and believe it would fail. But I’m convinced it will be seriously proposed and adamantly promoted.
 Of particular note: if some capacity growth like Pieter Wuille’s 17% growth per-annum is adopted, at some point there may be excess capacity again, driving fees to zero and threatening the security of the chain. The developers will presumably propose a soft fork implementing some kind of lower limit in non-busy periods, and miners can be anticipated to side with the developers against the short-term users and businesses.
 Block size following technological growthhttps://gist.github.com/sipa/c65665fc360ca7a176a6
 Such as Mark Friedenbach’s flexcap proposal, which is simplest to implement once the subsidy can be ignored. https://scalingbitcoin.org/transcript/hongkong2015/a-flexible-limit-trading-subsidy-for-larger-blocks