Any claim about Bitcoin that starts with "that can't be changed" should survive a simple follow-up question: where exactly in the code does it say that, and why can't it be changed? In this post, we answer that for the most important consensus rules, the rules that determine whether a Bitcoin block is valid at all. We went straight to the official Bitcoin Core source code (version 31.1) ourselves and show you the exact spots.
What a "Consensus Rule" Actually Means
A consensus rule is a rule that EVERY full Bitcoin node on the network checks independently, and checks in exactly the same way. If a block doesn't follow all of these rules, every correctly running node automatically rejects it, no matter how much computing power went into it or who created it. That's what sets consensus rules apart from the mere "house rules" of individual node operators (more on that in Part 4 of this series): breaking a consensus rule doesn't mean "my node doesn't like that," it means "the entire network rejects this."
Why Not Even the Most Powerful Miners Can Override These Rules
This raises an obvious question, one closely related to the concept of a 51% attack: a single large mining company invests millions in hardware and electricity. Why shouldn't it simply ignore a rule it doesn't like, given how much computing power it has? The answer lies in a deliberate division of labor that's been built into Bitcoin's design from the very start: computing power only decides WHO gets to propose a new block first, not WHETHER that block is valid at all. That second question is answered exclusively by the software running on every single node, even the smallest one, completely independent of any computing power.
So if a miner tried to, say, assign themselves more than the allowed 50 (now far fewer) bitcoin block reward, or tried to skip one of the checks described below, every single node worldwide checks that block against the exact same line of code and automatically rejects it if it breaks a rule, completely independent of how much computing power was spent finding it. In that case, the miner would have sunk enormous costs (electricity, hardware wear) into a block that no one in the end recognizes as valid, and that earns them not a single bitcoin. This exact combination (computing power only decides the order, software rules decide validity) is the real reason rule violations never pay off for anyone, no matter how much market power they might appear to have at first glance.
When "Alternative Software" Alone Wasn't Enough: Four Failed Attempts
Just how serious Bitcoin is about requiring genuine, voluntary majority approval for any rule change is shown by four real examples from Bitcoin's history, each with its own goal:
- Bitcoin XT (2015, initiated by Mike Hearn and later joined by Gavin Andresen) wanted to raise the maximum block size from 1 MB to 8 MB via BIP 101, with a planned doubling every two years after that.
- Bitcoin Classic (2016) wanted to solve the same bottleneck more moderately: a one-time increase to 2 MB instead of XT's much more aggressive growth path.
- Bitcoin Unlimited (2016) wanted to abolish the fixed block size cap entirely and instead let each miner or node configure their own limit ("emergent consensus").
- Bitcoin Satoshi Vision (BSV, November 2018) wanted massively larger blocks (128 MB initially, much more later) and wanted to restore original, early-disabled script opcodes.
Each of these four variants was fully programmed, working code. And yet, in none of the first three cases did the intended hard fork actually happen: there simply wasn't broad enough, simultaneous approval from miners, node operators, and economically relevant users. Without that, even finished, functioning code stays powerless. BSV is a bit different: it did successfully split off in November 2018, but not from Bitcoin itself, rather from Bitcoin Cash (which had itself split from Bitcoin back in 2017). That, too, ultimately makes the same point: a hard fork creates, at best, a new, separate coin that the market treats as something else. It doesn't change Bitcoin's own consensus rules. A striking counterexample to the common assumption that anyone with enough developer resources could unilaterally change Bitcoin's rules.
How a Soft Fork Actually Gets Activated: Miner Signaling
A good example of a soft fork is the pair of timelock opcodes OP_CHECKLOCKTIMEVERIFY (CLTV, activated on 2015-12-14 at block 388,381) and OP_CHECKSEQUENCEVERIFY (CSV, activated on 2016-07-04 at block 419,328), which let an amount be spent only after a certain point in time or after a certain waiting period, an important foundation for, among other things, Lightning payment channels. Both were added later via a soft fork, without older nodes ever having to understand the new rule: to them, the new script opcodes simply looked like a harmless no-op. But how does the network actually agree on the point in time a new rule like this takes effect? For that, Bitcoin developed its own signaling mechanism via the block version field, which itself has been refined twice over time. CLTV activated via the older mechanism (BIP 34, which introduced this approach for the first time and has, ever since, also enforced the rule that every coinbase transaction must prefix the current block height, checked in src/validation.cpp), which simply treated the version number as a plain integer and required approval from 75%, later 95%, of the last 1,000 blocks. CSV, in turn, was the very first rule activated via the newer, refined mechanism:
The refined mechanism in use since 2016 (BIP 9) turns this into a 29-bit bitfield: each individual bit can represent its own, independent rule change, so up to 29 different proposals can signal simultaneously and independently instead of blocking each other. Every proposal runs through a clearly defined state machine: it starts as DEFINED (defined but not yet active), switches to STARTED at a set point in time (miners can now actively signal approval), reaches LOCKED_IN once it gets at least 95% approval within a 2,016-block window (activation is now technically decided but not yet in effect), and finally becomes ACTIVE. If the 95% threshold isn't reached within a set deadline, the proposal expires as FAILED, without anyone being forced to adopt it. This staged process with a built-in deadline is the actual technical mechanism behind how Bitcoin can evolve in a controlled way at all, without any single entity ever having to announce "now is the time."
The 21 Million Cap: Not a Promise, But Math
The most famous Bitcoin number of all is the fixed cap of 21 million bitcoin. How is that actually enforced in the code? Through two independent mechanisms, which is notable in itself:
First, through the emission formula itself. The function GetBlockSubsidy in src/validation.cpp starts with a 50 bitcoin reward per block and halves that amount every 210,000 blocks (roughly every four years, at an average of 10 minutes per block). Technically, this happens via a so-called bit-shift operation (nSubsidy >>= halvings), a computational trick that halves numbers almost instantly.
You can verify the 21 million cap yourself with simple high-school math. Every one of the 210,000 blocks in a halving period pays the same amount: the first period pays a total of 210,000 × 50 = 10,500,000 bitcoin, the second only half of that, 210,000 × 25 = 5,250,000 bitcoin, and so on. Add up all the periods of this geometric series and you get 210,000 × 50 × (1 + 1/2 + 1/4 + 1/8 + …) = 210,000 × 50 × 2 = 21,000,000 bitcoin: exactly the well-known cap. In the code itself, though, there's no explicit limit value behind this, just plain integer arithmetic: nSubsidy starts at 5,000,000,000 satoshis (50 bitcoin), a number that needs 33 bits in binary, which is why it's already exactly zero after the 33rd halving (at block height 33 × 210,000 = 6,930,000, around the year 2140). The 64-halving limit visible in the code (if (halvings >= 64) return 0;) isn't a further milestone, it's only a safety guard against a technically undefined bit-shift by 64 or more positions: the actual zero point is already a good 30 halvings earlier. So emission doesn't end "sometime, roughly," it ends at a mathematically exact, precisely determined point.
Second, and this is often overlooked, the 21 million cap also exists as its own, separately checked constant in the code: MAX_MONEY = 21000000 * COIN in src/consensus/amount.h. Every single transaction on the entire network is explicitly checked against this limit: no output may contain more, no sum may exceed it. So the cap isn't just a mathematical consequence of the halving formula, it's an additional, hard-coded safety limit. Two independent checks for the same rule: anyone wanting to change it would have to touch both at once, and in a place every single node in the world would notice immediately.
Why a Block Never Comes Faster Than Every Ten Minutes
The time between two blocks is meant to average ten minutes, not because it couldn't technically be faster, but because it trades off security against time (more on that in Part 3, on the scripting rules). To keep this stable despite fluctuating global computing power (which has changed by millions of times over the years), the "difficulty" (how many attempts are needed on average to find a valid block) adjusts automatically.
The function GetNextWorkRequired in src/pow.cpp doesn't do this for every single block, though, only every 2,016 blocks (which, at ten minutes per block, works out to almost exactly two weeks). In between, the difficulty stays exactly the same. To calculate the adjustment, the code compares the time actually needed for the last 2,016 blocks against the target of two weeks, and scales the difficulty proportionally. A clever safeguard prevents manipulation: before the calculation, the measured time span is artificially capped at a minimum of one quarter and a maximum of four times the target time. So even if a single miner tried to cheat with a false timestamp, the difficulty could shift by at most a factor of four up or down per adjustment, never more.
"The Longest Chain Wins": Almost Right, But Not Quite
You've probably heard this phrase before, and it's one of the most commonly, slightly imprecisely, repeated statements about Bitcoin. In reality, the chain that wins isn't necessarily the one with the most blocks, but the one with the greatest total proven computational work (tracked in the code as nChainWork in src/chain.h, compared via CBlockIndexWorkComparator in src/node/blockstorage.h). In practice, that's almost always the same thing, since difficulty adjusts precisely so that, on average, every block costs roughly the same amount of work. But in a very short-term, extreme difficulty swing, a chain with fewer but "heavier" blocks could theoretically beat a longer but "lighter" one. The whitepaper itself, incidentally, already correctly talks about the chain with the greatest proven computational effort. The simplification "longest chain" only crept into general communication later.
Where Rules Stop Being Hard Rules: Consensus vs. Node Policy
A detail from the code that can resolve a lot of misunderstandings in discussions about Bitcoin: Bitcoin Core explicitly distinguishes two layers of rules in the code. MANDATORY_SCRIPT_VERIFY_FLAGS (in src/policy/policy.h) are rules whose violation makes a block invalid, the absolute minimum. STANDARD_SCRIPT_VERIFY_FLAGS are additional, stricter rules a node applies by default to decide what it accepts into its own waiting area (the mempool) or would mine itself; violating them doesn't make an already-mined block invalid, though.
That explains why different node software, or differently configured nodes, can quite happily apply slightly different rules to their own mempool without the network splitting into two chains as a result: disagreement at the policy level is normal and harmless, disagreement at the consensus level would be a hard fork. Part 4 of this series looks at exactly this policy level in detail.
A Technical Detail With Real History: Why Certain Checks Exist
Two small but instructive spots in the code show that Bitcoin's rules weren't designed on a whiteboard from scratch, but partly grew out of real incidents the network actually survived: the check that no transaction output may have a negative value directly references, right in the source code, a real, long-since-fixed vulnerability from Bitcoin's early days (publicly documented as CVE-2010-5139, checked in src/consensus/tx_check.cpp), a bug that would theoretically have allowed amounts to be manipulated via an integer overflow. Likewise, the check for duplicate inputs within the same transaction references a later, also long-since-closed bug (CVE-2018-17144). That's ultimately the best proof of the idea this series opened with: Bitcoin's security isn't based on the assumption that nothing can ever go wrong, it's based on a process where vulnerabilities get publicly documented, fixed, and left visible in the code forever as a reminder.
One More Thing: Freshly Minted Money Needs Time to Mature
One last small but important detail that's often misunderstood: this waiting period applies exclusively to the block reward itself, the bitcoin a miner is directly awarded as payment for successfully mining a new block (the so-called coinbase transaction). Ordinary bitcoin that you receive the normal way, via a transfer from someone else, isn't affected by this. You can typically send those on again right after the first confirmation, so on average after about 10 minutes.
Only the block reward itself has to mature for COINBASE_MATURITY = 100 further blocks before the miner is allowed to spend it, which, at an average of 10 minutes per block, works out to roughly 1,000 minutes, or a bit more than 16.5 hours. The reason for this one special case: if competing chains briefly appear and a different one than the miner's own ends up winning, the miner loses their entire block, including their own block reward, with no compensation. An ordinary, already-confirmed transfer to you as a recipient doesn't carry that same risk: if your miner's chain lost the race, your transaction would normally just get reconfirmed in the next, now-leading block, and the money itself would be preserved. The block reward, by contrast, has no "next block" to rescue it, it exists only because that one specific block won. The 100-block waiting period keeps a miner from immediately spending a reward that could retroactively turn out to have never existed.
When Theory Briefly Met Practice: The 2013 Chain Split
How seriously Bitcoin takes these rules is shown by a real, well-documented event from its early days: in March 2013, it turned out that two software versions in simultaneous circulation at the time (0.7 and the recently released 0.8) evaluated a particular, otherwise fully rule-compliant block differently, due to a technical quirk in the database each was using. The newer version accepted it, the older one rejected it. For a good hour, two parallel, internally consistent versions of the Bitcoin blockchain genuinely existed at the same time.
The situation wasn't resolved through any central intervention (there isn't one to make, after all), but through exactly the dynamic this series describes: the major mining pools and developers communicated publicly, agreed to temporarily roll back to the older, more compatible software version, and the network discarded the short secondary chain as soon as the majority of computing power was working on the original, longer chain again. No one lost any already-confirmed, older payments in the process, only the handful of transactions from the short secondary chain had to be reconfirmed. The incident led to stricter testing procedures for new releases afterward, and remains a textbook example to this day of how the network can respond robustly to genuine disagreements between software versions, entirely without any central authority.
Conclusion: Rules No One Can Quietly Move
The 21 million cap, the difficulty adjustment, the chain-selection rule: none of this is a marketing promise, it's concrete lines, viewable by anyone, in a public codebase that thousands of independent nodes worldwide check at the same time. Changing it wouldn't just mean editing the code, it would mean the overwhelming majority of node operators and miners worldwide voluntarily choosing to adopt that exact changed version, against every economic incentive pointing the other way.
Next up, Part 3: From Scripts to Taproot, how a Bitcoin transaction is technically "locked" and "unlocked" again, and how the Taproot upgrade introduced in 2021 made Bitcoin both more private and more efficient.
