Skip to main content

Overview

The consensus layer defines the rules that determine which blocks and transactions are valid in Bitcoin. These rules must be followed by all nodes to maintain network consensus. Bitcoin Core implements these rules in a modular fashion, with consensus-critical code isolated in specific libraries. Primary locations:
  • src/consensus/ - Core consensus validation
  • src/script/interpreter.cpp - Script execution
  • src/validation.cpp - Block and transaction validation
  • libbitcoin_consensus - Consensus library

Consensus Architecture

Consensus Parameters

Chain Parameters

Defined in src/consensus/params.h:

Network-Specific Values

Mainnet:
  • Target block time: 600 seconds (10 minutes)
  • Difficulty adjustment: Every 2016 blocks
  • Subsidy halving: Every 210,000 blocks
  • Initial subsidy: 50 BTC
  • Maximum supply: ~21 million BTC
Testnet:
  • Same rules as mainnet
  • Minimum difficulty blocks allowed
  • Different genesis block
Regtest:
  • Instant mining (difficulty = 1)
  • No peers required
  • Customizable parameters

Block Consensus Rules

Block Header Validation

Rules:
  1. Hash < Target: Block hash must be below difficulty target
  2. Timestamp: Not more than 2 hours in the future
  3. Version: Recognized version number
  4. Previous block: Must reference known block

Block Structure Rules

Size and weight limits:
Weight calculation:
  • Base size: Transaction size without witness data
  • Total size: Complete transaction size including witness
Witness scale factor:

Coinbase Transaction

Requirements:
  1. First transaction in block must be coinbase
  2. Exactly one coinbase per block
  3. Coinbase input must have:
    • Previous output: null hash (0x00…00)
    • Output index: 0xFFFFFFFF
    • Script sig: 2-100 bytes (includes height per BIP34)
Coinbase output value:
Total value constraint:

Transaction Consensus Rules

Transaction Structure

Basic Transaction Rules

  1. Version: Currently 1 or 2 (version 3 for TRUC)
  2. Inputs: At least 1 input (except coinbase)
  3. Outputs: At least 1 output
  4. Output values: Each output ≥ 0, total < 21M BTC
  5. Size: ≤ 400,000 weight units

Input Validation

Rules:
  1. Referenced output must exist in UTXO set
  2. Not already spent (no double-spends)
  3. Script validation passes
  4. Sequence/locktime constraints satisfied

Output Validation

Rules:
  1. Value ≥ 0
  2. Value ≤ 21M BTC (consensus limit)
  3. Sum of outputs ≤ sum of inputs (for non-coinbase)

Script Validation

Script Types

Bitcoin supports multiple script types:

1. Pay to Public Key Hash (P2PKH)

2. Pay to Script Hash (P2SH - BIP16)

Activation: Block 173,805 (April 1, 2012) Validation:
  1. Verify scriptSig + scriptPubKey
  2. Extract redeemScript from scriptSig
  3. Verify redeemScript execution

3. Pay to Witness Public Key Hash (P2WPKH - BIP141)

Benefits:
  • Fixes transaction malleability
  • More efficient (lower fees)
  • Enables Lightning Network

4. Pay to Witness Script Hash (P2WSH - BIP141)

5. Pay to Taproot (P2TR - BIP341)

Features:
  • Schnorr signatures (BIP340)
  • MAST (Merkelized Alternative Script Trees)
  • Tapscript (BIP342)
  • Better privacy and efficiency

Script Interpreter

Script execution in src/script/interpreter.cpp:
Process:
  1. Execute scriptSig → produces stack
  2. Execute scriptPubKey with that stack
  3. Top stack element must be true
  4. For P2SH/P2WSH: Additional script execution

Signature Validation

ECDSA (Legacy and SegWit v0)

Requirements:
  • DER encoding (BIP66)
  • Low-S values (BIP146)
  • Proper SIGHASH type
  • Valid secp256k1 signature

Schnorr (Taproot/SegWit v1)

Benefits:
  • 64-byte signatures (vs ~72 for ECDSA)
  • Batch verification
  • Key aggregation (MuSig2)
  • Provable security

Soft Fork Mechanisms

Buried Deployments (BIP90)

Soft forks activated at specific heights:
These are “buried” because they activated long ago and are now enforced unconditionally.

BIP9 Version Bits

Flexible soft fork deployment:
States:
Taproot activation (BIP341/342):
  • Bit: 2
  • Start time: April 24, 2021
  • Timeout: August 11, 2021
  • Activation height: 709,632 (November 2021)
  • Status: ACTIVE

Implemented BIPs

Bitcoin Core implements numerous BIPs (Bitcoin Improvement Proposals):

Consensus Changes

Network Protocol

Wallet and Addresses

Consensus-Critical Code

Isolation Strategy

Consensus code is carefully isolated:
Design principles:
  1. No external dependencies (except crypto)
  2. Deterministic behavior
  3. No floating-point arithmetic
  4. Careful integer overflow handling
  5. Identical behavior across platforms

libbitcoin_consensus

Extractable consensus library:
Use cases:
  • Alternative implementations can validate using Bitcoin Core’s consensus
  • Third-party verification
  • Cross-platform consensus checking

Validation Caching

Script Execution Cache

Caches script execution results:
Cache types:
  1. Signature cache: Individual signature verifications
  2. Script cache: Full script execution results
Benefits:
  • Avoid re-executing scripts during reorgs
  • Faster block validation
  • Reduced CPU usage

Assumevalid

Skip signature validation for old blocks:
Security model:
  • Relies on proof-of-work accumulation
  • All other consensus rules still enforced
  • Significantly faster initial sync
  • Configurable via -assumevalid=<hash>

Time Locks

Absolute Time Locks

nLockTime (transaction-level):
OP_CHECKLOCKTIMEVERIFY (BIP65):
  • Script-level absolute time lock
  • Compares against nLockTime
  • Enables refund transactions

Relative Time Locks

nSequence (input-level - BIP68):
OP_CHECKSEQUENCEVERIFY (BIP112):
  • Script-level relative time lock
  • Enables payment channels
  • Used in Lightning Network

Median Time Past (BIP113)

Time locks compare against median of last 11 blocks:
Benefits:
  • Prevents miner time manipulation
  • More reliable than single block timestamp

Consensus Upgrades in Practice

Activation Process

  1. Proposal: BIP drafted and discussed
  2. Implementation: Code merged (inactive)
  3. Signaling: Miners signal readiness via version bits
  4. Lock-in: Threshold reached (95% of 2016 blocks)
  5. Activation: Rules enforced after lock-in period

Recent Example: Taproot

Future Considerations

Potential Soft Forks

Under discussion:
  • ANYPREVOUT (BIP118) - Signature flexibility for eltoo
  • CHECKSIGFROMSTACK - Covenant functionality
  • OP_CAT - Concatenation operation
  • Cross-input signature aggregation

Consensus Evolution

Challenges:
  • Backward compatibility
  • Decentralized coordination
  • Testing and verification
  • Long-term maintenance
Process improvements:
  • Better soft fork deployment mechanisms
  • More comprehensive testing (fuzzing, formal verification)
  • Clearer activation paths