Nodes do not ask a central authority
When a node receives a block, it checks its proof of work, link to the previous block, transactions, signatures, double-spend prohibition, issuance limit and other consensus rules. The result does not depend on the sender's reputation or the number of nodes that relayed the block. An invalid block remains invalid even with strong miner support.
Consensus here describes a state in which independent nodes recognize the same chain after doing their own checks. It is neither an instant meeting nor agreement on every opinion. Nodes may briefly see different chain tips because messages propagate at finite speed.
Most accumulated work matters, not the largest block count
If two valid blocks appear at the same height, part of the network may initially build on one branch and part on the other. Once one valid branch accumulates more proof of work, nodes switch to it. Transactions from the abandoned branch may return to mempools or conflict with transactions in the winning branch.
The phrase longest chain is common, but the more precise criterion is greatest cumulative work among valid candidates. A branch with more blocks does not necessarily win if those blocks represent less required work. A node never chooses a branch it considers invalid.
- rules first determine which blocks are valid candidates
- accumulated proof of work selects the followed branch among valid candidates
- a temporary difference at the chain tip may be resolved by a reorganization
A rule change needs adoption, not an order
Developers can write new software but cannot remotely command every node to run it. Miners may signal or produce blocks under particular rules, but cannot force a node to accept a block its software rejects. Users, exchanges, merchants and other participants decide which software and coins they will use economically.
If old and new rules become incompatible and substantial groups persist with both, the network may split permanently. The technical terms soft fork and hard fork describe different compatibility properties, not automatic quality or legitimacy. Coordination without a central operator is both a benefit and a cost: unilateral change is difficult, but disputes can be slow to resolve.
Consensus does not provide instant absolute finality
A payment in the newest block can lose its confirmation during a reorganization. Each added layer of work makes reversal harder, but the protocol does not set one universal confirmation count that is safe for every value and threat. The recipient chooses a threshold based on value, risk and ability to wait.
Majority hash rate can increase the ability to censor or reorganize recent payments and attempt to double-spend the attacker's own coins. Under unchanged rules, however, it cannot create an arbitrary subsidy or spend somebody else's UTXO without the required authorization, because full nodes would reject that block.