How Bitcoin's rules are changed, and who can change them

Bitcoin has no owner, no head office and no board that can issue an instruction. Its rules live in software, and a rule only holds while enough independent people choose to run software that enforces it. That single fact explains the entire change process.

Nobody owns the network

The Bitcoin project's own frequently asked questions page states it directly: "Nobody owns the Bitcoin network much like no one owns the technology behind email." It goes on to describe how changes happen. They are proposed in public as Bitcoin Improvement Proposals, reviewed by developers, and "only take effect if users, miners, and node operators voluntarily adopt them."

That design is deliberate and traces back to the 2008 whitepaper, which set out to let payments be sent from one party to another without going through a trusted third party. Removing the trusted third party also removes the body that would otherwise approve changes to the rules. Nothing was put in its place.

How a change is proposed

A Bitcoin Improvement Proposal, usually written as BIP, is a design document. Anyone can write one. BIP 1 created the process in 2011, BIP 2 revised it in 2016, and BIP 3 replaced BIP 2 in 2025 with the streamlined workflow used today.

The steps are ordinary and public:

1. The idea is raised and argued over on the public development mailing list and in other open forums.
2. The author writes a draft in a fixed format, covering motivation, specification, backwards compatibility and reference code.
3. A BIP editor checks it is well formed and assigns it a number.
4. The proposal is reviewed, revised, and given one of four statuses: Draft while it is being worked on, Complete when the author considers the work finished, Deployed once it is settled and in use, and Closed if it is of historical interest only.

The important part is what a number does not do. A BIP number is an index entry, not a permission. The status field records what happened to a proposal; it does not cause anything to happen. Numbers many readers have seen, such as BIP 32 for hierarchical wallet keys, BIP 39 for seed phrases, BIP 141 for Segregated Witness and BIP 341 for Taproot, are references, not decrees.

The next stage is code. A proposal has to be implemented, most commonly in Bitcoin Core, where the change is reviewed and merged in public. Merging code produces a software release. It does not change the network. The network changes when operators install the release and run it.

Soft forks and hard forks

The type of change decides how much agreement it needs.

Because a soft fork keeps everyone on one chain even when some operators have not upgraded, almost every change made to Bitcoin's consensus rules has been a soft fork. A hard fork needs practically everyone to move at once, which is why proposals requiring one rarely reach activation.

Who actually decides

Four groups hold different pieces of the decision, and none of them holds the whole thing.

There is no vote, no share register and no quorum. Each group can decline. A change reaches the network when all four groups happen to arrive at the same answer, and stalls when they do not.

The dispute that answered the question in practice

Between 2015 and 2017 the argument over Bitcoin's capacity turned the theory into a test case.

Bitcoin blocks had carried a one megabyte size limit since 2010. As usage rose, one part of the community wanted the limit raised directly, which would have been a hard fork. Another part supported Segregated Witness, described in BIP 141, a soft fork that restructured how signature data is counted and introduced a block weight limit of four million weight units, increasing effective capacity without editing the old field.

Activation used the mechanism in BIP 9, where miners set a bit in the block version field to signal readiness, and the rule locks in once 95 per cent of blocks in a 2,016 block period carry the signal. Signalling sat well below that level for months, and the deployment stalled.

Two responses in 2017 broke the deadlock. BIP 148 proposed a user-activated soft fork, in which node operators would from 1 August 2017 reject any block that failed to signal Segregated Witness. Separately, BIP 91 made that signalling compulsory among the miners who ran it. Signalling rose sharply, the rule locked in, and Segregated Witness became active at block 481,824 in August 2017.

On the same 1 August, part of the ecosystem ran software with a larger block size limit that the existing rules did not accept. That was a hard fork, and it produced a second chain with its own coin, Bitcoin Cash. Both chains continued to operate. Nobody was stopped and nobody was compelled, which is the whole answer to the question of who is in charge.

Taproot in 2021 is the quieter version of the same mechanism. BIP 341 was signalled under a 90 per cent threshold, locked in during June 2021, and became active at block 709,632 in November of that year, with no split and very little drama.

Can the 21 million limit be changed?

New coins are created by mining at a decreasing and predictable rate, with the reward halving every 210,000 blocks, and total issuance limited to 21 million.

The cap is a line in software, so it can be edited. What no group has is a way to make that edit apply to everyone else. A node still running the existing rule rejects any block that creates coins beyond the cap, so the outcome of a partial change is a separate chain rather than a raised limit on the original one. A rule is hardest to change when it is the reason people are on the network at all.

What is still unsettled

Two questions remain openly argued and have no agreed answer. The first is how activation itself should be decided, since BIP 9, BIP 8 and the shorter signalling window used for Taproot each distribute the decision differently between miners and node operators. The second is how mining is paid for as issuance keeps falling and transaction fees become a larger share of the reward. Both are discussed in the same public forums as everything else, and neither is closed.

Where to look next

• Bitcoin price in Australian dollars - the live figure, updated from a named feed.
• Crypto data pages - live values for the coins Tradergy tracks.
• Glossary - plain definitions of the market terms used across the site.
• Guides - the rest of the explainer library.

Sources

• Bitcoin FAQ, bitcoin.org - ownership, the proposal process, voluntary adoption, mining issuance and the 21 million limit.
• Bitcoin: A Peer-to-Peer Electronic Cash System (2008) - the original design goal of payments without a trusted third party.
• BIP 1, BIP purpose and guidelines - the original proposal process.
• BIP 2, BIP process, revised - the 2016 workflow, now closed and superseded.
• BIP 3, Updated BIP Process - the current workflow, editor role and status values.
• BIP 123, BIP Classification - the soft fork and hard fork definitions.
• chainparams.cpp, bitcoin/bitcoin - nSubsidyHalvingInterval, the 210,000 block halving interval.
• BIP 9, version bits with timeout and delay - miner signalling and the 95 per cent threshold.
• BIP 141, Segregated Witness - the consensus change and block weight limit.
• BIP 148, mandatory activation of SegWit deployment - the user-activated soft fork.
• BIP 341, Taproot - the 2021 change and its activation.
• Bitcoin Core contributing guide - how proposed code is reviewed and merged.

General information about how the Bitcoin protocol is governed and changed. Not advice, not a recommendation, and not a view on any asset. Tradergy keeps no account and collects no personal data. Reviewed by the Tradergy editorial team, September 2026.