This appendix catalogs the consensus rules that constitute the validation predicate V(C, B) of Definition 13.18, organized by the four phases of Definition 13.19. Only consensus rules appear: violating any rule below makes a block invalid for every node. Relay-policy rules (standardness, minimum fee rates, the default OP_RETURN limit) are deliberately excluded; the distinction is developed in Section 16.1.
Two cautions. First, heights and flags describe Bitcoin mainnet. Second, this
catalog is a faithful description, not a normative specification—per the
specification problem of Section 33.9, the rules are ultimately defined by the
behavior of deployed implementations (Bitcoin Core's
src/validation.cpp and src/consensus/ are the
de facto reference; declarative restatements such as the Hornet DSL are cited
in Appendix B).
D.1 Phase 1 — Header Validation
| Rule | Requirement | Active since |
|---|---|---|
| Connection | The previous-block hash refers to a known, valid header | Genesis |
| Proof of work | The block hash, as a 256-bit integer, does not exceed the target encoded in the bits field | Genesis |
| Difficulty | The bits field equals the value prescribed by the difficulty adjustment algorithm for this height (Section 14.4) | Genesis |
| Timestamp, lower bound | Strictly greater than the median of the previous 11 block timestamps (MTP) | Genesis |
| Timestamp, upper bound | At most 2 hours ahead of network-adjusted time | Genesis |
| Version minimum | Version ≥ 2 (BIP-34), ≥ 3 (BIP-66), ≥ 4 (BIP-65) | Heights 227,931 / 363,725 / 388,381 |
D.2 Phase 2 — Transaction Validation (Context-Free)
Applied to every transaction in the block, with no reference to chain state.
| Rule | Requirement | Active since |
|---|---|---|
| Non-empty | At least one input and at least one output | Genesis |
| Size bound | Serialized size without witness data, times 4, does not exceed 4,000,000 weight units | Genesis (in weight form since SegWit) |
| Output range | Each output value in [0, 21,000,000 × 10⁸] satoshis; the running sum stays in range | Genesis |
| No duplicate inputs | No two inputs of the transaction reference the same outpoint | Genesis |
| Coinbase script size | For a coinbase: scriptSig length between 2 and 100 bytes | Genesis |
| No null prevouts | For a non-coinbase: no input references the null (coinbase-style) outpoint | Genesis |
D.3 Phase 3 — Block-Structure Validation
| Rule | Requirement | Active since |
|---|---|---|
| Merkle root | The header's Merkle root equals the root computed from the transaction list (Chapter 12) | Genesis |
| Mutation check | The transaction list does not exhibit the duplicate-subtree malleation of CVE-2012-2459 | Detection since Bitcoin Core 0.6.2 (2012) |
| Coinbase position | The first transaction is a coinbase and no other transaction is | Genesis |
| Block weight | Total weight at most 4,000,000 WU (Definition 13.9) | Genesis (1 MB size form); weight form since SegWit, height 481,824 |
| Signature operations | Total signature-operation cost at most 80,000 | Genesis (limit restated in cost form at SegWit) |
| Per-transaction checks | Every transaction passes Phase 2 | — |
D.4 Phase 4 — Contextual Validation and Connection
State-dependent rules, evaluated against the chain state C.
| Rule | Requirement | Active since |
|---|---|---|
| Finality | Every transaction is final: locktime satisfied relative to block height or median time past | Genesis; MTP comparison since BIP-113, height 419,328 |
| Coinbase height | The coinbase scriptSig begins with the block height (BIP-34) | Height 227,931 |
| Witness commitment | If any transaction has witness data, the coinbase commits to the witness Merkle root (BIP-141; Section 12.6) | Height 481,824 |
| No txid overwrite | No transaction's txid duplicates that of an earlier transaction with unspent outputs (BIP-30; made unreachable for new blocks by BIP-34) | March 2012 |
| Inputs exist | Every input references an existing unspent output in the UTXO set | Genesis |
| Coinbase maturity | Spent coinbase outputs have at least 100 confirmations | Genesis |
| Value conservation | For each transaction, total input value ≥ total output value; the difference is the fee | Genesis |
| Subsidy bound | Coinbase output total at most subsidy(height) + total fees (Remark 10.3, Definition 15.2) | Genesis |
| Sequence locks | Relative lock-times encoded in sequence numbers are satisfied (BIP-68) | Height 419,328 |
| Script execution | Every input's script verifies under the flags active at this height (Chapter 11) | See D.5 |
D.5 Height-Gated Script Verification Flags
The script-execution rule of Phase 4 is itself height-parameterized: each soft fork added verification flags that apply from its activation height.
| Flag / rules | Soft fork | Mainnet activation height |
|---|---|---|
| P2SH evaluation | BIP-16 | 173,805 |
| Strict DER signatures | BIP-66 | 363,725 |
| OP_CHECKLOCKTIMEVERIFY | BIP-65 | 388,381 |
| OP_CHECKSEQUENCEVERIFY | BIP-112 (with 68/113) | 419,328 |
| Witness program evaluation (v0) | BIP-141/143 | 481,824 |
| Taproot and Tapscript (v1) | BIP-341/342 | 709,632 |
Together, D.1–D.5 are the concrete content of Remark 13.5: the valid set R(C) contracted at each of these heights, and every contraction was a soft fork in the sense of Definition 26.5.
D.6 Standardness (Policy) Rules
For contrast with D.1–D.5, this table lists the major policy rules—Bitcoin Core's defaults for what it will relay and admit to its mempool (Definition 16.2). Three caveats distinguish every row from the consensus rules above: policy is per-node (each operator may configure it), version-dependent (defaults change between releases without any fork), and not a security boundary—a transaction violating every rule below is still consensus-valid, and miners can and do include such transactions when submitted to them directly.
| Rule | Default requirement | Purpose |
|---|---|---|
| Standard output types | Outputs match known templates (P2PKH, P2SH, P2WPKH, P2WSH, P2TR, bare multisig up to 3 keys, OP_RETURN data) | Predictable validation; upgrade protection |
| Dust threshold | No output worth less than the cost of spending it (≈546 sats P2PKH, ≈294 sats P2WPKH at default rates; Remark 16.2) | UTXO-set hygiene |
| Minimum relay fee | At least 1 sat/vB | DoS protection |
| Maximum standard weight | Transaction weight at most 400,000 WU (a tenth of a block) | Keep blocks composable; DoS protection |
| Minimum size | At least 65 non-witness bytes | Forbid 64-byte transactions (CVE-2017-12842; Section 35.3) |
| Data carrier | OP_RETURN payload within the configured limit (historically 80 bytes by default; Section 11.9) | Network hygiene |
| Low-S signatures | ECDSA s ≤ n/2 (Section 7.8) | Malleability hygiene |
| Clean stack | Script execution leaves exactly one stack element | Malleability hygiene; upgrade protection |
| Discouraged upgrade hooks | No spends of undefined witness versions or use of OP_SUCCESS opcodes (Section 16.8) | Soft-fork protection |
| Replacement signaling | Conflicting-transaction replacement per BIP-125 rules (fee must increase) | Mempool coherence |
| Package limits | Bounded counts and sizes of unconfirmed ancestors and descendants | DoS protection |
Because these are defaults rather than rules of the system, they drift: the data-carrier limit, replacement signaling, and dust rates have all changed across Bitcoin Core releases, and other implementations choose differently. That drift is harmless precisely because policy violations cannot split the chain—which is the entire content of the policy/consensus distinction of Section 16.1.