Consensus Rules

The rules that define the protocol used for the blockchain

A number of standard policies are set around network consensus and its ruleset. The consensus rules are codified into the Bitcoin node client software system and represent fixed and unchangeable rules applied across the network. These rules must be strictly adhered to by a node to participate in the network governance process actively.

Genesis Block Rule

The blockchain is anchored to the very first block that was created on 3 January 2009 (block timestamp 1231006505). This marked the beginning of blockchain, hence the name, Genesis. Only blocks that add to the blockchain formed by building upon the Genesis block are valid.

The Genesis Block is special: its header and coinbase were hardcoded into the software rather than discovered by the mining network (which did not yet exist). It carries the first 50-coin subsidy in an ordinary pay-to-public-key coinbase output.

Those 50 coins are unspendable because of a hardcoded special case that became consensus. When a node initializes the chain it inserts the Genesis block, but it skips connecting the Genesis coinbase into the transaction / UTXO database. There is therefore no recognized UTXO for that output, and any attempt to spend it fails validation as a missing input. The same handling remains in modern reference implementations (the classic comment: “Special case for the genesis block, skipping connection of its transactions (its coinbase is unspendable)”).

The Genesis block rule prevents a malicious party from creating a new chain to perpetrate a malicious redirection of hash power or economic activity. It is an essential aspect of Simplified Payment Verification, allowing users to check they are using the correct chain of blocks with minimal overhead.

The genesis block is identified using its block hash - 
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.

By ensuring all network users are aware of this block hash, there can be certainty around which chain of blocks is valid. If a user or node connects to a chain of blocks which leads back to the point of origin that is not the genesis block, it can know immediately that it has connected to the wrong network.

Block Size Rule

The size of a block is the size in bytes of the serialised form of the block, including the block header and all of the transactions in it.

From the UAHF onward there is no single hard-coded maximum block size baked into the protocol; instead each node enforces a maximum that miners coordinate on. There is a consensus limit in force at any given time — a block larger than the active maximum is invalid (reason bad-blk-length) — but the specific value is an operator-configured policy rather than a fixed protocol constant. Before the UAHF the limit was the fixed LEGACY_MAX_BLOCK_SIZE of 1 MB. See Blocks and the validity rules below.

Longest Chain Rule

As described in Node Operations — Mining, the node is ­­­expected to always keep track of the longest honest chain while building on top of that chain. This is the minimal and optimal method for mining nodes to configure their software. If at any time a mining node is intentionally building on an alternative chain than the longest honest one, it is considered malicious and is in violation of the protocol.

Block Subsidy Rule

When creating new blocks, mining nodes are rewarded by block subsidies. These subsidies also perform the function of distributing new coins in the network. The rewards received by the mining node from this activity are considered as financial income and are subject to local income and tax regulation. The services performed by the mining node are also bound under the regulations that any business falls under in their local jurisdiction.

Difficulty Adjustment

The purpose of difficulty adjustment is to maintain the stability of the network operation and to keep control of the rate of block creation to as close to 10 minutes as possible.

This requires that the difficulty level be adjusted based on verifying the frequency of new blocks being discovered. This adjustment is applied in the mining process using the ‘bits’ value in the block header, which impacts the target value calculation (defined by a number of leading zeros in the block hash value). This has been implemented in the node software and is not manually configurable for a specific node.

In the first 284 days of the launch of the Bitcoin blockchain network, there should be 144 blocks a day for a total of 41,000 blocks mined. That is 2 million bitcoin. Instead, only 1.25 million were mined at that point.

Network consensus (also known as Nakamoto consensus)

A proof of work quorum system is based on forming a network consensus in such a way that there should be no value at all in the consensus methodology. This is an alternate system to traditional voting by reputation or selection methodologies.

Rather than achieving consensus in the blockchain by voting, they show acceptance of a block by building on top of it. In the protocol, this is defined as 'voting by nodes'. Nodes “vote” for process transactions through the creation of blocks and by building new blocks on previously broadcast blocks of accepted transactions.

The number of nodes that have created blocks is publicly available. At most, 2016 nodes may operate (6 blocks an hour for 14 days) as the difficulty adjustment period of two weeks only allows this number. The difficulty adjustment will reset the count for the new set of 2016 nodes that will mine a block. In general, most of these blocks are created by a small set of nodes, typically numbering between 5-10. So at any point in time, the network votes are fixed to a maximum of 2016 nodes. There could be other nodes present in the network, but if they are not able to create blocks, they are not part of the network consensus and voting mechanism. This makes them just listener clients and not part of the node network.

Another aspect to look at is the 100 block rule for coinbase output. 100 blocks is the minimum number of blocks that a node has to wait before spending a coinbase transaction. Therefore after finding a valid block a node has an economic incentive to secure the network for 100 blocks. Therefore the window of nodes that can operate at the same time is 100. Because at any time max 100 nodes have economic incentives to maintain and secure the network

With the PoW process, the participant nodes in the network change every 2 weeks (along with difficulty). Any nodes that build blocks in the new cycle are considered nodes for that difficulty period. This mechanism allows for open and permissionless-based operations in the network.

By using a brute force-like process, it ensures there is no unfair advantage possible in the process of PoW mining. This key innovation creates trustless and permissionless participation of nodes in the network making them non-trusted intermediaries. When other methods are utilised, this creates an element of trust in the intermediary, making the system vulnerable and a target for malfeasance. The characteristic of untrusted transaction execution in the network is what makes a blockchain innovative.

First Seen rule

When receiving transactions, the first-seen rule is applied to determine which transaction is valid in the case of a double-spend. When a node detects a double-spend, it considers the transaction that it received first as the valid spender of that coin.

The rule has been extended further to add any blocks which are discovered that include the double-spend transaction - those blocks should also be considered invalid, and the node should continue to mine against it unless a second block is discovered on top of that block, indicating a majority of the network has determined that the other transaction was the first seen.

Transaction and block validity rules

This section enumerates the consensus checks that determine whether a transaction or block is valid. Each is a testable rule: if the stated condition holds, the transaction or block is rejected with the given reason code. A transaction that is valid under these rules today remains valid forever.

Ground truth. Every rule below is taken from CheckTransactionCommon, CheckCoinbase, CheckRegularTransaction, Consensus::CheckTxInputs, IsFinalTx, GetBlockSubsidy, and CheckBlock in src/validation.cpp, with limit constants from src/consensus/consensus.h. Reason codes in code font are the exact rejection strings emitted by the node. Citations pin to release v1.2.2 (commit 879fc8b); CheckTxInputs/CheckBlock live in validation.cpp (there is no tx_verify.cpp or blockvalidation.cpp at this release).

Rules common to every transaction

Checked by CheckTransactionCommon (validation.cpp):

Reason code	Rejected when	Era
bad-txns-vin-empty	the transaction has no inputs	all
bad-txns-vout-empty	the transaction has no outputs	all
bad-txns-oversize	serialized size > MAX_TX_SIZE_CONSENSUS (1 MB pre-Genesis, 1 GB from Genesis)	all
bad-txns-vout-negative	any output value < 0	all
bad-txns-vout-toolarge	any output value > MAX_MONEY (21,000,000 × 10⁸ sat)	all
bad-txns-txouttotal-toolarge	the sum of output values overflows or exceeds MAX_MONEY	all
bad-txn-sigops	signature-operation count exceeds the per-transaction limit (20,000)	pre-Genesis only

Output values are non-negative — zero is valid (needed for OP_RETURN data outputs). The per-transaction sigop limit is removed at Genesis.

Coinbase transaction

Checked by CheckCoinbase:

Reason code	Rejected when	Era
bad-cb-missing	the transaction is not a coinbase (must have exactly one input whose prevout is null)	all
bad-cb-length	coinbase scriptSig size < 2 or > MAX_COINBASE_SCRIPTSIG_SIZE (100)	all

A coinbase must also carry the block-height prefix from the BIP34 activation height (reason bad-cb-height), and its total output must not exceed subsidy + fees (reason bad-cb-amount) — see Block-level rules and Block subsidy.

Regular (non-coinbase) transaction

Checked by CheckRegularTransaction:

Reason code	Rejected when	Era
bad-tx-coinbase	a non-first transaction is a coinbase	all
bad-txns-prevout-null	any input spends a null prevout	all
bad-txns-inputs-duplicate	the same prevout is spent by two inputs	all
bad-txns-vout-p2sh	any output is a P2SH template (OP_HASH160 <20 bytes> OP_EQUAL)	Genesis onward (P2SH sunset)

Contextual input rules

Checked by Consensus::CheckTxInputs, using the UTXO set and spend height:

Reason code	Rejected when	Era
(inputs unavailable)	a referenced input is missing or already spent	all
bad-txns-premature-spend-of-coinbase	a coinbase output is spent before COINBASE_MATURITY (100) blocks have passed	all
bad-txns-premature-spend-of-confiscation	a confiscation output is spent before CONFISCATION_MATURITY (1000) blocks	from confiscation upgrade
bad-txns-inputvalues-outofrange	an input amount or the input total is outside [0, MAX_MONEY]	all
bad-txns-in-belowout	sum(inputs) < sum(outputs)	all
bad-txns-fee-negative	the computed fee is negative	all
bad-txns-fee-outofrange	the fee is outside the money range	all

(Confiscation-transaction checks — bad-ctx-invalid, bad-ctx-not-whitelisted, bad-txns-inputs-frozen — are covered on the Protocol Upgrade History page.)

Finality (nLockTime / nSequence)

A transaction is final (IsFinalTx, validation.cpp) when:

• nLockTime == 0; or
• nLockTime < LOCKTIME_THRESHOLD (500,000,000) and nLockTime is below the current block height; or
• nLockTime ≥ LOCKTIME_THRESHOLD and nLockTime is below the current block time; or
• every input has nSequence == 0xffffffff (SEQUENCE_FINAL), which makes the transaction final regardless of nLockTime.

A non-final transaction in a block is rejected as bad-txns-nonfinal. (See Transactions for the field layout and BIP68 relative-locktime encoding.)

Block subsidy rule (consensus)

The coinbase may claim at most the block subsidy plus the total fees. The subsidy (GetBlockSubsidy) is:

• 50 × COIN at height 0, where COIN = 100,000,000 satoshis;
• halved every nSubsidyHalvingInterval (≈ 210,000) blocks (subsidy >> halvings);
• zero once 64 or more halvings have occurred.

A coinbase whose total output exceeds subsidy + fees is rejected as bad-cb-amount.

Block-level rules

Checked by CheckBlock (validation.cpp L5708) and the contextual block check:

Reason code	Rejected when	Era
high-hash	the header fails proof of work (CheckProofOfWork)	all
bad-txnmrklroot	hashMerkleRoot ≠ the computed Merkle root	all
bad-txns-duplicate	the Merkle computation detects a mutated (duplicated-subtree) tree	all
bad-cb-missing	the block has no transactions / no coinbase first	all
bad-blk-length	serialized block size > the active maximum block size	all
bad-blk-sigops	block signature-operation count > 20000 × ceil(size / 1 MB)	pre-Genesis only
bad-cb-height	the coinbase scriptSig does not begin with the block height	BIP34 height onward

The first transaction must be the coinbase and no other transaction may be a coinbase (enforced by running CheckCoinbase on vtx[0] and CheckRegularTransaction, which rejects coinbases, on the rest). Both sigop limits (per-transaction and per-block) are removed at Genesis. See Blocks for header/Merkle/PoW detail.

Note on scope

The rules above are consensus — they define validity. Miner-configurable limits (relay policy, the specific maximum block size a node accepts, mempool admission) are policy: they affect what a node relays or mines, not whether a transaction or block is valid. Policy is covered on the Policy vs Consensus page.