Timechain Wiki

Consensus rules

11 min read

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); 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.
  • 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.
  • Timestamp plausible. > median of past 11 timestamps; < local time + 2 hours.
  • Block weight ≤ 4 million weight units. See Blocks and the blockchain.
  • 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.
  • Scripts execute correctly. Locking and unlocking scripts must run to completion and end with a truthy stack top. See Bitcoin Script and opcodes.
  • 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 and The halving - Mechanism.
  • 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.
  • 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.

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.

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) demonstrated the political-philosophical difficulty.

The substantive engagement on how upgrades happen lives in Soft forks and hard forks. The cultural-political question of why soft forks dominate Bitcoin’s upgrade history is engaged in Block Size Wars - History and Protocol-evolution constraints (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. On the political-philosophical constraints around upgrades, see Protocol-evolution constraints (Criticisms section) and Block Size Wars - History (History section). On the specific contemporary debates around new consensus rules, see OP_CAT and the covenants programmability debate and BIP-300 and the Drivechains debate (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.
  • 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).

Graph View

Backlinks