Consensus rules determine which transactions and blocks Bitcoin can accept. Each Full Node, a program that independently verifies the network, applies them for itself. It checks, for example, that the same funds are not spent again, that spending conditions written in the Bitcoin Script language are met, and that the block has valid Proof of Work, evidence of a solution to the mining challenge. It also checks the amount of newly created bitcoin. Greater computing power does not let a miner bypass these rules.
Imagine someone spending the same funds from an earlier payment first to pay you and then to pay a shop. Both spends cannot belong to a valid history. To check this, a node tracks transaction outputs: records of amounts and the conditions under which they can be spent. When a node receives a block, it checks whether the block follows its rules, not who recommended it. Checks include the availability of the outputs being spent, Bitcoin Script conditions and any required signatures, Proof of Work and the permitted miner reward. Breaking a rule means rejection. Corporate support or a majority of online votes does not change that result. [1]
A miner selects transactions and searches for a block; a Full Node independently checks the result. Developers can propose a change and release software, but that alone does not change other nodes’ rules. Node operators choose which software to run. Their choice determines what they themselves accept, not what everyone else must accept. [2] [1]
A node also has rules for unconfirmed transactions: what it keeps in its Mempool, its local collection of transactions awaiting confirmation, and what it forwards to other nodes. These local rules, called policy, can be stricter than consensus. Rejection from a mempool therefore does not by itself mean a transaction would be invalid in a block. Relay policy is not applied when validating blocks. [3]
A Soft Fork tightens the rules: blocks valid under the new rules also satisfy the old ones. Older nodes do not, however, check the new conditions. A Hard Fork can instead allow a block that older nodes reject. An activation mechanism helps coordinate a change; it neither guarantees everyone’s agreement nor replaces operators’ decisions about which software to use. [4]
Running your own Full Node lets you check received blocks instead of relying on a block explorer website. A node may know several branches: different continuations of a shared history. Among valid branches, it chooses by chainwork, the sum of the work credited to each block according to its mining difficulty. This is not a measurement of electricity actually consumed or simply a count of blocks. More work cannot excuse a rule violation. For nodes to reach the same result, they must apply the rules consistently even in unusual cases. A software bug can make them disagree about which blocks to accept. [4] [5]
A node may refuse to relay a transaction whose fee is too low. But if a miner includes it in a block and both transaction and block meet consensus rules, the node accepts the block. If a miner instead claims more than the allowed amount of new bitcoin, called the Block Subsidy, plus the transaction fees in the block, the node rejects the block even with valid Proof of Work. The distinction is the reason for rejection, not the miner’s reputation. [3] [1]
For the clearest picture, read this entry together with Full Node, Soft Fork, Proof of Work, Bitcoin Core, Bitcoin Script, Mempool. The reverse links also lead from 21 Million, Soft Fork, Hard Fork, BIP (Bitcoin Improvement Proposal).