Block-Level Validation Rules

Block-level validation rules, also referred to as consensus rules, define what is permitted to be included in a block. Block-level validation rules are absolute and any block or transaction that would cause a violation such a rule must be rejected. These differ from network-level validation rules, also referred to as standardness rules, which can be circumvented by miners, should they wish to include a non-standard transaction in a block. In short, consensus (block-level) rules define what is permitted in a block, while standardness (network-level) rules define recommended behavior for nodes on the network.

When validating a transaction, it must be done within the context of a block. That may be a historical (or new) block that the transaction is a part of or it may be as a part of a hypothetical "next" block. The latter category, often referred to as "mempool" transactions, represent transactions that a node is aware of, and considers valid, but that have not yet been added to a block. In this case, they are treated as though they are all in a new block that follows after the last block in the longest chain the node is currently aware of.

The reason that transaction validation is context-dependent in this way stems from what is probably the most important validation rule: the inputs to a transaction must be UTXOs. That is, transactions must spend transaction outputs that were created by a prior transaction but that have not been spent by another transaction in the target block or its history. Note that this means that blocks with divergent histories will treat different transactions as valid. For example, consider the following scenario:

graph LR;
... --> blockn(Block N)
blockn --> blocka(Block A)
blockn --> blockb(Block B)
blocka --> blocka2(Block A')
blockb --> blockb2(Block B')

Since Block A' and Block B' are at the same block height, there may be some nodes that treat Block A' as the most recent block (e.g. Node A) and others that treat Block B' as the most recent block (e.g. Node B). If a transaction is submitted to both Node A and Node B that spends an output created in a transaction in Block A, Node A may consider the transaction valid while Node B would reject it on the grounds that it is dependent on a UTXO that is not a part of Block B''s history, which only contains Block B', Block B, and Block N (and its parents).

Consensus Rules


SigChecks was implemented as a part of HF-20200515 and replaced the existing system of signature operation counting (SigOps). During script execution, signature checks are counted using the following rules: