> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/bitcoin-protocol-documentation/specification/consensus-rules.md).

# Consensus Rules

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](/bitcoin-protocol-documentation/specification/blocks.md) and the [validity rules](#transaction-and-block-validity-rules) below.

## **Longest Chain Rule**

As described in [Node Operations — Mining](/bitcoin-protocol-documentation/implementation-notes/node-operations.md#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.

{% hint style="info" %}
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.
{% endhint %}

## **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.

{% hint style="info" %}
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
{% endhint %}

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`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/validation.cpp), with limit constants from [`src/consensus/consensus.h`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/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`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/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](#block-level-rules) and [Block subsidy](#block-subsidy-rule-consensus).

### 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`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/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](/bitcoin-protocol-documentation/specification/transactions.md) 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](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/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](/bitcoin-protocol-documentation/specification/blocks.md) 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](/bitcoin-protocol-documentation/implementation-notes/policy-vs-consensus.md) page.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/specification/consensus-rules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.