Consensus rules
Also called: consensus, validation rules, consensus layer, consensus vs policy.
Consensus rules are the checks every full node applies to decide whether a block or transaction is valid; a block that breaks one is rejected.
Consensus rules are the checks every full node applies to every block and transaction. A block that breaks one is invalid, no matter how much work went into it, and nodes refuse to build on it. Because all nodes apply the same rules independently, they agree on one chain without trusting each other.
Examples of consensus rules
- Every block must meet the proof-of-work target, and the coinbase transaction can't claim more than the block subsidy plus fees, which keeps the supply schedule.
- A transaction may only spend existing, unspent outputs (UTXOs), each once, with a valid script and signatures.
- Block weight must be at most 4,000,000 units (BIP 141).
- Timelocks must have expired (BIP 65, BIP 68, BIP 112).
Consensus vs policy
Nodes also apply policy (or "standardness") rules, such as minimum relay fees, dust limits and replace-by-fee rules, to decide which unconfirmed transactions enter their mempool and get relayed. Policy is local and each operator can change it. A non-standard transaction is still valid if a miner puts it in a block. Consensus rules, by contrast, must match on every node, or the network splits.
Changing consensus rules
Tightening the rules is a soft fork; loosening them is a hard fork. BIP 99 describes both. Deployed changes are listed under deployed BIPs, and BIP 90 shows how old activation logic was later replaced by fixed block heights.
There is no separate written specification: the rules are whatever widely used node software enforces. BIP 50 shows the risk, describing how an undocumented database limit in 2013 implicitly became a consensus rule and split the chain.