What nodes check, and why a blockchain needs consensus

Three desks, three questions

Picture a node with three desks. At the first desk: “Does this satisfy the rules?” At the second: “Will I keep and relay this unconfirmed transaction?” At the third: “Which valid history should I follow?”

The desks are a teaching device, not the architecture of Bitcoin Core. They help prevent a common mistake: treating every rejection, delay, or disagreement as the same kind of event.

Consensus rules define what the node accepts as valid in the chain. A transaction cannot create arbitrary value simply because someone broadcasts it widely. An invalid block does not become acceptable merely because a miner spent effort producing it.

Relay policy is more local. Bitcoin Core applies additional policy to unconfirmed transactions before accepting them into its mempool. Different peers can have different local views and choices. A transaction that a peer declines to relay is not automatically consensus-invalid.

Agreement still needs a history

Even when two proposed transactions are individually plausible against the same earlier state, they may conflict by spending the same output. They cannot both become valid spends in the same accepted history.

Temporary competing blocks can also exist. Nodes compare valid chains using accumulated proof of work. The word valid does essential work here. History selection operates within the rules a node enforces; it is not an override for them.

Follow three fictional cases

Case	Question to ask	What follows?
A spend allocates more value than its inputs provide	Does it satisfy value rules?	More relay does not repair the invalid arithmetic
A transaction meets consensus requirements but a peer declines it under local policy	Will this peer relay it?	Other peers may have different unconfirmed views
Two valid branches extend a shared ancestor	Which valid history has more accumulated work?	A node may change its active chain when it learns more

A wallet saying “pending” therefore compresses several facts. Its backend may have accepted the transaction locally; that does not prove every node has it, that a miner will select it, or that it will confirm by a particular time.

Also distinguish a node from a miner. A validating node checks the chain it accepts. A miner constructs candidate blocks and searches for suitable proof of work. One operator can do both, but the roles are not synonyms.

Debug the sentence

Consider this explanation: “All nodes voted to approve the payment, so it must enter the next block.” Underline each unsupported leap.

Expected result: there is no requirement that all nodes see the payment at once; validation is not a simple one-node-one-vote approval process; local relay does not guarantee miner selection; and there is no guaranteed next-block deadline.

Rewrite it as a statement about evidence: “Our node accepted the transaction into its local mempool. It has not yet appeared in a block on our node’s active chain.” This sentence gives a reader a concrete observation and its boundary.

For a deeper implementation exercise, read Bitcoin Core’s policy documentation beside the consensus explanation. Identify one sentence about local mempool handling. Keep any version-specific policy numbers out of a timeless diagram unless you also record the applicable version.