Who Enforces Bitcoin's Rules, and How Do They Change?

Every full node enforces Bitcoin’s rules for itself. A full node is a computer running Bitcoin software that downloads every block and checks it against the rules in that software. A block that breaks any rule is rejected, however much computing power went into it. Miners only choose which valid transactions go into a block, in what order, and which valid chain to build on. Nobody can change the rules your node enforces except you, by installing new software. A change takes hold across the network only when enough node operators, above all those who accept bitcoin as payment, and miners choose to run it.

This tells you what no company or miner can do to your bitcoin, such as create extra coins or spend yours without your key. It lets you read headlines like “miners vote for an upgrade” correctly. And when the network splits, as part of it did in August 2026, it tells you what to check before you move funds.

Who Does What: Nodes, Miners and Users

Full nodes check every block

A full node checks each new block against its consensus rules, the rules that decide whether a block is valid. Among other things, it checks that:

every transaction carries a valid signature from the key that controls the coins it spends (see keys, addresses and signatures);
no coin is spent twice;
the miner pays itself no more than the new coins allowed at that height (3.125 BTC per block since April 2024) plus fees;
the block fits the size limit of 4 million weight units, a measure in which signature data counts less;
the block carries enough proof of work and builds on a block the node already accepts.

The node does this alone and needs nobody’s permission to reject a block. There are tens of thousands of full nodes, of which roughly 15,000 to 20,000 accept incoming connections (November 2026).

Miners propose blocks

A miner runs specialized machines that compete to add the next block by doing proof of work, a costly computing race explained in how proof of work secures Bitcoin. Miners decide which valid transactions go into their block, usually the best-paying first, and which valid block to build on, normally the newest block of the chain with the most accumulated work.

Miners can leave transactions out. A group with most of the hash power (the network’s total mining computing power) could rewrite recent blocks. It could also refuse to build on any block that includes certain transactions: censorship, not a rule change, because those transactions stay valid. But no amount of hash power makes an invalid block acceptable: every full node discards it, just like a block with a forged signature.

Users choose the software

A user here means anyone who holds or accepts bitcoin: you, an exchange, a shop, a wallet company. Each relies on a node, their own or someone else’s, to say whether a payment is real, so that node’s rules decide what they accept as bitcoin. That gives the people and businesses who accept bitcoin as payment real weight: miners are paid in coins, and coins are only worth something on a chain that buyers and sellers accept.

Developers write the software and propose changes, but nobody has to install what they write.

Developers write new versions of the software. You choose which version your node runs and install it. Miners pick valid transactions and build blocks, and send each new block to your full node. Your node checks every block against the rules of the version you installed: a block that passes every rule is added to your chain; a block that breaks any rule is rejected, however much work went into it. Only you can change the rules your node checks, by installing new software. — **Developers write, you choose, miners propose, your node checks.** New rules reach your node only through software you install, and a miner’s block joins your chain only if it passes those rules. Exchanges, shops and wallet companies choose for their own nodes in the same way.

The table sums up the four roles.

Group	What it decides	What it can’t do
Full nodes	Whether each block is valid, by the rules their software runs	Make any other node accept or reject anything
Miners	Which valid transactions go in a block, their order, which valid chain to extend	Make an invalid block valid, create extra coins, spend coins without a valid signature
Users and businesses	Which software their own node runs, and so which coins they accept	Change the rules for anyone else
Developers	What code they write and propose	Make anyone run it

Why Nodes Don’t Vote

You will often read that nodes “vote” on blocks or upgrades. They don’t. Each node applies its rules and keeps every block that passes. Among the chains that pass, it follows the one with the most accumulated proof of work. Work only chooses between valid chains; it never makes an invalid one count.

A chain splits into three branches. The top branch has the most blocks, so the most work, but its first block creates 4 BTC of new coins, more than the rules allow, so your node ignores it together with every block built on top of it. The middle branch is valid and has the most work among the valid branches: your node follows it. The bottom branch is valid but has less work, so it is left behind. Rules first, then work: work only chooses between chains that follow the rules. — **Nodes don’t vote; they filter, then follow the work.** A branch with one invalid block is ignored however long it grows. Among the branches left, your node follows the one with the most accumulated proof of work.

Counting nodes couldn’t work as a vote anyway: anyone can start a thousand nodes on rented servers. A node’s power is more personal. It protects whoever relies on it: a block your node rejects can’t fool you, whatever everyone else does.

Consensus Rules and Relay Policy

Nodes apply two kinds of rules, and today’s debates hinge on the difference.

Consensus rules decide whether a block is valid. Two nodes that disagree on one end up following different chains.
Relay policy decides which unconfirmed transactions a node keeps in its mempool, its waiting room for unconfirmed transactions, and passes on to other nodes. It is a local preference that any operator can change without leaving the network. A transaction your node declines to relay is still valid, and if a miner includes it, your node accepts that block.

Two cases. First, two nodes differ on relay policy: your node doesn't pass a transaction on, another node does. They stay on one chain, because both accept the block a miner puts the transaction in. Second, two nodes differ on consensus rules: your node rejects a new block as invalid, another node accepts it as valid. The chain splits in two and each node follows the blocks it accepts. Only consensus rules can split the chain; relay policy is a local preference. — **Relay policy is a preference; consensus rules decide which blocks count.** Nodes can set relay policy differently and still agree on every block. Disagree on a consensus rule and they no longer accept the same blocks.

How Rules Change: Soft Forks and Hard Forks

A change to the consensus rules is called a fork, and there are two kinds (the blockchain lesson has a diagram of both):

A soft fork tightens the rules: some blocks that used to be valid become invalid, and nothing invalid becomes valid. Nodes that don’t upgrade still accept the new blocks and stay on the same chain, but they don’t check the new rules themselves.
A hard fork loosens the rules: something that used to be invalid becomes valid. Nodes that don’t upgrade reject the new blocks, so either everyone switches software or the chain splits in two.

A soft fork goes smoothly only if most of the hash power enforces the new rule. If not, upgraded nodes reject the blocks that break it, old nodes accept them, and the chain splits after all. So soft forks are usually coordinated by miner signaling, a method set out in BIP 9 (a Bitcoin Improvement Proposal; more on these below). Miners set one bit in the version number in each block’s header to show they are ready. The new rules lock in once enough blocks in a 2,016-block period (about two weeks) have signaled, and take effect one period later. Signaling is a readiness check, not a vote.

Two outcomes of a soft fork. First, most hash power enforces the new rule, as with Taproot: the 90% signaling threshold was reached on 12 June 2021 and the rule started on 14 November 2021. Every new block follows the rule, so nodes with the rule and nodes without it accept the same blocks, and there is one chain. Second, most hash power ignores the new rule, as with BIP-110: about 2.5% of blocks signaled (51 of 2,016) against the 55% needed, and the rule started on 8 August 2026. Nodes with the rule reject the first block that breaks it and follow the blocks a few miners make, about one every few days, while nodes without the rule follow the blocks of most of the hash power. The result is two chains. Without most of the hash power, enforcing a soft fork splits the chain. — **A soft fork needs most of the hash power behind it.** Miners signal readiness first. When nearly all of them are ready, nodes with and without the new rule stay together; when they aren’t, the nodes that enforce it anyway end up on a chain of their own. The Taproot and BIP-110 stories come later in this lesson.

SegWit (2017): a soft fork that needed a push

Segregated Witness (SegWit) moved signature data into a separate part of each transaction and replaced the 1 MB block limit with the 4 million weight-unit limit. Its activation code needed 95% of the blocks in a period to signal, and signaling stayed below that from November 2016 into the summer of 2017.

Two pushes followed. Some users and businesses backed BIP 148, a user-activated soft fork (UASF): from 1 August 2017, their nodes would reject any block that didn’t signal for SegWit. And in July 2017, miners with most of the hash power adopted BIP 91, under which their own nodes rejected non-signaling blocks. SegWit locked in during August and activated at block 481,824 on 24 August 2017, and nodes that hadn’t upgraded stayed on the same chain. How much each push mattered is still argued about.

Bitcoin Cash (2017): a hard fork that became another coin

Some miners and businesses wanted much bigger blocks instead. Their software raised the block size limit to 8 MB from 1 August 2017. It also required the first new block to be larger than 1 MB, so nodes on Bitcoin’s existing rules were certain to reject it. The chains separated after block 478,558, and the new one took the name Bitcoin Cash (BCH). Anyone holding bitcoin before the split held the same amount on both chains. Bitcoin Cash also added replay protection: a change to how transactions are signed, so that a payment on one chain couldn’t be copied onto the other.

Taproot (2021): a soft fork by “Speedy Trial”

Taproot added Schnorr signatures, a newer and more efficient kind of digital signature, and a new output type that reveals less about how coins can be spent. Developers used a short signaling window called Speedy Trial: between late April and mid-August 2021, 90% of the blocks in one 2,016-block period had to signal. That threshold was reached on 12 June 2021. Activation was set for block 709,632, about five months later, to give everyone time to upgrade, and Taproot went live on 14 November 2021.

Who Proposes Changes, and How They Are Adopted

Anyone can propose a change. Serious proposals are written up as a Bitcoin Improvement Proposal (BIP), a numbered design document in a public repository on GitHub. BIP editors assign numbers but “do NOT evaluate whether the proposal is likely to be adopted”. The process document, BIP 3, is explicit: “No formal or informal decision body governs Bitcoin development or decides adoption of BIPs.”

In practice a consensus change goes through these steps:

Discussion in public, on the bitcoin-dev mailing list and the Delving Bitcoin forum, often for years.
Specification and code: the BIP plus an implementation, usually for Bitcoin Core, the software most nodes run.
Review: Bitcoin Core’s guidelines require a consensus change to have “a widely discussed BIP” and “a generally widely perceived technical consensus” before its maintainers merge it.
Release with activation rules: miner signaling with a threshold, a fixed block height (a “flag day”), or both.
Adoption: node operators, businesses and miners each decide whether to run it. Nothing reaches your node until you install it.

No single group can push a change through. In 2017, companies and miners representing more than 80% of the hash power agreed to double the block size by hard fork (SegWit2x). It met opposition from users and developers, and on 8 November 2017 its organizers called it off, saying they had “not built sufficient consensus”. The lesson on what happens when all bitcoins are mined asks what this means for the 21 million cap.

Why the 21 Million Cap Is So Hard to Change

No node counts coins against a 21 million total. The cap follows from the issuance schedule, worked out in the supply lesson. (The code does hold the number 21 million, but only as a sanity check on single amounts.) Every full node checks that a block’s coinbase transaction, the first transaction, which pays the miner, pays out no more than the new coins allowed at that height plus fees. Bitcoin Core rejects a block that pays more with the message “coinbase pays too much”.

Raising the cap would therefore be a hard fork. Nodes on today’s rules would reject the first block with extra coins, so the change would apply only to people who chose to install it. Extra coins would dilute every holder, which gives holders a strong reason to refuse; unless almost everyone switched, the result would be a separate coin, as Bitcoin Cash became.

History shows how firmly the rule is held. On 15 August 2010, a bug let block 74,638 create about 184 billion bitcoins. A corrected version of the software came out within about five hours of the discovery. The fix was itself a soft fork: a new check that made such blocks invalid. Nodes that installed it rejected the block. By the next day, the chain miners rebuilt without it had overtaken the faulty one, and nodes that hadn’t upgraded switched to it too, because it had more work and broke none of their rules.

Three moments in 2010. 1, 15 August 2010: a bug lets block 74,638 create about 184 billion bitcoins, and nodes accept it. 2, within about five hours of the discovery: a fixed version makes such blocks invalid, which is a soft fork, and miners start again from the block before it. 3, the next day: the rebuilt chain has more work than the faulty one, and even nodes without the fix switch to it, because it breaks no rule. The cap is a rule people enforce: it held because nodes and miners ran the fix. — **In 2010 a bug minted about 184 billion bitcoins, and people undid it within a day.** The fix was a new check that made such blocks invalid. Miners rebuilt the chain without the faulty block, and every node ended up following the rebuilt chain.

So the cap is not guaranteed by mathematics. It is a rule people enforce, and removing it would need almost everyone who uses bitcoin to choose software that gives it up.

Today’s Debates, as of November 2026

Data in blocks: a relay-policy dispute

Some transactions carry data unrelated to payments, such as images (often called inscriptions), and node operators disagree about relaying them. One home for such data is an OP_RETURN output: an output is the part of a transaction that says where coins go, and an OP_RETURN output holds data instead and can never be spent. Bitcoin Core 30 (released 10 October 2025) raised its default relay limit for these, datacarriersize, to 100,000 bytes, which “effectively uncaps the limit”.

A June 2025 statement signed by many Bitcoin Core contributors argued that refusing to relay what miners will include anyway only pushes users toward other ways of reaching miners, and stressed that this “is not endorsing or condoning non-financial data usage”. Some operators who disagreed switched to Bitcoin Knots, a long-running derivative of Bitcoin Core with stricter relay filters. Up to this point the dispute was purely about relay policy: both programs followed the same chain.

BIP-110: when the dispute became a consensus change

BIP-110, the “Reduced Data Temporary Softfork”, went further. For about a year, it would have made blocks invalid if they created outputs over 34 bytes (83 for OP_RETURN data) or carried any single data item over 256 bytes, among other limits. Knots 29.3 shipped it in May 2026, switched on only after the operator confirmed it. Blocks 961,632 to 963,647 had to signal for it, and enforcing nodes would reject any block that didn’t: a user-activated soft fork, like BIP 148.

Miners didn’t follow. In the last 2,016-block period before that window, 51 blocks signaled (about 2.5%) against the 55% needed to lock in. Inside the window, no block on the chain Bitcoin Core follows signaled (our count from mempool.space data). On 8 August 2026, the enforcing nodes rejected block 961,632 and split away. In the following weeks their chain got about one block every few days. The BIPs repository marked BIP-110 as Closed; the pull request that did so says it “split to a new chain and stalled”. The Bitcoin Optech newsletter called it an “unsuccessful activation attempt”.

Knots then went a step further, with a hard fork. Version 29.4.1 (2 September 2026) replaces the hash function miners compute for proof of work, SHA-256d (SHA-256 applied twice), with a different one, BLAKE2b, from block 961,640, and applies the BIP-110 rules from that height. Nodes on the existing rules reject those blocks, so Knots 29.4.1 and later follow a separate chain. Its release notes call it “a backward-incompatible protocol change”.

The two sides describe this in opposite terms. Knots’ release notes say that on 8 August “most former miners abandoned Bitcoin en masse” and have been “falsely promoting a new altcoin as ‘Bitcoin’”, calling it “the biggest attack on the Bitcoin network to date”. The BIPs repository and Optech describe an activation that failed. Bitcoin Core, mempool.space and the miners producing around 1,000 EH/s (exahashes, or billion billion guesses, per second) stayed on the SHA-256d chain, which kept the existing rules and is now past block 970,000.

What this shows: enforcing a rule decides which chain your own node follows; it doesn’t make anyone else follow you. If you run Knots, see how to check which chain your node is on and our comparison of Bitcoin Core and Knots.

The rule changes in this lesson, grouped by outcome. Stayed one chain, because most hash power enforced the change: the 2010 overflow fix, SegWit in 2017 and Taproot in 2021, all soft forks. Split off, followed only by those who ran it: Bitcoin Cash in 2017, a hard fork; BIP-110 in 2026, a soft fork few miners followed; and the BLAKE2b proof of work in Knots in 2026, a hard fork. Called off before it activated: SegWit2x in 2017, a hard fork. A change takes hold only when enough node operators and miners run it. — **Every change in this lesson ended one of three ways.** Soft forks that most of the hash power enforced kept one chain. Changes that only some people ran left them on a chain of their own, and SegWit2x was called off before it activated.

Proposals still under discussion

Soft forks under discussion include a “Consensus Cleanup” of old edge cases (BIP 54) and an output type to prepare for quantum computers (BIP 360). Others would add covenants, ways to limit how coins can be spent in future (such as BIP 119 and BIP 347). None is scheduled: Bitcoin Core 32.1 (October 2026) contains no new soft-fork deployment. A BIP number, or the status “Complete”, means a finished document its authors recommend, not a coming change: BIP 3 leaves it “up to the Bitcoin community to evaluate, adopt, ignore, or reject”.

What to Do With This

Check the rules yourself when it matters. Run your own node or connect your wallet to one you trust (why run a Bitcoin node).
Read release notes before you upgrade. If they mention “consensus”, “soft fork”, “hard fork” or “activation”, find out what changes and who supports it first. Verify the download too (how to verify Bitcoin software). On a running node, bitcoin-cli getdeploymentinfo lists the soft-fork deployments your software tracks and their status.
During a split, wait. Coins from before a split exist on both chains, and a payment signed the ordinary way can often be copied onto the other chain. Hold off on sending, receiving or opening Lightning channels (Bitcoin’s layer for fast payments) until you know which chain your node, and the other party’s, follows.

A chain splits in two. Your coins from before the split exist on both chains. You pay someone on one chain. The same signed payment can often be copied onto the other chain, where it spends your coins too and pays the same person. During a split, wait until you know which chain your node, and the other party's, follows. — **During a split, the same coins exist on both chains.** A payment signed the ordinary way can often be copied onto the other chain, where it spends your coins as well. Hold off until you know which chain your node, and the other party’s, follows.

Key Takeaways

Every full node checks every block against its own rules and rejects invalid ones. Nodes don’t vote; miners only order valid transactions and extend valid chains.
Consensus rules decide which blocks are valid; relay policy only decides what a node passes on.
A soft fork tightens the rules (SegWit, Taproot); a hard fork loosens them, and those who don’t switch stay on the old chain (Bitcoin Cash).
Rules change only when people choose new software. The 21 million cap is very hard to change because almost nobody would give it up, not because change is impossible.

Check Your Understanding

1. A large mining pool announces that each of its blocks will create 4 BTC of new coins for it, plus fees, instead of 3.125 BTC. What happens?

Answer

Every full node rejects those blocks, because the coinbase transaction pays more than the allowed 3.125 BTC of new coins plus fees. The pool wastes the electricity spent on them. Even with most of the hash power, it would only produce a chain that today’s nodes ignore.

2. Why do nodes that don’t upgrade keep working after a soft fork but not after a hard fork? And why does a soft fork still need most of the hash power?

Answer

A soft fork only tightens the rules, so blocks valid under the new rules also pass the old ones. A hard fork makes something valid that wasn’t, so old nodes reject the new blocks. And if most miners keep making blocks that break a soft fork’s new rule, upgraded nodes reject them while old nodes accept them, so the chain splits.

3. In August 2026 some nodes enforced BIP-110, yet the chain mempool.space shows carried on without it. Why didn’t those nodes make it activate?

Answer

Nodes don’t vote. Each enforcing node applied BIP-110 to itself and rejected blocks that didn’t signal for it. Almost no mining power signaled, so those nodes split onto a chain that got about one block every few days. Everyone else, including Bitcoin Core users and nearly all the hash power, carried on with the old rules.