How does a protocol with no central authority evolve? Part of what makes the question hard is that Bitcoin uses the word "consensus" for three different things: the rules enforced by software, the social threshold for changing those rules, and the looser sense that most participants agree (Remark 33.2). Much of Bitcoin's governance conflict is conflict over which meaning is being invoked. The process is often called "rough consensus and running code," a phrase borrowed from the IETF (Definition 33.4); in practice, durable consensus-rule changes require at least passive acceptance across the economically relevant parts of the network. This chapter examines Bitcoin's governance model: the BIP process, the dynamics of soft fork activation, and the specification problem that underlies both.
33.1 The Stakeholders
Definition 33.1 (Bitcoin Stakeholder Groups)
Bitcoin governance involves multiple constituencies:
- Developers: Write code, propose changes, review
- Node operators: Run full nodes, enforce rules
- Miners: Produce blocks, signal for upgrades
- Users: Hold and transact in BTC
- Businesses: Exchanges, wallets, payment processors
Remark 33.1 (Power Distribution)
No single stakeholder group can unilaterally change Bitcoin:
- Developers: Write code but cannot force adoption
- Miners: Produce blocks but users can reject them
- Users: Can reject rules by choosing validating software, but the power is effective only when coordinated with economically meaningful counterparties
- Economic nodes: Exchanges, custodians, merchants, and payment processors, whose validation choices determine which chain carries market liquidity
- Businesses: Influence but do not control rule changes
Durable consensus-rule changes require at least passive acceptance across the economically relevant parts of the network.
33.2 The BIP Process
Definition 33.2 (Bitcoin Improvement Proposal)
A BIP is a design document describing:
- A new feature or process for Bitcoin
- Technical specification
- Rationale and motivation
BIPs are numbered and tracked in the bitcoin/bips repository.
Definition 33.3 (BIP Types)
Under BIP-3 (the 2025 revision of the process), BIPs have three types:
Specification: Changes affecting implementations (consensus rules, peer services, API/RPC, applications), called "Standards Track" under the older BIP-2 process
Informational: General guidelines or information
Process: Changes to BIP process itself
The bips repository is curated by a small group of BIP editors, who assign numbers and judge whether a submission meets the process criteria; under BIP-3, new editors are added by agreement of the existing ones. The editors' jurisdiction ends at the catalog: a BIP number is neither necessary nor sufficient for deployment, and nothing prevents code from shipping without one. The catalog binds no one, which is precisely why disputes over what it admits are usually disputes about something else.
Example 33.1 (Notable BIPs)
| BIP | Title | Status |
|---|---|---|
| 32 | HD Wallets | Deployed |
| 39 | Mnemonic Seed Phrases | Deployed |
| 141 | Segregated Witness | Deployed |
| 341 | Taproot | Deployed |
| 119 | OP_CHECKTEMPLATEVERIFY | Draft |
33.3 Social Consensus Formation
Beyond technical specification, controversial changes require social consensus.
Remark 33.2 (Three Senses of "Consensus")
Before going further, a warning about the chapter's central word. In Bitcoin discourse "consensus" carries three incompatible meanings, and this book has already used two of them:
- Consensus rules (the technical sense): the validation predicate of Definition 13.18, the rules of Definition 16.1 and Appendix D. A precise, falsifiable property of software.
- Near-unanimity (the social sense): no significant stakeholder objects. This is what "rough consensus" (Definition 33.4 below) approximates.
- General agreement (the loose sense): most participants, perhaps weighted by some unstated notion of expertise or stake, are in favor.
The ambiguity is exploitable. The claim "we don't have consensus" can block a proposal while committing to nothing: it may mean the rules forbid it (sense 1, checkable), that identified stakeholders object (sense 2, answerable), or merely that someone, somewhere disagrees (sense 3, unfalsifiable). A speaker who never specifies which sense is meant cannot be refuted, which gives the unqualified word much of its rhetorical force. The remedy is terminological discipline: say consensus rules for sense 1, non-contentious for sense 2, and general agreement for sense 3. When someone asserts that consensus exists or is lacking, the first question is which kind is meant. This book uses "consensus" unqualified only in the technical sense.
Definition 33.4 (Rough Consensus)
Rough consensus is a term of art from the IETF (RFC 7282): a working-group chair declares rough consensus when the objections raised have been addressed on the record, answered rather than outvoted, even if not everyone is persuaded. The IETF can operate this way because it is an organization, with working groups, chairs accountable for the declaration, and an appeals path.
Bitcoin's use of the phrase is more radical. There is no chair to declare consensus, no procedure obliging anyone to answer an objection, and no appeal, because the second half of the slogan does all of the work. Running code either attracts the economy or it does not: deployment is the declaration, adoption is the minutes, and the fork is the appeal. Whether that is a stronger discipline than the IETF's or a weaker one is a question that each of this chapter's case studies (Section 33.7) puts to the record.
Remark 33.3 (Social Consensus Signals)
Social consensus is observed through:
- Mailing list discussion: bitcoin-dev list debates
- Implementation: Multiple independent implementations
- Testing: Deployment on testnet/signet
- Support statements: Companies and developers
- Futures markets: Price signals for contentious forks (where liquid markets exist)
Each of these signals is read off a venue, and every venue has an operator: mailing lists are moderated, conference programs are curated, and platform feeds are ranked. An observation of social consensus therefore inherits the admission rules of the channel through which it was observed.
Remark 33.4 (The "Ossification" Debate)
A growing tension in Bitcoin governance:
- Pro-change (common among application and Layer 2 developers): Bitcoin needs features (covenants, etc.) to remain competitive
- Pro-stability (common among long-term holders and some senior contributors): Changes risk breaking what works; ossification protects value
- Middle ground: Only changes with near-unanimous support
Participants across the debate describe the threshold for activating changes as having risen since 2017 (four years between SegWit and Taproot; none since).
33.4 Soft Fork Activation
Agreement on a technical design (a working BIP) does not by itself change the network: an activation mechanism is required.
Definition 33.5 (Activation Methods)
- Flag Day: Fixed block height or date
- BIP-9: Miner signaling with timeout
- BIP-8: Signaling with optional mandatory activation
- Speedy Trial: Fast signaling, delayed activation
Remark 33.5 (MASF vs UASF)
Two philosophical approaches to activation:
Miner Activated Soft Fork (MASF):
- Miners signal readiness
- Activation at threshold (e.g., 95%)
- Risk: miners can block upgrades
User Activated Soft Fork (UASF):
- Users set flag day activation
- Miners must comply or risk invalid blocks
- Risk: chain split if miners resist
Example 33.2 (SegWit Activation)
SegWit activation combined both approaches:
- BIP-9 signaling deployed (2016)
- Signaling stalled at ~30% for months
- BIP-148 (UASF) announced August 1, 2017 deadline
- Miner signaling rose rapidly in July 2017, concurrent with both the BIP-148 deadline and the New York Agreement's BIP-91 deployment; the relative contribution of each remains debated
- 95% reached; SegWit activated August 2017
33.5 Bitcoin Core's Role
Definition 33.6 (Bitcoin Core)
Bitcoin Core is the reference implementation:
- Descended from Satoshi's original code
- Open source, permissively licensed
As of 2025, Bitcoin Core is the most widely run full-node implementation by listening-node share. Its development involves a handful of maintainers with merge access, a few dozen regular contributors, and over a hundred occasional contributors in a typical year. Merge access is granted, and occasionally relinquished, by agreement among the existing maintainers; there is no external appointment, no term, and no election. The check on the maintainer set is the same as the check on the code itself: the repository can be forked by anyone, and the name "Bitcoin Core" attaches to whichever repository the economy continues to treat as canonical.
Most full-time contributors are paid not by the project, which has no treasury, but by grants from a small number of nonprofit and corporate sponsors, each of which decides independently whom to fund, for what work, and for how long. No protocol mechanism allocates these funds and no stakeholder vote reviews the allocations; the grants, like the commits they pay for, are public.
Remark 33.6 (The Developer-Power Critique)
Critics, from legal scholars such as Angela Walch to veterans of the block size war, argue that the formal power map of Remark 33.1 understates developer influence. Maintainers control commit access to the software the economy runs by default, and, they argue, defaults are sticky: "users can reject a release" is true in principle but rarely exercised. On this account, agenda setting (which proposals receive review at all) is itself a form of power, and contributor funding is concentrated among a handful of sponsors. On this view, Section 33.9's code-as-specification argument cuts against the standard rebuttal (Remark 33.7) rather than for it: if the rules are the code, those who write the code write the rules. Walch presses the point furthest, arguing that core developers function as de facto fiduciaries, exercising trusted power without accountability. The rebuttals follow.
Remark 33.7 (Core is Not Bitcoin)
The standard rebuttal holds that Bitcoin Core has significant influence but not control: users can run alternative implementations, fork the code, or reject a release, and core contributors cannot unilaterally change the consensus rules. The rejection option is not merely theoretical: forks of Core carrying contested consensus changes (the clients of Examples 27.1–27.3) failed to attract economic adoption despite substantial miner and business support, and the 2025 relay-policy migration (Example 33.6) shows node operators switching implementations over a default.
Remark 33.8 (Core Development Process)
Bitcoin Core changes require:
- Pull request with clear rationale
- Review by multiple contributors
- Testing and QA
- Concept ACK → Approach ACK → Code review ACK
- Merge by maintainer after sufficient review
Consensus changes require much more scrutiny than other PRs.
The Release Pipeline
Between the repository and the network sits one further mechanism: releases are built reproducibly (the Guix build system), so that anyone can compile the source and verify that the published binaries match it, and release binaries are signed by multiple parties whose keys are public. Verification is open to anyone; it is one of the few checks in this chapter that requires trusting no group at all, only performing the check.
33.6 Philosophical Foundations
Definition 33.7 (Bitcoin Maximalism)
The philosophical position that:
- Bitcoin's core properties should be preserved above all
- Decentralization and censorship resistance are paramount
- Changes should be minimal and conservative
- Alternative cryptocurrencies are inferior or unnecessary
Properties Bitcoin Governance Tends to Protect
Observation across the episodes of this chapter: Bitcoin governance tends to protect a small set of properties:
- 21 million cap: Fixed supply, no inflation
- Censorship resistance: Anyone can transact
- Permissionless: No gatekeepers
- Decentralized: No single point of control
- Sound money: Predictable monetary policy
Remark 33.9 (Schelling Point Preservation)
Bitcoin's value partially derives from being a Schelling point:
- The default choice for "cryptocurrency"
- The coordination point for sound money
- Changes risk disrupting this coordination
This creates strong pressure toward conservatism.
33.7 Case Studies in Governance
33.7.1 The Block Size War (2015-2017)
Example 33.3 (Block Size Debate)
Widely regarded as Bitcoin's formative governance crisis:
- Issue: How to scale Bitcoin (blocks vs layers)
- Camps: Big blockers vs small blockers
- Resolution: SegWit activated; the big-block side forked to create Bitcoin Cash
- Lesson widely drawn: Users, not just miners, determine which rules prevail, though some observers attribute the outcome more narrowly to exchanges and large economic nodes, and note that the UASF ultimatum was never tested against actual miner resistance
33.7.2 Taproot Activation (2020-2021)
Example 33.4 (Taproot)
A smoother activation process:
- Substance: Broad agreement on the design's benefits
- Debate: Activation method (LOT=true vs LOT=false)
- Resolution: Speedy Trial compromise
- Result: 90% signaling, activated November 2021
33.7.3 Ordinals/Inscriptions (2023)
Example 33.5 (Ordinals Controversy)
Emergent use case causing debate:
- Innovation: NFT-like assets on Bitcoin
- Criticism: Spam, increased fees, not the intended use
- Defense: Permissionless use, valid transactions
- Outcome: No general agreement to filter emerged; default relay policy was unchanged (see Section 33.7.4 for the 2025 sequel)
33.7.4 The Relay-Policy Dispute (2025)
Example 33.6 (The OP_RETURN Default)
In 2025 a dispute over Bitcoin Core's default data-carrier policy, the relay limit on OP_RETURN payloads (Section 11.9, Appendix D.6), became, by common description on both sides, the most contentious policy dispute since the block size war. One side argued that relay defaults should track what miners demonstrably include, since a filter that no longer predicts confirmation only degrades fee estimation and pushes transactions to private submission channels; the other argued that filters raise the cost and friction of data embedding and protect node operators' resources, and that defaults are normative whatever their direct effect on confirmation: relaxing them signaled endorsement of non-monetary data on the chain. A substantial minority of reachable listening nodes switched to an alternative implementation with stricter defaults; how much weight that signal deserved was itself contested, since reachable-node counts are inflatable and do not measure economic activity.
The book's apparatus classifies the episode without adjudicating it. The disputed rules are policy, not consensus (Definition 16.2): no setting of them can split the chain (Appendix D.6), and both sides' blocks remained valid to all. Claims that one side or the other "lacked consensus" exhibited precisely the ambiguity of Remark 33.2: the rules permitted both behaviors (sense 1), while neither near-unanimity (sense 2) nor general agreement (sense 3) existed for either default. And the migration of operators between implementations was the client diversity trade-off of Remark 33.13 operating in real time: an exercise of the exit option that is harmless at the policy layer but would be a chain split at the consensus layer. What the episode demonstrates is that defaults are a governance surface even when they govern nothing consensus-critical: the fight was over what Bitcoin is for, conducted in the only venue available.
33.8 Future Governance Challenges
Remark 33.10 (Open Questions)
Bitcoin governance faces unresolved challenges:
- Covenant activation: CTV/CAT debate ongoing
- Developer funding: How to sustain contributors
- Quantum resistance: Future necessity, timing unclear
- Fee market: Long-term security budget
- Ossification: When/if to "freeze" the protocol
Remark 33.11 (Governance Evolution)
Bitcoin's governance has evolved:
- 2009-2014: Satoshi-led, then core developers
- 2015-2017: Contested, stakeholder conflict
- 2017-present: Higher bar for changes after the contested SegWit activation
- Future: Contested (Remark 33.4)
33.9 The Specification Problem
Every governance question in this chapter presupposes that there is a well-defined thing being governed: the consensus rules. But where, exactly, do those rules live? Bitcoin has no normative specification. There is no document whose text is authoritative the way a constitution or an IETF standard is. What exists is software—above all Bitcoin Core—whose behavior is, in practice, the definition of validity.
Remark 33.12 (Code as Specification)
Section 13.10 defined validation as a pure predicate V(C, B). The specification problem is that no canonical statement of V exists apart from implementations of it. The BIPs describe individual rule changes, but no BIP, and no combination of BIPs, describes the complete predicate; large parts of it (the original rules, accumulated bug-for-bug behaviors, serialization edge cases) are documented nowhere except in code. The practical consequence: "valid" means "accepted by the software the economy runs," and a consensus bug, once economically relied upon, can become indistinguishable from a rule.
Example 33.7 (March 2013: A Specification Failure)
Chapters 36 and 37 treat the March 2013 fork as an accidental chain split. We reread it here as a statement about specification. Bitcoin Core 0.7 stored the block index in Berkeley DB, which enforces a configurable limit on the number of simultaneously held locks. A sufficiently large block exceeded that limit on 0.7 nodes, which therefore rejected it, while 0.8 nodes, using LevelDB, accepted it. The network split for 24 blocks.
No one had written the rule "a block must not require more than N Berkeley DB page locks," and no one would have endorsed it. Yet it was, operationally, part of V: an unwritten, environment-dependent validation rule violating the determinism requirement of Definition 13.18. The episode shows that the consensus rules are whatever the deployed software does, including the parts nobody knows about.
Remark 33.13 (The Client Diversity Dilemma)
The specification problem shapes the debate over implementation diversity. With a single dominant implementation, its bugs are uniform: everyone accepts and rejects the same blocks, so latent rule-defects do not split the network, but the project inherits a monoculture's fragility and concentrates de facto rule-setting power (Section 33.5). With many independent implementations, no single codebase defines the rules, but any disagreement between them, however obscure, is a chain split waiting for an adversary to trigger it. Without an authoritative specification to converge on, diversity trades one systemic risk for another.
Remark 33.14 (Toward Executable Specifications)
The emerging response is to make the specification executable:
a statement of V precise enough to run, so that
"spec" and "implementation" cannot drift apart. Efforts span a spectrum.
Bitcoin Core's libbitcoinkernel project extracts the consensus
engine from the rest of the node, so that one well-reviewed artifact can
serve many clients. Declarative approaches, such as the Hornet DSL
(Sharp, 2025), go further, restating the validation pipeline of
Definition 13.19 as pure, deterministic, height-tagged rule functions with
no side effects, verified against existing implementations by large-scale
differential testing rather than formal proof. Whether any such artifact
ever becomes normative is itself a governance question: a
specification only specifies if the economy treats divergence from it as
a bug rather than a rule change.
Appendix D collects the consensus rule catalog that any such specification must capture.
Exercises
Exercise 33.1
Research the "LOT=true" vs "LOT=false" debate for Taproot activation. What were the arguments on each side? How was the disagreement resolved?
Exercise 33.2
Model Bitcoin governance as a game theory problem. What are the payoffs for different stakeholder groups in supporting vs opposing a change?
Exercise 33.3
Analyze the claim "Bitcoin Core developers control Bitcoin." What evidence supports or refutes this? Consider the block size war.
Exercise 33.4
Design a mechanism for measuring social consensus on protocol changes. What metrics would you use? What are the limitations?
Exercise 33.5
Compare Bitcoin's governance to other open-source projects (Linux, Ethereum, etc.). What distinguishes Bitcoin's governance from each?