Who Controls Bitcoin?Understanding the BIP Governance System
Discover how Bitcoin evolves without central leadership through BIPs. Explore the governance system that enables the world's largest cryptocurrency to adapt and improve.
If Satoshi is gone and no one is in charge of Bitcoin, how does it get better? How are bugs fixed, features added, or the protocol upgraded? It seems like a paradox. A leaderless, decentralised system worth trillions shouldn't be able to evolve, yet it does.
The answer to this governance puzzle lies in a formal, methodical and often controversial process known as the Bitcoin Improvement Proposal, or BIP.

To truly understand Bitcoin's resilience and future, one must understand the BIP process. This article will demystify BIPs, explore their historical impact, explain how anyone can participate if they are technically minded, and show why this foundational process is critical for the future of Bitcoin and its Layer 2 (L2) solutions such as Bitfinity.

What is a Bitcoin Improvement Proposal (BIP)?
At its most fundamental level, a BIP is a formal design document. It is a proposal, a historical record, a technical specification and a battleground for ideas all rolled into one.
Before the BIP process was formalised by developer Amir Taaki in [BIP 0001] (2011), discussions about changing Bitcoin were scattered across forum posts and chat logs. This was chaotic and inefficient. A great idea could be lost in the noise, and it was difficult to track the history and rationale behind changes.
The BIP process itself was heavily inspired by the Python Enhancement Proposal (PEP) process, which governs the evolution of the Python programming language.
The Internet was built by a loose confederation of academics and engineers who needed to agree on standards (like TCP/IP, defined in [RFC 793]) without a central authority dictating terms. Their motto, famously articulated by David Clark, was "rough consensus and running code".
This ethos is alive and well in Bitcoin.
- Rough Consensus: A change does not happen because of a 51% vote. It happens when the vast majority of relevant technical experts and stakeholders agree.
- Running Code: An idea is just an idea until it is expressed in code that can be tested, verified and run. A BIP is often accompanied by a "Reference Implementation", proving that the proposal is not just theoretical but practically achievable.
The Three Types of BIPs
Understanding the three categories of BIPs is crucial to grasping the different ways Bitcoin can evolve.
Standards Track BIPs
These are the most consequential BIPs, as they propose direct changes to the Bitcoin protocol that all full nodes must understand and enforce. Failure to agree on these rules can literally split the network and the currency in two.
We see the Consensus-Critical (Forks), which are changes to the validation rules that every full node follows.
- A Soft Fork is a backwards-compatible change. It tightens the rules, meaning blocks created by upgraded nodes are still seen as valid by old nodes. However, blocks created by old nodes might be seen as invalid by new nodes if they violate the new, stricter rules.
- A Hard Fork is a non-backwards-compatible change. It loosens the rules or fundamentally alters the block structure in a way that makes new blocks invalid to old nodes. This requires all participants in the network to upgrade simultaneously. If a significant portion of the network refuses to upgrade, the blockchain permanently splits, creating two different assets (e.g. Bitcoin and Bitcoin Cash).

Informational BIPs
These BIPs do not propose any changes to the Bitcoin software. Instead, they provide information, context or general guidelines to the community. They are not enforceable at the protocol level, but they can become incredibly influential de facto standards through utility and network effects.
The most famous Informational BIP is almost certainly [BIP 39], which defines the standard for generating a 12 or 24-word mnemonic phrase (seed phrase) to back up and restore a crypto wallet. It is not a consensus rule; a wallet could use a different system, but its simplicity led to near-universal adoption.
Process BIPs
This is the most meta category. Process BIPs describe or propose changes to processes surrounding Bitcoin. They are the rules about how the rules are made, debated and implemented.
The foundational Process BIPs are:
- [BIP 1]: Defines what a BIP is, its purpose and the role of the BIP author and editors.
- [BIP 2]: Outlines the specific mechanics, formatting and lifecycle of a BIP (Draft → Proposed → Final/Rejected).
These BIPs ensure that the governance process itself is transparent and well-defined. If someone wants to change how BIPs work, they must submit a new Process BIP and convince the community, just like any other change.
The list of BIP editors is maintained within BIP 1 itself. This means that adding or removing an editor requires a change to a Process BIP. As of late 2023, the only active editor listed is Luke Dashjr, a long-time Bitcoin Core developer who was involved in a recent debate around Bitcoin Knots.

BIP Lifecycle
Proposing a change to Bitcoin is open to anyone, but the path from idea to activation is a trial by fire designed to ensure only the most robust and widely supported ideas survive.
- The Idea and Socialisation: An idea is not simply thrown into a GitHub repository. It begins with socialisation. The "champion" of the idea first brings it to the community's technical forums, primarily the highly respected bitcoin-dev mailing and sometimes IRC channels. Here, the idea is subjected to initial critique. Is it useful? Is it secure? Is it redundant?
- Drafting the Proposal: If the idea survives initial scrutiny, the champion drafts a formal BIP following the strict format outlined in BIP 2. This document is incredibly detailed, including sections for an Abstract (summary), Motivation (the "why"), a precise technical Specification, Rationale (design choices) and analysis of Backwards Compatibility.
A BIP without a working "Reference Implementation" (sample code) is often dismissed as vaporware. The community ethos of "rough consensus and running code" means a practical, testable implementation is essential to be taken seriously.
- Getting a Number: he author submits the draft as a pull request to the official BIPs GitHub repository. The BIP editors review it for formatting, clarity and completeness. If it passes muster, they assign it a BIP number and merge it into the repository. The proposal is now an official Draft.
Having one person (historically, Luke Dashjr) responsible for a key administrative step seems centralised. However, this perception changes when you understand the extremely limited scope and power of the BIP editor's role. They are more like a librarian or an administrative clerk.
- Peer Review & Iteration: The draft is now open to intense, public peer review from developers, cryptographers, academics and engineers worldwide. The champion must defend their proposal, answer tough questions and often revise the BIP dozens of times.
- Implementation: As a BIP gains overwhelming support, developers will begin writing the actual code to implement it in clients like Bitcoin Core.
- Activation: Once the code is merged into a client release, it is not yet active. For major changes (soft forks), an activation mechanism is required. A common method is miner signalling, where a high threshold of miners (e.g. 90-95% of blocks in a given period) must signal their readiness for the new rules.

Who Really Decides?
his is the most misunderstood part of Bitcoin. A change is adopted not because a majority wants it, but because an overwhelming consensus of stakeholders agrees to run the code that enforces it. A controversial proposal that only has 51% support is considered a failure.
Developers are the technical stewards who write, review and merge code. Their consensus is critical for a proposal's technical viability. However, they are a check, not a ruler—they cannot force anyone to run their software.
Miners (Economic Nodes) provide the network's security (hashrate). Their signalling is often the trigger for activation of an upgrade. However, they are economically rational actors influenced by powerful incentives. Mining blocks that the rest of the network rejects is a quick way to go bankrupt, so they are heavily incentivised to follow the rules valued by the economic majority.
Full Node Operators (The Economic Majority) are the ultimate check and balance. This group is not uniform; it includes every individual, merchant and exchange running a full node, each independently validating every transaction and block against their own copy of the rules.
While an individual running a node exercises their sovereignty, large economic players like exchanges wield immense influence within this group. They act as "economic heavyweights" because they hold funds for millions of users, and their choice of software effectively acts as a proxy vote for the economic weight of their entire customer base.
Their most significant power is the ability to grant legitimacy and liquidity. If developers and miners push a change, users can simply refuse to upgrade. The power of exchanges was demonstrated during the 2017 fork that created Bitcoin Cash (BCH). The public support and decision by major exchanges like Bitfinex to list BCH as a tradable asset instantly gave the new chain a market price and economic reality, which in turn incentivised miners to secure it. Without this support from major economic nodes, the fork would have likely failed.
Ultimately, consensus is discovered, not decreed. The power rests with the economic majority who choose which rules to enforce.
Landmark BIPs That Shaped Bitcoin
- BIP 32 and 39: The Foundation of Modern Wallets
These BIPs created the standard for using a single 12 or 24-word backup to generate and restore all of a wallet's keys, as mentioned above. - BIP 16: Pay-to-Script-Hash (P2SH)
This upgrade made complex transactions like multi-signature security practical. - BIP 65 and 112: Timelocks (CLTV and CSV)
These introduced timelocks, enabling funds to be locked until a future time or for a set duration. Essential for payment channels and the first L2 (Lightning Network). - BIP 141: Segregated Witness (SegWit)
Building on that foundation, BIP 141 (SegWit) tackled scaling and functionality. By restructuring transaction data, it made space for more transactions in each block. - BIPs 340-342: The Taproot Upgrade
The Taproot upgrade brought major improvements to privacy and smart contract efficiency and enables complex operations.
Why BIPs Matter for Layer 2 (L2) Solutions
Bitfinity understands that Bitcoin's strength lies in its deliberate and secure evolution, governed by the formal BIP process.
We built Bitfinity to address this exact opportunity. Instead of attempting to alter Bitcoin's core protocol, we embrace its stability and serve as a next-generation Layer 2, providing a high-performance EVM that delivers 1000 TPS and advanced smart contract functionality without requiring any changes to the main chain.
For instance, our ability to support Ordinals and Runes is built directly upon the witness data structure created by Segregated Witness (BIP 141).
Furthermore, our future roadmap to issue Taproot transactions is designed to harness the efficiency and privacy gains from BIPs 340-342. In essence, we use the tools forged by that process to unlock its full potential, bringing the vast and familiar EVM development environment to Bitcoin's ecosystem.

Connect with Bitfinity Network
Bitfinity Wallet | Bitfinity Network | Twitter | Telegram | Discord | Github

*Important Disclaimer: The information provided on this website is for general informational purposes only and should not be considered financial or investment advice. While we strive for accuracy, Bitfinity makes no representations or warranties regarding the completeness, accuracy, or reliability of the content and is not responsible for any errors or omissions, or for any outcomes resulting from the use of this information. The content may include opinions and forward-looking statements that involve risks and uncertainties, and any reliance on this information is at your own risk.
External links are provided for convenience, and we recommend verifying information before taking any action. Bitfinity is not liable for any direct or indirect losses or damages arising from the use of this information.


Comments ()