Policy vs Consensus
The distinction between consensus rules and configurable policy
A node applies two distinct kinds of check to transactions and blocks:
Consensus rules determine validity. Every node enforces them identically, and they are always checked. A block is valid or invalid purely on the consensus rules. These are specified in Consensus Rules.
Local policy is per-node configuration — relay limits, mempool-admission limits, minimum fee, the specific block/transaction sizes a node accepts. Policy affects what a node relays or mines, not whether something is valid. A transaction rejected by one node's policy may be perfectly valid and mined by another.
Local policy is checked before a transaction is admitted to a node's mempool or included in a candidate block; consensus rules are checked whenever a transaction or block is validated. Where a limit has both a consensus value and a policy default (block size, for example), only the consensus value bears on validity — the policy default is operator-chosen and out of the validity contract.
Node components
A node is conventionally described as three functional components. This is an abstraction of the reference implementation, not a protocol requirement — the boundaries are an implementation choice.
Node software — validates transactions, assembles candidate blocks, and validates received blocks against the consensus rules.
Mining — performs the proof-of-work search over candidate headers.
Bitcoin Server Network (BSN) — the peer-to-peer message layer.
How these functions work is described under Node Operations; only the consensus rules the node software enforces are part of the protocol.
Reference rules list
Last updated