Bitcoin Consensus Rules Reference

What Are Bitcoin Consensus Rules?

Bitcoin consensus rules are the set of validation checks that every full node independently enforces when processing blocks and transactions. A block or transaction that violates any consensus rule is rejected unconditionally, regardless of how much proof-of-work backs it. These rules define what Bitcoin is: any change to them requires either a soft fork (tightening rules) or a hard fork (loosening them).

This reference documents every major consensus rule enforced by Bitcoin nodes as of Bitcoin Core 31.0 (released April 2026). It covers block validation, transaction validation, script execution limits, and the soft fork rules activated through BIPs 34, 65, 66, 68, 112, 113, 141, 143, 341, and 342.

Block Validation Rules

Every block must pass these checks before a node will accept it into the chain. Failure on any single rule causes immediate rejection.

Block Weight and the 4M Limit

Before SegWit, Bitcoin enforced a flat 1,000,000-byte (1 MB) block size limit. BIP 141 replaced this with a weight-based system that gives a discount to witness data:

block_weight = base_size × 3 + total_size

Equivalently, non-witness bytes cost 4 weight units each, and witness bytes cost 1 weight unit each (the WITNESS_SCALE_FACTOR is 4). The maximum block weight is 4,000,000 WU. For a legacy-only block with no witness data, this maps exactly to the original 1 MB limit (1,000,000 bytes × 4 = 4,000,000 WU). In practice, blocks containing SegWit transactions reach roughly 1.5 to 2.3 MB in serialized size.

Virtual size (vsize) is defined as weight / 4 (rounded up), so the maximum block is 1,000,000 vbytes. Fee rates are typically quoted in sat/vB to normalize the cost across transaction types. For tools that help estimate fees, see the fee estimator.

Transaction Validation Rules

Individual transactions must satisfy these consensus rules before inclusion in a valid block. Note that nodes also enforce additional policy rules (like dust limits and standardness checks) that are stricter than consensus but not covered here.

• Input and output lists must each be non-empty
• All output values must be between 0 and 2,100,000,000,000,000 satoshis (21 million BTC)
• Sum of all output values must not exceed the money range
• No input may reference the null outpoint (hash=0, index=0xFFFFFFFF) except in a coinbase transaction
• Each input must reference an existing, unspent output in the UTXO set
• Sum of input values ≥ sum of output values (difference is the transaction fee)
• No double-spending within the same block
• Minimum transaction weight: 240 weight units (60 bytes × 4)
• Coinbase scriptSig length: between 2 and 100 bytes

Script Execution Limits

Bitcoin Script has built-in resource limits that prevent denial-of-service attacks during validation. These limits differ between legacy/SegWit v0 scripts and Tapscript (BIP 342).

Tapscript's removal of the 10,000-byte and 201-opcode limits enables significantly more complex spending conditions. The per-input sigops budget (50 + total witness bytes for the input) replaces the block-wide sigops limit, allowing scripts to scale their computational cost proportionally to the data they commit to the chain. For a deeper look at Tapscript capabilities, see our research on Taproot and Schnorr signatures.

Soft Fork Activation History

Bitcoin's consensus rules have been tightened through a series of soft forks, each activated at a specific block height. The following table documents every major consensus soft fork, its activation height, and what it changed. Early soft forks (BIPs 34, 66, 65) are now enforced as "buried deployments" per BIP 90, meaning nodes check block height directly rather than reading version bits.

Timelock Rules in Detail

Bitcoin supports both absolute and relative timelocks at the transaction level and the script level. Timelocks are fundamental to payment channels, including the Lightning Network, and are enforced at the consensus layer.

Absolute timelocks use the nLockTime transaction field. Values below 500,000,000 are interpreted as block heights; values at or above that threshold are Unix timestamps. Since BIP 113 (block 419,328), time-based lock comparisons use the Median Time-Past (median of the previous 11 block timestamps) rather than the block's own timestamp, ensuring a monotonically increasing reference.

Relative timelocks (BIP 68) repurpose the nSequence field on transaction inputs. If bit 31 is unset and the transaction version is ≥ 2, the lower 16 bits encode a lock duration. Bit 22 determines the unit: if unset, the value is a block count; if set, the value multiplied by 512 gives seconds. OP_CHECKSEQUENCEVERIFY (BIP 112) allows scripts to enforce these relative locks, enabling constructions like HTLCs and revocation-based channels.

What Happens When Rules Are Violated

Consensus rules are absolute. When a node detects a violation, the response depends on the severity:

• Invalid blocks are rejected immediately and never stored. The node does not relay them, and no transactions within the block are confirmed.
• Peers that send invalid blocks or transactions are penalized. Bitcoin Core assigns "ban scores" to peers: sending a block that fails consensus validation typically results in immediate disconnection and a ban lasting 24 hours by default.
• If a miner produces a block that only upgraded nodes reject (because it violates a new soft fork rule), non-upgraded nodes may temporarily follow the invalid chain. Once the economic majority of nodes rejects the block, the invalid chain gets orphaned and the network converges on the valid chain.
• A hard fork occurs when nodes disagree on rules permanently, resulting in two incompatible chains. This has not happened on Bitcoin's main chain since the BIP 66 fork incident in July 2015, which was resolved within hours.

For developers building on layer 2 protocols like the Lightning Network or Spark, understanding consensus rules is critical. Layer 2 security ultimately depends on the ability to broadcast valid on-chain transactions: a justice transaction or force-close that violates consensus rules provides no protection.

Consensus vs. Policy Rules

Not every validation check in Bitcoin Core is a consensus rule. Policy (or "standardness") rules are additional filters that nodes apply to unconfirmed transactions in the mempool but that miners are free to override. Common policy rules that are often confused with consensus:

• Dust limit (546 satoshis for legacy outputs, 294 for SegWit) is policy, not consensus. A miner can include a 1-satoshi output in a valid block.
• Maximum transaction size of 400,000 weight units (100,000 vbytes) is policy. At the consensus level, a single transaction can fill an entire block.
• Minimum relay fee (default 1 sat/vB as of Bitcoin Core 31.0) is policy. Zero-fee transactions are consensus-valid.
• OP_RETURN output size limits are policy. Bitcoin Core 30.0 raised the relay limit to 100 KB, but there is no consensus cap on OP_RETURN data beyond the block weight limit.
• Replace-by-fee rules are entirely policy. Consensus does not care which of two conflicting transactions ends up in a block.

The distinction matters for protocol developers: consensus rules guarantee what is and isn't valid on-chain, while policy rules affect transaction propagation and mempool acceptance. A transaction rejected by policy can still be mined if submitted directly to a miner. For more on transaction propagation, see our Bitcoin transaction lifecycle guide. You can also inspect raw transactions with the transaction decoder.

Signature Verification Across Eras

Bitcoin has used three distinct signature verification schemes, each introduced through soft forks:

Legacy transactions use ECDSA over the secp256k1 curve. BIP 66 (block 363,725) enforced strict DER encoding for all signatures, eliminating a class of malleability attacks caused by OpenSSL's permissive parsing. The sighash for legacy inputs requires serializing and hashing the entire transaction for each input, creating O(n²) computational cost for large transactions.

SegWit v0 (BIP 143) introduced a new digest algorithm that includes the input value in the signed data and pre-computes reusable hash midstates (hashPrevouts, hashSequence, hashOutputs). This reduces signature verification to O(n) for n inputs, fixing the quadratic hashing problem that had been a denial-of-service vector.

Taproot (BIP 341/342) switched to Schnorr signatures (BIP 340), which are smaller, enable native key aggregation via MuSig2, and support batch verification across multiple inputs. Taproot key path spends are indistinguishable from single-signature payments on-chain, improving privacy.

Frequently Asked Questions

What is the maximum Bitcoin block size?

Since SegWit activation at block 481,824, Bitcoin uses a weight-based limit of 4,000,000 weight units (4 MWU) rather than a flat byte limit. Non-witness data costs 4 weight units per byte, and witness data costs 1 weight unit per byte. In practice, this allows blocks of roughly 1.5 to 2.3 MB in serialized size, depending on the mix of transaction types. For legacy-only blocks, the effective limit remains 1 MB.

How many confirmations until a coinbase transaction can be spent?

Coinbase transaction outputs require 100 confirmations before they can be spent. This COINBASE_MATURITY rule exists because chain reorganizations can invalidate coinbase transactions (since the proof-of-work changes), and 100 blocks provides a large safety margin against reorgs making already-spent mining rewards disappear.

What is the difference between consensus rules and policy rules?

Consensus rules are enforced by every node and determine block validity. A block violating consensus is rejected by the entire network. Policy rules are additional restrictions nodes apply to unconfirmed transactions (like dust limits, relay fees, and standardness checks) that affect mempool propagation but not block validity. A miner can include a policy-violating transaction in a consensus-valid block.

What happens if a miner creates a block that violates consensus?

Every full node independently rejects the invalid block. The miner wastes the energy spent on proof-of-work and receives no block reward. Peers that relay the invalid block are penalized with ban scores and may be disconnected. If non-upgraded nodes accept the block (in a soft fork scenario), a temporary chain split occurs until the economic majority converges on the valid chain.

How does Taproot change Bitcoin's consensus rules?

Taproot (BIPs 341/342), activated at block 709,632, added SegWit version 1 spending rules. Key changes: Schnorr signatures replace ECDSA for Taproot inputs, OP_CHECKSIGADD replaces OP_CHECKMULTISIG, the 10,000-byte script size limit and 201-opcode limit are removed for Tapscript, sigops use a per-input budget instead of a block-wide cap, and undefined opcodes become OP_SUCCESSx (enabling future soft fork upgrades without new witness versions).

How are Bitcoin sigops counted?

For legacy and SegWit v0 scripts, sigops are counted against a block-wide budget of 80,000 weighted sigops. Legacy sigops cost 4 each (matching the original 20,000 limit times the witness scale factor). SegWit v0 sigops cost 1 each. Tapscript inputs do not count toward the block-wide limit at all: instead, each input gets its own budget of 50 + total witness bytes, with each signature operation consuming 50 from that budget. This per-input model allows larger scripts without affecting other transactions in the block.

Why does Bitcoin use Median Time-Past instead of the block timestamp?

BIP 113 (activated at block 419,328) switched timelock evaluation from the block's own timestamp to the Median Time-Past (median of the previous 11 blocks). This was necessary because block timestamps are only loosely constrained: they can be up to 2 hours in the future and do not need to be strictly ordered. MTP increases monotonically by definition, providing a reliable reference for time-based timelocks used in payment channels and HTLCs.

This reference is for informational purposes only and does not constitute financial or security advice. Consensus rules are documented as of Bitcoin Core 31.0 (April 2026). Rule details may change in future soft forks. Always consult the Bitcoin Core source code and BIP specifications for authoritative definitions.