Bitcoin's blocks had a size limit. It constrained how many transactions could be processed, and as usage grew, fees rose.
One side wanted bigger blocks: keep fees low, preserve the payments use case, do the obvious thing. The other side argued that bigger blocks raise the cost of running a node, and if running a node gets expensive, fewer people validate independently, and the property from F101-04 quietly erodes.
In May 2017 the New York Agreement committed dozens of companies and a majority of hashpower to a two-part plan: activate SegWit, then hard fork to 2MB blocks six months later.
SegWit activated in August 2017. On 1 August, a faction hard forked to 8MB blocks and became Bitcoin Cash.
Then the second half collapsed. Node operators and users rejected it as a deal made by companies over their heads. On 8 November 2017, SegWit2x was called off before it ever activated.
Two years of conflict, a permanent chain split, and an abandoned upgrade, over a parameter change that the arithmetic below shows would not have delivered the capacity everyone was ostensibly arguing about.
Because throughput was not what was being decided. The question was who gets to change Bitcoin. The answer that emerged is that a coalition holding most of the hashpower and most of the large companies could not, because ordinary node operators declined to run the software.
Whether you think that was a triumph or a tragedy is exactly the disagreement this lesson is about, and we are not going to settle it for you.
Bitcoin and Ethereum get compared the way phones get compared, as though one is a better version of the other. They are not competing products. They are answers to different questions, and almost every design difference falls out of which question was asked.
Two questions
Bitcoin asks: can we have money that nobody can debase or seize?
If that is your goal, the most valuable property of your system is that it does not change. A supply commitment is only credible if changing it is close to impossible, so you deliberately make yourself hard to modify. Conservatism is not caution here, it is the feature.
Ethereum asks: can we have a shared computer that nobody controls?
If that is your goal, you need expressiveness: arbitrary programs, running on shared state, that anyone can deploy. That is a far larger design space, it is not going to be right the first time, and it requires ongoing change. So you build the capacity to upgrade, and you use it.
Everything else follows.
| Bitcoin | Ethereum | |
|---|---|---|
| Central question | Money nobody can debase | A computer nobody controls |
| Scripting | Deliberately limited | Deliberately general |
| Change | Rare, backward-compatible where possible | Regular, including breaking upgrades |
| Supply | Fixed schedule, treated as sacred | Adjustable, has changed several times |
| Failure mode | Ossification, missing something it needed | Complexity, and bugs in the surface area |
| Value of not changing | The entire proposition | A cost to be managed |
Neither column is the correct one. They are consistent answers to different questions, and a system that tried to do both would do neither.
What conservatism costs
Be specific, because "Bitcoin does not change" is usually said as either praise or dismissal and rarely as an accounting.
It buys: a supply schedule that is credible precisely because two years of institutional pressure from most of the industry failed to alter a single parameter. That is not a slogan; it is an observed result with a date on it.
It costs: slow adaptation, capabilities that live on other layers or not at all, and a governance process that resolves major questions by exhausting everyone.
The reverse is equally true of Ethereum. Shipping change means it has adapted repeatedly. It also means the DAO fork in F101-03, a larger surface area, and a supply policy that is a decision rather than a commitment.
The block size fight was framed as a fight about payments. Size it, because the sizing is what makes the whole episode legible.
Bitcoin at 1MB. A typical transaction is roughly 250 bytes, and a block arrives about every 600 seconds.
Transactions per block = 1,048,576 / 250 = about 4,194
Transactions per second = 4,194 / 600 = about 7
At 8MB, the figure Bitcoin Cash adopted, capacity scales linearly:
7 x 8 = about 56 per second
Now the comparison the argument was implicitly making. Card networks handle on the order of thousands of transactions per second, with peaks well above that. Take 5,000 as a modest reference point.
Multiple needed from 1MB: 5,000 / 7 = about 714 times Multiple still needed at 8MB: 5,000 / 56 = about 89 times
Read the second number. After winning the fight, splitting the chain, and taking an eightfold increase, you are still short by a factor of roughly ninety.
Which means the honest conclusion is uncomfortable for both sides. The small-block camp was right that 8MB did not solve payments. The big-block camp was right that 1MB definitely did not either. What the arithmetic actually shows is that no achievable block size solves it, because a global replicated log that every participant verifies cannot reach card-network throughput by making the log bigger. That is the constraint from F101-03, and it is a property of the design rather than a parameter.
Which is why both systems eventually went the same direction: settlement on the base layer, volume on layers above it. The two-year war was fought over a parameter that could not have decided the question either way, and that is the most useful thing about it.
What the episode revealed about governance
Strip the technical argument and what remains is the more interesting result.
A coalition holding the majority of hashpower and most of the large companies in the industry agreed on a change. In almost any other system that is the end of the discussion. It did not happen, because thousands of individual node operators simply did not run the software, and a rule nobody enforces is not a rule.
That tells you where power actually sits, and it is not where the org chart suggests. It is with the people running validating nodes, which is precisely why the small-block argument cared so much about the cost of running one. The two halves of that fight were connected in a way that was not obvious at the time.
It also tells you what F101-03 meant in practice. Coordination cost is the mechanism, and here it was high enough that a well-funded, well-organised majority could not pay it.
One of these will win, so I should work out which.
This framing has cost people a lot of money and a lot of time, and it misreads what the two things are.
They are not competing for the same job. A settlement asset optimised for not changing and a programmable platform optimised for capability are complements at best and unrelated at worst. Asking which wins is like asking whether gold beats the internet.
The framing also smuggles in a prediction, and P10 applies: we are not going to tell you what to hold or imply that either appreciates.
The question worth asking instead is a design question, and it has an answer. Which property does the thing I am trying to do actually require?
If you need a supply commitment nobody can alter, you need a system that is hostile to change, and you should be pleased rather than frustrated when it refuses to adapt.
If you need programmability, you need a system that changes, and you are accepting upgrade risk and complexity as the price.
If you need thousands of transactions a second and low fees, the worked example says neither base layer is your answer, and you should be looking at what sits on top of them, or at whether you need a chain at all.
Reading any other chain
Almost every other system positions itself somewhere between these two poles, usually by claiming to have removed the tradeoff.
The question to ask is always the same, and it is F101-03's chokepoint question wearing different clothes: what was given up? Higher throughput usually means higher hardware requirements for validators, which means fewer of them, which means the property in F101-04. Faster finality usually means a smaller validator set or a different trust assumption. Cheaper usually means subsidised, and subsidies have a burn rate, which is the next lesson and also the course autopsy.
Nobody has repealed the tradeoff. Some have made a good trade for a specific purpose, which is a real achievement and a much smaller claim than the one on the website.
Bitcoin asks whether we can have money nobody can debase, so it is deliberately hostile to change, and that hostility is the product rather than a limitation. Ethereum asks whether we can have a computer nobody controls, so it must be expressive and must keep changing, and pays for that in complexity and upgrade risk. The block size war looked like a fight about capacity and the arithmetic shows no achievable block size would have delivered it, so what was really decided was who is allowed to change Bitcoin, and the answer was that a majority of hashpower and most of the industry could not. When you meet any other chain, do not ask which one wins. Ask which property your use actually needs, and what was given up to provide it.