Hard fork resistance underpins the supply cap

Bitcoin's resistance to incompatible rule changes is what secures its monetary properties: because a hard fork can change anything — the 21 million cap, even the ownership of coins — the extreme difficulty of executing one is itself the guarantee that those properties survive.

For (strongest version as argued): A hardfork can essentially change Bitcoin in any way, from raising the supply cap above 21 million to taking coins from any holder and giving them to someone else; in the small-block worldview recorded here, resistance to this is precisely what made the network resilient — it meant nobody could take away their coins and ensured the cap was robust. The argument scales with the stakes: if the rules could not withstand a dispute in which only a few hundred people really cared, they would never withstand the immense pressure that mainstream financial and political players would apply as the system's value grew. The status quo had to be defined, and there had to be standing dynamics — not goodwill — ensuring it would survive and prevail. The 2015 email from a Satoshi address made the design claim outright: the system was built so that future modifications to the consensus rules would be difficult without near-unanimous agreement. Once incompatible change is normalized as a majority-rules procedure, every property of the system becomes negotiable at the next contested majority; refusing the procedure is how the properties stay non-negotiable.

Against (strongest version as argued): The large-block camp's answer, in the same source, is that this is the slippery-slope fallacy and a red herring: raising a capacity parameter is not confiscation, and a community capable of telling the two apart can permit one while refusing the other — the argument treats all incompatible changes as the same kind of change precisely to avoid debating the one on the table. The cost of the resistance machinery was also on display: the source records almost universal agreement that 1 MB was too small, yet no agreed way to change it — a system that cannot execute a change nearly everyone wants is not obviously robust; it may simply be stuck, and its stuckness pushed change into worse channels (rival clients, miner brinkmanship, exhausting social war). The anti-censorship catch-22 applies here too: if the bar for incompatible change is near-unanimity, and campaigning for change is itself treated as an attack, the bar can never be met even when it should be.

Nuance: Three claims travel together and should be separated. (a) A hard fork is unconstrained by prior rules — protocol fact (see soft-fork-vs-hard-fork). (b) Difficulty of hard-forking protects the monetary properties — this entry's contested governance claim. (c) No hard fork should ever happen — a maximalist extension that even the war's small blockers did not uniformly hold: the source records small-block figures offering staged hardfork increases (2-4-8 MB). Note also what actually does the protecting: nothing technical prevents a hard fork — bitcoin-cash-split records one happening — what protects the cap is that economically relevant node operators refuse rule-loosening chains (nodes-enforce-rules, supply-cap-enforcement), a fact about the userbase that has to be re-earned continuously rather than a property the protocol enforces on its own.

Sourcing: a single owner-research file — the owner's reading notes on The Blocksize War (Bier), a secondary account whose substantive coverage stops at February 2016 plus fragments — so INGEST_PLAYBOOK.md caps this at CONTESTED with confidence low. The email quoted for the design-intent point is one the source itself can only call probably genuine or hacked; nothing here was cross-checked against primary records this session.

Common misstatements: "The 21 million cap is cryptographically fixed" (it is a consensus rule nodes enforce; a hard fork could change it for whoever follows that fork — see supply-cap-enforcement). "Any hard fork endangers the cap" (hard forks require opting in; the argued danger is normalizing majority-rule incompatible upgrades, not the existence of forks). "Hard forks are impossible in Bitcoin" (they are possible and have happened — see bitcoin-cash-split; they do not automatically carry the name, the users, or the price). "Satoshi said the rules must never change" (the quoted email says difficult without near-unanimous agreement, its authenticity is unverifiable, and appeals to it settle nothing — see satoshis-intent-cannot-settle-protocol-disputes).