Who Decides Whether Bitcoin’s Rules Change?

(MENAFN  )

A proposal to change Bitcoin’s rules can become news long before it changes anything for the people using the network. An idea may have an author, a formal document, and working code while existing software keeps applying the old rules. Adoption is a separate step. Developers can write and publish a change; they cannot make everyone accept it. The people and businesses using Bitcoin choose which software to run and which rules to recognize. No executive or committee can decide for the whole network.

In a June 2025 statement, Bitcoin Core contributors said they could not dictate users’ software choices. They pointed to the project’s practice of avoiding automatic updates. A new release can be ready to download while older versions remain in use. Developers write and review changes, and maintainers decide what goes into a particular project. A maintainer can approve code for that project without controlling the computers that will run it. Users can keep an existing version or choose different software.

A Proposal to Change Bitcoin’s Supply

Bitcoin’s supply limit is a rule that gets a lot of attention. Miners create new coins as they add blocks of transactions, and the software checking those blocks limits how many they can create. This supply decreases periodically, with the maximum number of Bitcoin that can be created set at a fixed limit. In its July 11, 2026 report, AlphaWire covered StarkWare CEO Eli Ben-Sasson’s proposal to replace the fixed cap with a system that would keep creating coins each year. He argued that new coins could compensate for coins becoming inaccessible when owners lose the private keys needed to spend them. Under the existing rules, those inaccessible coins are not replaced.

Turning the suggestion into a change would require code specifying a different schedule and participants willing to accept it. Publishing that code would not update anyone else’s computer. Software following the old limits would still reject blocks that exceeded them, even if the person proposing the change had broad public support.

A detailed design can be published as a Bitcoin Improvement Proposal, or BIP. Authors describe the proposed change and address feedback. Editors assign a number once the submission meets the publication requirements. That number gives people a shared reference for discussion. It is not a network vote, an adoption timetable, or an instruction to install software.

The Rules Run on People’s Computers

A fully validating node is a computer that checks Bitcoin transactions and blocks. Its operator chooses the software doing that work. Miners assemble transactions into blocks; nodes check whether those blocks follow the rules they enforce. Even a block produced by a powerful miner can fail those checks.

Two operators can read the same proposal and choose differently. One may adopt revised rules while the other keeps the existing ones. Their computers can then disagree over whether a block is acceptable. Neither operator can make the other computer change its checks simply by accepting or rejecting that block. If miners keep producing blocks under incompatible rules, separate transaction histories can develop. Each operator’s software determines which history their computer recognizes as valid.

A publicly visible node count is not a ballot. One person can run several nodes, and many people use Bitcoin through services without operating a node themselves. A count of machines cannot show every user’s preference. For a hosted service, decisions about the software enforcing transaction rules sit with its operator.

Some upgrades preserve compatibility with older software, so adoption does not require everyone to install the same version on the same day. A routine repair affecting one software project may also proceed without a BIP. A new version number alone says nothing about whether Bitcoin’s shared rules have changed.

What Has Actually Happened?

“Developer Publishes Bitcoin Transaction Proposal” could be an accurate hypothetical headline on the day a document appears. “Bitcoin Changes Its Transaction Rules” would describe a different event. The first headline could remain true even if nobody had written software implementing the proposal.

A later release would establish that an implementation was available. Its release notes could identify the proposal and explain when the software would start enforcing the change. If the rules take effect only after specified conditions are met, installing the release and activating those rules are separate events.

The scope can be narrower, too. A wallet might adopt a shared format while other wallets continue using different designs. That is a change in the wallet’s software. It does not establish that Bitcoin now accepts transactions that the network previously rejected.

A Completed Proposal May Still Be Unused

The BIP process changed in January 2026. Bitcoin Optech reported the revised status labels, including “Complete” and “Deployed.” Authors can mark a proposal Complete when their planned work is finished and they recommend adoption. Specifications require working example code and test cases. A proposal can remain Complete indefinitely.

Deployed requires evidence of active use after the proposal has settled. The qualifying evidence depends on its scope: support in an established project’s released software can qualify. The label does not mean every participant uses it.

The January update was itself a deployed proposal, BIP 3, which replaced the previous proposal process on January 14. It changed the instructions followed by authors and editors, including the status labels. It did not activate a new transaction rule or authorize additional coins to be created.

MENAFN05102026009285019118ID1111761799