# Consensus rules > Source: https://timechain.wiki/wiki/consensus-rules · TimechainWiki, the Bitcoin encyclopedia. (note · technical) > **Consensus rules** are the protocol-level invariants every full node enforces when validating blocks and transactions. They are the **inviolable surface** of Bitcoin — the rules that determine whether a block is valid, whether a transaction is valid, whether a chain is canonical. Examples: the maximum block weight is 4 million weight units; coinbase outputs cannot be spent for 100 blocks; signatures must verify against the correct sighash; the issuance schedule produces exactly 50 BTC of subsidy in the genesis era, halving every 210,000 blocks; the total supply caps at 21 million BTC. A node that enforces a different set of rules is, by definition, on a different consensus — running a software version that disagrees with the network means running an altcoin, not Bitcoin. This is what gives "running a node" its substantive meaning: it is the mechanism by which a holder personally enforces what counts as Bitcoin. The rules can be modified, but only through coordinated network upgrades (soft forks or hard forks; see [Soft forks and hard forks](https://timechain.wiki/wiki/soft-forks-and-hard-forks.md)); even seemingly-trivial changes require broad social agreement among node operators, miners, and exchanges. --- ## Why this note matters Consensus rules are the protocol's authoritative specification — what Bitcoin **is**, as a system. Every other piece of Bitcoin infrastructure (wallets, exchanges, miners, Lightning channels) operates within these rules; deviation is rejection. The rules are also the **mechanism of decentralized governance**. Bitcoin's protocol changes happen only when miners, node operators, and economic users converge on new rules. Each participant's enforcement is independent and personal; there is no centralized authority that can dictate consensus. This is why "running a full node" matters for self-sovereignty — it's how a holder personally enforces what they consider valid. Substantive protocol-evolution debates (covenants, post-quantum migration, block weight) are at root debates about which rules to add, modify, or relax. Understanding the current rule-set is the prerequisite for engaging those debates. --- ## What is a consensus rule A consensus rule is a binary predicate that every node applies during validation: - **Per-block rules:** Apply to a block as a unit. Examples: block weight ≤ 4 MWU; PoW valid; timestamp plausible; Merkle root matches. - **Per-transaction rules:** Apply to each transaction within a block. Examples: each input references an unspent output; signatures verify; scripts execute correctly; no negative output values. - **Cross-block rules:** Apply to the chain as a whole. Examples: block height matches the issuance schedule; coinbase subsidy matches the height-derived amount; cumulative work determines the canonical chain. The full rule-set is large (hundreds of distinct rules); the canonical implementation is Bitcoin Core's source code. Other implementations (btcd, libbitcoin, etc.) are bug-for-bug compatible with Core for consensus-critical code paths. **Rules that are NOT consensus rules:** - Mempool relay policies (which transactions a node will accept and propagate before they're in a block) - Fee estimation - Wallet UX - Block-template construction strategies - Address-format display These are *policy* rather than *consensus* — different nodes can implement them differently without breaking compatibility. A node might refuse to relay a transaction it considers spammy, but if that transaction ends up in a block, the node still validates the block (assuming the transaction is consensus-valid). --- ## The principal block-level rules A non-exhaustive listing of consensus rules at the block level: - **PoW valid.** Double-SHA-256 of header ≤ target encoded in bits field. See [Proof of Work](https://timechain.wiki/wiki/proof-of-work.md). - **Previous-block known.** Previous-block-hash references a block already in the chain. - **Difficulty correct.** The bits field matches what the difficulty-adjustment algorithm prescribes for this height. See [Difficulty adjustment](https://timechain.wiki/wiki/difficulty-adjustment.md). - **Timestamp plausible.** > median of past 11 timestamps; < local time + 2 hours. - **Block weight ≤ 4 million weight units.** See [Blocks and the blockchain](https://timechain.wiki/wiki/blocks-and-the-blockchain.md). - **Merkle root correct.** Recomputed root over included transactions matches header. - **Coinbase subsidy correct.** Coinbase output total ≤ subsidy_at_this_height + sum_of_fees. - **Coinbase has correct height in scriptSig (BIP-34).** Since BIP-34 (block 227,931), the coinbase scriptSig must encode the block height. Prevents duplicate coinbase TXIDs. - **Witness commitment matches** (post-SegWit blocks). A block failing any of these is rejected. The node never extends from it; the chain never includes it. --- ## The principal transaction-level rules A non-exhaustive listing at the transaction level: - **Inputs reference unspent outputs.** Each input's outpoint must match a UTXO in the current chain state. - **No double-spending within the block.** No two inputs can reference the same UTXO. - **Output values are non-negative.** Outputs cannot create negative BTC. - **Sum of inputs ≥ sum of outputs.** Difference is the fee (paid to the miner via the coinbase). - **Signatures verify.** Per-input signatures must verify against the sighash computed from the transaction's serialized form. See [Signature schemes in Bitcoin](https://timechain.wiki/wiki/signature-schemes-in-bitcoin.md). - **Scripts execute correctly.** Locking and unlocking scripts must run to completion and end with a truthy stack top. See [Bitcoin Script and opcodes](https://timechain.wiki/wiki/bitcoin-script-and-opcodes.md). - **Standard transaction format (mempool-relay only).** Non-standard transactions are relay-rejected but consensus-valid; miners can include them if they choose. - **Locktime satisfied.** Transactions with nonzero locktime are only valid after the specified height or timestamp. - **Sequence numbers consistent.** Relative locktimes (BIP-68) and replace-by-fee signals (BIP-125) require specific sequence-number behavior. Plus many edge-case rules: maximum signature size, maximum input/output counts (per protocol limits), maximum script size, maximum number of OP_CHECKSIG operations per block, etc. --- ## The cross-block / chain rules - **Issuance schedule.** Block subsidy = 50 BTC initially, halving every 210,000 blocks. The asymptotic total ≈ 21 million BTC. See [Bitcoin fixed supply and issuance schedule](https://timechain.wiki/wiki/bitcoin-fixed-supply-and-issuance-schedule.md) and [The halving - Mechanism](https://timechain.wiki/wiki/the-halving-mechanism.md). - **100-block coinbase maturity.** Outputs from coinbase transactions cannot be spent until 100 blocks have been built on top. - **Cumulative work determines canonical chain.** The chain with greatest cumulative work is the canonical one (longest-chain rule, more precisely most-work-rule). See [Chain reorganizations](https://timechain.wiki/wiki/chain-reorganizations.md). - **Soft-fork-activated rules.** Various rules added by soft forks (BIP-34 height-in-coinbase, BIP-65 CLTV, BIP-66 strict DER signatures, BIP-68 CSV, BIP-141 SegWit, BIP-341 Taproot, etc.). Each rule has an activation height after which it becomes consensus-enforced. --- ## Running a node as consensus enforcement When a node is running, it: 1. **Receives** block and transaction announcements from peers 2. **Validates** each against the consensus rules 3. **Accepts** valid blocks (extending the chain) and valid transactions (entering the mempool) 4. **Rejects and refuses to propagate** anything that fails If a majority of miners produce a block that violates a consensus rule the node enforces, the node **rejects the block**. The miner's PoW is wasted from the node's perspective; the block doesn't exist. If a sufficient minority of nodes rejects the same way, a chain split emerges — the network has effectively forked into two consensus camps. This is the substantive meaning of "running a node": every node operator personally enforces their interpretation of valid Bitcoin. If the node operator runs a software version that omits certain rules (e.g., a hypothetical "Bitcoin Cash"-compatible build that allows >1 MB blocks), they're enforcing a different consensus. **The "don't trust, verify" principle.** Self-sovereign Bitcoin holders run their own nodes precisely to enforce consensus locally rather than trusting a third party's enforcement. This is why running a full node is treated as a serious operational practice in [Practical self-custody and sovereignty](https://timechain.wiki/wiki/practical-self-custody-and-sovereignty.md). **SPV light clients** trust the longest chain but do not enforce all consensus rules — they cannot, because they don't have the data. This is the trade-off in light-client architecture; see [Full nodes vs pruned vs SPV](https://timechain.wiki/wiki/full-nodes-vs-pruned-vs-spv.md). --- ## How rules change Consensus rules are not immutable, but changes are exceptional. The standard mechanisms: - **Soft fork.** A tightening of existing rules — what was valid before becomes invalid; new behaviors require explicit support. Old nodes still validate new blocks (they're a strict subset of what old rules allowed). Requires miner adoption and node-operator adoption; can activate via various coordination mechanisms (BIP-9 versionbits, BIP-8 with timeout, UASF-style user activation). - **Hard fork.** A loosening or change to existing rules — old nodes will reject new blocks. Requires *all* node operators to upgrade or the chain splits. Bitcoin has had effectively zero coordinated hard forks; the Block Size Wars (see [Block Size Wars - History](https://timechain.wiki/wiki/block-size-wars-history.md)) demonstrated the political-philosophical difficulty. The substantive engagement on how upgrades happen lives in [Soft forks and hard forks](https://timechain.wiki/wiki/soft-forks-and-hard-forks.md). The cultural-political question of why soft forks dominate Bitcoin's upgrade history is engaged in [Block Size Wars - History](https://timechain.wiki/wiki/block-size-wars-history.md) and [Protocol-evolution constraints](https://timechain.wiki/wiki/protocol-evolution-constraints.md) (Criticisms). **Recent soft-fork additions to consensus rules:** - **2017 SegWit** — new consensus rule: 4 MWU weight limit; witness data segregated. - **2021 Taproot** — new consensus rules: Schnorr signatures (BIP-340), Taproot output type (BIP-341), Tapscript validation (BIP-342). - **No additions since 2021.** OP_CAT re-enablement, BIP-300 Drivechains, and post-quantum signatures are all proposed but not yet activated. The cadence (a few soft forks per decade, each adding modest new capabilities) is the empirical pattern. --- ## Tradeoffs and design choices **Why the consensus rules are deliberately conservative.** Adding new rules can introduce bugs; removing rules can break existing assumptions; modifying rules can split the chain. The "ossification" mindset — that Bitcoin's protocol surface should be small, stable, and changed only with overwhelming necessity — is the dominant cultural position. The cost is that legitimate improvements (covenants, performance optimizations, privacy enhancements) face high political barriers. **The "consensus is the smallest valid set of rules" framing.** A useful perspective: consensus is the *intersection* of what every participant considers valid. Adding rules narrows the intersection (a tightening, soft fork). Removing rules expands it (a loosening, hard fork). Bitcoin's strong soft-fork preference means consensus only shrinks (in the rule sense) or stays constant; it rarely expands. **The "consensus surface" as protocol attack surface.** Every consensus rule is a potential bug. The fewer rules, the smaller the surface. The implicit-rules pattern (e.g., "Bitcoin Script's behavior is whatever Bitcoin Core does") is criticized for its fragility — a Bitcoin Core bug becomes a consensus bug. The mitigation is bug-for-bug compatibility across implementations. **Mempool policy vs consensus.** Some rules sit ambiguously between mempool-relay policy (loose, varies between nodes) and consensus (strict, enforced by all). The line is occasionally blurry — e.g., the "standard transaction" rules are mempool-only but most miners only build from standard transactions, so the effective consensus is tighter than the formal one. **The political-philosophical character of consensus.** Bitcoin's consensus rules embody specific value choices: hard supply cap (vs adjustable), 10-minute block time (vs faster), PoW (vs PoS), engineering conservatism (vs feature richness). Each choice is defensible; each is contested by some alternative blockchain. The choices are what make Bitcoin specifically *Bitcoin* rather than some other system. **For substantive engagement** on how protocol changes happen, see [Soft forks and hard forks](https://timechain.wiki/wiki/soft-forks-and-hard-forks.md). On the political-philosophical constraints around upgrades, see [Protocol-evolution constraints](https://timechain.wiki/wiki/protocol-evolution-constraints.md) (Criticisms section) and [Block Size Wars - History](https://timechain.wiki/wiki/block-size-wars-history.md) (History section). On the specific contemporary debates around new consensus rules, see [OP_CAT and the covenants programmability debate](https://timechain.wiki/wiki/op-cat-and-the-covenants-programmability-debate.md) and [BIP-300 and the Drivechains debate](https://timechain.wiki/wiki/bip-300-and-the-drivechains-debate.md) (Controversies section). --- ## Open questions for further development - How will the consensus-rule set evolve over decade horizons? The post-Taproot quiet has lasted longer than any prior gap; debate is reopening around 2025-2026. - Is there an upper limit to "consensus surface" complexity that Bitcoin should respect? Some developers argue the current rule-set is near-optimal; others see meaningful additions worth making. - How do consensus rules interact with post-quantum migration? Will new signature schemes require new validation rules, or can they be layered onto existing infrastructure? - What's the right operational practice for node operators around emergency rule fixes (CVE-class bugs)? The post-2018 record is good but the test under pressure has been limited. --- ## Canonical sources for this note **Bitcoin engineering references** - *Mastering Bitcoin*, Andreas Antonopoulos (chapter 10: "Mining and Consensus") — canonical engineering treatment. See [Mastering Bitcoin - Andreas Antonopoulos](https://timechain.wiki/wiki/mastering-bitcoin-andreas-antonopoulos.md). - Bitcoin Core source code — `consensus/consensus.h`, `validation.cpp`, and adjacent files are the canonical implementation. - *Programming Bitcoin*, Jimmy Song (chapters 6-9) — working-programmer treatment of validation. **Bitcoin Improvement Proposals** - The full BIPs list at github.com/bitcoin/bips — every BIP marked "Final" represents one or more consensus rules. - Notable: BIP-34 (height in coinbase); BIP-66 (strict DER); BIP-65 (CLTV); BIP-68 (CSV); BIP-141 (SegWit); BIP-340/341/342 (Taproot). --- ## Related notes - [Proof of Work](https://timechain.wiki/wiki/proof-of-work.md) — One specific consensus rule among many; this note frames the full ruleset. - [Difficulty adjustment](https://timechain.wiki/wiki/difficulty-adjustment.md) — The retarget formula is itself a consensus rule. - [Blocks and the blockchain](https://timechain.wiki/wiki/blocks-and-the-blockchain.md) — Block-level rules apply at block validation. - [UTXO model and Bitcoin transactions](https://timechain.wiki/wiki/utxo-model-and-bitcoin-transactions.md) — Transaction-level rules apply at transaction validation. - [Signature schemes in Bitcoin](https://timechain.wiki/wiki/signature-schemes-in-bitcoin.md) — Signature verification is one of the consensus rules. - [Bitcoin Script and opcodes](https://timechain.wiki/wiki/bitcoin-script-and-opcodes.md) — Script execution is one of the consensus rules. - [Chain reorganizations](https://timechain.wiki/wiki/chain-reorganizations.md) — Cumulative-work rule determines canonical chain. - [Bitcoin fixed supply and issuance schedule](https://timechain.wiki/wiki/bitcoin-fixed-supply-and-issuance-schedule.md) — Issuance is a cross-block consensus rule. - [The halving - Mechanism](https://timechain.wiki/wiki/the-halving-mechanism.md) — Subsidy halving is a cross-block consensus rule. - [Full nodes vs pruned vs SPV](https://timechain.wiki/wiki/full-nodes-vs-pruned-vs-spv.md) — Full nodes enforce all rules; pruned nodes enforce all rules from a checkpoint; SPV nodes enforce a strict subset. - [Soft forks and hard forks](https://timechain.wiki/wiki/soft-forks-and-hard-forks.md) — How consensus rules change. - [Protocol-evolution constraints](https://timechain.wiki/wiki/protocol-evolution-constraints.md) — Substantive engagement on why protocol changes are politically difficult. Criticisms section. - [Block Size Wars - History](https://timechain.wiki/wiki/block-size-wars-history.md) — Historical example of consensus-rule dispute. History section. - [OP_CAT and the covenants programmability debate](https://timechain.wiki/wiki/op-cat-and-the-covenants-programmability-debate.md) — Contemporary consensus-rule-extension debate. Controversies section. - [BIP-300 and the Drivechains debate](https://timechain.wiki/wiki/bip-300-and-the-drivechains-debate.md) — Contemporary consensus-rule-extension debate. Controversies section.