bitcoin-consensus

v2026.09.24

Bitcoin consensus rules: block validation, transaction validation, soft-fork activation mechanics (BIP9, BIP8, Speedy Trial), nLockTime / nSequence semantics, mempool policy vs consensus distinction. USE WHEN: discussing what makes a tx/block valid, soft-fork deployment, reorg handling, "is this consensus-valid".

GitHub
Install command
npx skhub add claude-dev-suite/bitcoin-consensus
Markdown
SKILL.md

Bitcoin Consensus

Bitcoin consensus = the set of rules every full node enforces to decide if a block / transaction is valid for inclusion in the chain. Distinct from mempool policy (which is a node-local default for what tx to accept and relay).

Block validation (high-level)

  1. Decoded block header is well-formed (80 bytes).
  2. prev_block exists and points to current best chain (or triggers reorg).
  3. Proof-of-work: SHA256d(header) ≤ target where target is derived from the difficulty re-target window (every 2016 blocks).
  4. Block timestamp > median of last 11 blocks (MTP) and ≤ network-adjusted time + 2 hours.
  5. Coinbase is the first tx, has 1 input with null prevout, scriptSig length in [2,100], and includes BIP34 height in scriptSig (active since block 227,931).
  6. Witness commitment in coinbase's OP_RETURN matches the merkle root of wtxids (BIP141).
  7. Merkle root of txids matches header.
  8. All transactions are individually consensus-valid (see below).
  9. Total fees + subsidy ≥ coinbase value.

Transaction validation

  1. Non-empty vin and vout.
  2. No negative or > MAX_MONEY (21M × 1e8 sats) output amount.
  3. No duplicate inputs (within the tx).
  4. Coinbase input present iff this is the coinbase tx.
  5. For each non-coinbase input: prevout exists in UTXO set and is unspent.
  6. Script execution succeeds for scriptSig + scriptPubKey and (post-segwit) the witness stack.
  7. Sum(inputs) ≥ Sum(outputs).
  8. nLockTime / nSequence rules (BIP65, BIP112) — see proposals/.

Soft-fork activation

MechanismFirst usedNote
BIP9 (versionbits)CSV (BIP68/112/113), SegWit (initially)bit signaled in version field; needs 95% of last 2016
BIP8 (LOT=true/false)proposed for Taproot, debatedBIP9 + lockinontimeout option
Speedy Trial (BIP9 short window)Taproot deployment 20213-month signaling, 6-month grace
Modified BIP9 (BIP8-style mandatory signaling)BIP110 “reduced_data”, 2026 — failedbit 4, threshold 1109/2016 (55%), NO_TIMEOUT

Thresholds are per deployment, not a BIP9 constant: BIP9 specifies 1916/2016 (95%) on mainnet and SegWit used it; Taproot's Speedy Trial used 1815/2016 (90%), which is still Core's mainnet default.

BIP110 is the most recent mainnet attempt. Its mandatory-signaling window opened at block 961,632 (2026-08-08) and mainnet did not signal bit 4, so enforcing nodes split onto a branch that mined two blocks in ~8 hours; the BIPs repo moved BIP110 to Closed on 2026-08-10. No BIP110 rule is in force as of September 2026.

nLockTime / nSequence semantics (key for layer-2)

  • nLockTime: tx valid only after specified block-height or unix-time.
  • nSequence per-input:
    • 0xFFFFFFFF → final, disables nLockTime for that input.
    • 0xFFFFFFFE → does not signal opt-in RBF (BIP125). Signalling is moot for relay: full-RBF is the Core default since v28.0 (Oct 2024).
    • < 0xFFFFFFFE → signals opt-in RBF.
    • BIP68 relative locktime when input's tx version ≥ 2:
      • bit 31 = 0 → relative time enforced
      • bit 22 = 0 → block-height units, =1 → 512s units
      • low 16 bits = the lock value

Consensus vs Policy

LayerExamplesWhere defined
Consensusblock size weight ≤ 4M WU, sigops ≤ 80k, nLockTime, output value rulessrc/consensus/ in Core
Standardnessnon-standard scripts rejected by mempool, dust threshold, MAX_STANDARD_TX_WEIGHT=400k, replaceability, cluster limitssrc/policy/

A tx that is non-standard but consensus-valid can be mined (via direct submission to a miner like mempool.space accelerator) and is valid in a block.

Recent additions

  • Cluster mempool (Bitcoin Core 31.0, April 2026) — the mempool no longer enforces ancestor/descendant size or count limits. Connected components ("clusters") are capped instead: 64 txs and 101 kvB (-limitclustercount / -limitclustersize). RBF now requires the resulting mempool feerate diagram to be strictly better; the CPFP carveout is gone (use TRUC + sibling eviction). Still current in 31.1 (July 2026).
  • Opportunistic 1p1c relay (Bitcoin Core 28.0, October 2024) — a parent below the mempool min feerate is paired with one child and evaluated as a package over the existing tx-relay protocol; submitpackage (26.0, December 2023) does the same locally. BIP331 (“Ancestor Package Relay”) is still Status: Draft as of September 2026 and its sendpackages / pkgtxns P2P messages have never shipped — see package-relay/SKILL.md.
  • TRUC v3 transactions (BIP431) — version=3, ≤1 unconfirmed ancestor, ≤ 10kvB, sibling-eviction, child can pay 0 fee. Pairs with ephemeral anchors (output value = 0, must be spent in same package).

See also

Reference

  • Bitcoin Core source: src/consensus/, src/validation.cpp
  • BIPs: 9, 8, 16, 30, 34, 65, 68, 112, 113, 141, 143, 144, 147, 341, 342, 431
Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

MIT

Source path

skills/bitcoin/protocol/consensus

Default branch

main

Latest commit

9496306

Tree SHA

fe4e2f1