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:
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
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, and
Block N (and its parents).
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: