Consensus is referenced in the last sentence of the Bitcoin paper.
Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
Consensus refers to the agreed definition of block validity. From this we derive the term “consensus rules” which are the formalization of the agreement. A person uses the rules to determine whether a received payment is valid.
Conflicts between competing valid blocks are resolved by a proof of greater work. A majority “vote” by processing power controls the long chain and thereby has control over double spends.
As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers.
Rule Changes (Forks)
Changes to these rules are referred to as hard forks and soft forks. In the case of a hard fork, a new transaction may be valid despite not conforming to the original rules. In the case of a soft fork, new transactions are valid under the original rules. In other words, holders of a money have not agreed to a hard fork but inherently accept a soft fork.
A soft fork can be enforced by simple majority of processing power. In other words a soft fork isn’t actually a change in consensus among people, it’s a change that flows from the people controlling a majority of processing power.
The original paper does not articulate a distinction between these rules, loosely referring to both scenarios as consensus. However it is an error to refer to soft fork rules as “consensus rules”. These are “majority rules” with the caveat that it is majority of processing power not majority of people. Bitcoin’s disruption social security guards against soft forks by less than a majority of people.
A hard fork requires that all participating people change rules. If a person fails to accept a change in the rules he can spend his existing money with others who have accepted the change. However he will reject new money that doesn’t conform to his unchanged rules. Widespread rejection of the money would result in failure of a hard fork. When people generally refuse to accept a new money it will not be able to fund its own security.
The consensus to be reached in acceptance of a hard fork is among those holding the money. Only those who hold the money have something at stake. However it is not actually savers who protect the money against hard forks, it is those validating money received in trade.
Anything about the money can be changed in a hard fork and any change can constitute a taking from a saver. Hard-forking a person’s savings without their agreement is unethical and harms the necessary predictability of the money. Bitcoin’s economic social security guards against hard forks that lack consensus among stakeholders.
Software developers either sell or donate software to the community. Agreement among them is not a consensus referred to in the original paper, nor is it an aspect of Bitcoin. They contribute neither to the majority nor the consensus. They do not contribute processing power toward the majority, do not contribute validation of their own trades in defense of the consensus, and are not stakeholders in the consensus.