Module 4 · The Bitcoin Machine / 4.7
The rules, and who can change them.
A constitution is a useful analogy—if we keep its limits in view.
Imagine a game played in many towns. Every town has a copy of the same rulebook.
One powerful player arrives with a newly printed rule: “My points count twice.” The paper is real. The other players still have to decide whether this is the game they agreed to play.
Rules first. A mechanism for agreeing on history.
Think of the consensus rules as part of a constitution: they define what is allowed. A payment must satisfy its spending conditions. An output cannot be spent twice in the accepted history. A block cannot claim too much new bitcoin.
But a constitution needs more than a list of forbidden acts. Participants also need a way to handle competing valid proposals. In Bitcoin, proof of work and the most-accumulated-work rule help nodes converge on one valid transaction history.
These are different jobs. Validity answers “Could this be accepted?” Chain selection answers “Which valid history do I follow?” You need both to understand consensus.
The analogy has limits. Bitcoin has no supreme court that interprets human intent, no universal voter register and no one-person-one-vote election. Software applies explicit checks. People outside the protocol debate what software ought to run.
Power is divided, but it is not equal.
Developers propose and review code. Miners propose blocks and influence which valid transactions get included. Node operators choose the rules they enforce. Users, businesses, custodians and markets influence which network they use and value.
No single developer can force every independent operator to install a new version. Nor can one person command the whole network by launching a million cheap nodes. Raw node count is not a vote that changes the rules.
Yet “nobody has total control” does not mean “nobody has power.” Large pools, widely used software, exchanges, hosting providers and communication channels can become pressure points. Independence is something to assess and maintain, not a slogan that solves every dispute.
Running a node can reduce reliance on someone else’s account of the chain. It does not guarantee that your preferred change will be adopted or that other people will value the same asset.
A proposal is not an amendment.
A Bitcoin Improvement Proposal, or BIP, describes an idea in a form people can inspect. Publication is not adoption. Review, implementation, deployment and actual use are separate steps.
A soft fork tightens validity rules in a way that old software can still regard the newly valid blocks as acceptable. Old nodes do not thereby enforce the new restriction themselves. Coordination still matters, and a poorly coordinated change can cause disruption.
A hard fork allows some behaviour that old rules reject. To follow those new rules, participants need compatible software. If groups continue to maintain incompatible histories, a lasting split can result; not every fork creates a viable second currency.
A shared rulebook is an analogy. Publication of an amendment alone does not establish adoption.
Bitcoin has changed before: SegWit and Taproot added capabilities without changing its supply schedule. Ethereum later changed from proof of work to proof of stake through a coordinated upgrade. That was a different network making a different choice.
The constitution picture helps you ask the right question: which rule is changing, who must act, and what happens to participants who disagree? It does not predict the social answer.
The idea to keep
Consensus combines validity rules with a way to select history. Governance is the human process of proposing and adopting changes to that arrangement. Decentralization spreads particular powers; it does not make influence disappear.