ryanwold.net - BIP 110 as a blip in the bitcoin ecosystem

Bitcoin Protocol Governance

A change nobody could agree on: what the BIP-110 episode shows about who actually controls Bitcoin

This week's most consequential blockchain story wasn't a bill or a rule — it was a dispute inside Bitcoin itself, and it's a useful, low-stakes preview of a question every agency evaluating blockchain eventually has to ask: who is actually in charge of this network, and what happens when they disagree? No government system depends on Bitcoin's technical rules today, but the pattern this week — how a change gets proposed, who gets to say yes, and what happens when they say no — is the same pattern that would govern any public blockchain an agency chose to build on.

The proposal. A group of contributors wrote a change called BIP-110 ("BIP" just means "Bitcoin Improvement Proposal," the formal way changes get suggested). It would have temporarily blocked certain ways of stuffing unrelated data — images, files, arbitrary text — into Bitcoin transactions, on the theory that this data bloats the ledger every computer running Bitcoin has to store forever, and that Bitcoin should stay focused on being a payment and savings network rather than general-purpose file storage. Critics, including well-known Bitcoin figures like Adam Back and Michael Saylor, argued the opposite: that once you let anyone decide certain valid, paid-for transactions don't belong on the network based on what they contain, you've created a tool that could later be used to block any transaction someone in power dislikes.

Who actually gets a vote. This is the part worth sitting with: developers can write and propose a change, but they cannot make it happen. Bitcoin has no CEO, no board, and no central authority that can order an update installed. Changes take effect only if the people who run the "miners" — the computers that do the heavy processing work that confirms transactions and produces new blocks — choose to adopt the new software. BIP-110 needed 55% of newly mined blocks to signal support during a set window in order to activate smoothly. It got about 2.53%.

What happens when the vote fails but backers proceed anyway. Most proposals would simply die at that point. BIP-110 was written differently: its supporters intended to enforce it regardless of whether the rest of the network agreed, which meant that when the window closed, the network split into two separate, incompatible versions of Bitcoin — one continuing exactly as before, and a second, new chain that only BIP-110 supporters recognized as valid. This is technically straightforward to do — anyone can copy the software and change the rules — but only useful if enough of the network's processing power and its users come along. Almost none did: within a day, over 99.8% of Bitcoin's processing power was still confirming transactions on the original chain, while the breakaway chain produced two blocks and then effectively ground to a halt, because too few computers were doing the work needed to keep it moving at a normal pace.

The escalation, and why it matters. Rather than accept that outcome, BIP-110's backers announced they're now developing a plan to change the underlying math problem miners solve to confirm blocks — which would make every existing piece of Bitcoin mining hardware in the world unable to work on their chain, intentionally cutting out the miners who declined to support them, and requiring them to attract entirely new computing power, plus new exchanges and users, essentially from zero. Whether that plan succeeds or not, the sequence itself is the governance lesson: a well-organized, well-funded, technically capable group tried to change the rules of a major public network, and the network's broader participants — miners, businesses, and users who simply kept using the original version — outweighed them, without any vote being formally "denied" by an authority. The decision was made collectively, informally, and economically, by who showed up and kept using which version.

Why this belongs in a public-sector conversation. If an agency ever builds on, accepts payments in, or relies on a public blockchain, this is the governance model it inherits: no single party — not the original developers, not any government, not even a well-resourced coalition — can unilaterally guarantee the network's rules won't change or won't fork. Stability comes from broad, ongoing agreement among a decentralized set of participants, not from an authority an agency could call, contract with, or hold accountable in the way it would a vendor. That's a real advantage for censorship-resistance and neutrality, and a real complication for anyone who needs predictable, governable infrastructure — worth naming explicitly in any risk or adoption conversation, rather than assuming "the blockchain" behaves like a system someone owns.