Consensus rules

The rulebook is long on specifics: no double spends, no output worth more than its inputs, valid scripts, and a coinbase that claims no more than the subsidy plus fees. Bitcoin Core hardcodes the numbers: 4,000,000 weight units per block, 80,000 signature operations, and a 100 block wait before mined coins can be spent. These rules are why no exchange can credit you a coin the network never created.

How it works

Consensus rules divide into four groups, and almost all of them are deliberately dull.

The first group governs money. A block's reward halves every 210,000 blocks, and the coinbase output may not claim a satoshi more than that subsidy plus the fees of the transactions actually included. Coins created by a block cannot be spent for 100 further blocks. Every other transaction must spend outputs that exist, have not already been spent, and satisfy the script that locked them, with the total going out never exceeding the total coming in.

The second group governs resources, because verification has to stay cheap enough for an ordinary machine. A block may not exceed 4,000,000 weight units or 80,000 signature operation units. The third group governs structure: the coinbase transaction comes first and only once, the merkle root in the header must match the transactions present, and the header hash must sit at or below the target the difficulty rules demand. The fourth group governs time. A block's timestamp must be later than the median of the previous eleven and no more than two hours ahead of a node's own clock, and since BIP113 the same median time is what locktimes are measured against.

Where these rules are written is the awkward part. There is no independent specification: the rules are whatever the deployed code accepts, which for the overwhelming majority of the network means Bitcoin Core's validation logic, quirks and accidents included. That is why a rewrite in another language is treated as a hazard rather than an improvement, and why Bitcoin Knots, the best known variant, keeps Core's consensus behaviour byte for byte and differs only in relay and mining policy.

Changing the list is done in one of two directions. A soft fork removes possibilities, so blocks made under the new rules still look valid to old software: strict DER signature encoding became mandatory at block 363,725 and OP_CHECKLOCKTIMEVERIFY at block 388,381, and neither split the network. A hard fork adds possibilities, which makes new blocks look invalid to anyone who has not upgraded, and produces two chains unless adoption is universal.

Why this matters when you buy bitcoin

Consensus rules are the one part of owning bitcoin that nobody can renegotiate with you afterwards.

They set a hard floor under a small number of risks. Nobody can print coins outside the schedule, spend an output without its key, or delete a payment buried under real work. That floor is narrow, and it is worth being precise about what sits outside it, because that is where people actually lose money: an exchange going insolvent, a phishing site collecting a seed phrase, a support agent freezing an account, a tax bill arriving unbudgeted. None of those involve a rule being broken. They involve trusting something the rules never covered.

The distinction gives you a test for marketing claims. If a service can reverse a confirmed payment, it did not reverse a bitcoin transaction; it adjusted its own ledger, and you were never on chain. If a product advertises settlement faster than blocks allow, it is extending you credit and taking the risk itself, which may be a perfectly good service as long as you know that is what you bought. If a coin claims bitcoin's security with thousands of transactions per second, the resource limits above are the reason bitcoin does not.

What consensus rules are emphatically not is law. The network applies the same checks to every user on earth, while the legal rulebook changes at every border, which is why the country guides on this site exist separately from anything on this page. Validity is decided by nodes. Legality, reporting, and whether an exchange will accept you at all are decided by your jurisdiction, and the two have never once agreed to consult each other.

The 184 billion bitcoin that lasted five hours

On August 15, 2010, a transaction in block 74,638 created two outputs of more than 92 billion bitcoin each.

The bug was arithmetic. The code checked that each output was a sane amount but summed them into a value that overflowed, so a total larger than the entire supply schedule read as a small positive number and passed. Satoshi Nakamoto published version 0.3.10 with a fix within hours, nodes switched to it, and a corrected chain overtook the faulty one 53 blocks later. The incident is catalogued as CVE-2010-5139 and remains the only time bitcoin's supply has ever exceeded its schedule.

Two lessons survive. The 21 million cap is not a law of physics, it is a line of code, and code can be wrong. And the repair worked precisely because nobody was in charge of it: thousands of independent operators each chose to run the corrected software, which is the only mechanism a consensus rule has ever had.

Consensus rules vs mempool policy

Consensus rules decide what is valid; mempool policy decides what a node will pass along. Policy is looser, local, and adjustable per node: a default minimum relay fee of 1 sat/vB, a dust threshold of 546 satoshis on a legacy output, limits on data carrying outputs, and a list of script types considered standard. Break policy and your transaction may simply not propagate. Break a consensus rule and no block containing it can ever exist. Miners regularly include transactions that some nodes would not have relayed, and the resulting blocks are entirely valid, which is why "my wallet says non standard" is a routing problem with workarounds, while "invalid" is final.