Upgrading Bitcoin is a challenging process that requires consensus among stakeholders called a “Bitcoin Improvement Proposal” or BIP. They are complicated, cumbersome, and oftentimes the process lacks clarity. Informational BIPs may get passed relatively quickly, while Standard and Process BIPs could take years — if they are approved at all. This is quite different from traditional software upgrades, which are typically decided by a small group within a tech company with minimal concerns for user privacy. Traditional software upgrades are like car maintenance, straightforward and controlled by a single entity. Blockchain upgrades, however, resemble spaceship maintenance—complex, involving a diverse and decentralized group of stakeholders. Each proposed upgrade requires a massive majority consensus, making the process slow and potentially leading to different versions (forks) of the blockchain. Upgrading Bitcoin protocols is challenging because there is no central authority. Proposals must be reviewed and approved by the community, which often has conflicting opinions. For example, Segregated Witness (SegWit) proposal faced significant contention within the community, leading to a split and the creation of Bitcoin Cash in 2017. This decentralized decision-making process can be slow and contentious, sometimes resulting in network forks where the blockchain splits into separate chains. Despite these challenges, regular updates are necessary to enhance performance, security, and functionality. Bitcoin’s Taproot upgrade, which enhanced privacy and efficiency by implementing Schnorr signatures and Merkelized Abstract Syntax Trees (MAST), underwent a lengthy review and approval process before its activation in November 2021. Bitcoin Improvement Proposals (BIPs) A Bitcoin Improvement Proposal (BIP) is a standardized process for proposing changes or enhancements to the Bitcoin protocol. BIPs introduce new features, improve existing ones, or fix issues within the Bitcoin network. They serve as a formal mechanism for the Bitcoin community to discuss and reach consensus on changes. Bitcoin Improvement Proposals (BIPs) follow a specific format to ensure clarity and consistency. Each BIP includes sections such as the BIP number, title, author, status, type (Standards Track, Informational, or Process), and a detailed description of the proposal. This standardized format helps in organizing and evaluating proposals systematically, facilitating better understanding and discussion within the community. For example, BIP 141, which introduced Segregated Witness (SegWit), follows this structured format, detailing its objectives, technical specifications, and implications for the Bitcoin network. Types of BIPs There are three types of BIPs: Standards Track, Informational, and Process. Each is meant to encompass a different type of network upgrade.
-
Standards Track BIPs propose changes that directly affect the Bitcoin network protocol, block, or transaction validation. These are critical updates that can alter how the network operates. For instance, BIP 340, which proposed Schnorr Signatures, aimed to improve the efficiency and security of Bitcoin transactions by introducing a new signature algorithm. Another example is BIP 9, which introduced a new method for soft fork deployment using miner signaling
-
Informational BIPs provide guidelines, recommendations, or other information to the Bitcoin community. These do not propose changes to the protocol but offer valuable insights and best practices. For example, BIP 32 describes a method for hierarchical deterministic wallets, providing a framework for wallet management without altering the Bitcoin protocol itself
-
Process BIPs propose changes to the processes or procedures surrounding Bitcoin development. These do not affect the Bitcoin protocol directly but aim to improve the workflow and decision-making processes within the development community. An example is BIP 2, which outlines the standards and guidelines for writing BIPs, ensuring that proposals are well-structured and comprehensible Proposal Lifecycle Every BIP proposal is subject to the same process: submission of the initial draft, discussion, and finally a vote.
-
Draft: The initial stage where the proposal is written and shared for feedback. At this stage, the proposer drafts a detailed document outlining the proposed change, its rationale, and its potential impact on the network. This draft is then shared with the community for initial review. For example, BIP 148, a user-activated soft fork (UASF) proposal, began as a draft outlining the method to activate SegWit
-
Discussion: Once the draft is shared, it enters the discussion phase where the broader Bitcoin community reviews the proposal. Feedback is provided through various channels, including online forums, mailing lists, and developer meetings. This phase is crucial for refining the proposal and addressing any concerns. BIP 8, which proposed a change in the activation method for soft forks, underwent extensive discussion within the community before reaching consensus (Falkvinge).
-
Accepted/Rejected: Based on the community feedback and consensus, the proposal is either accepted or rejected. For a BIP to pass, the required percentage of stakeholders (typically miners; others may include developers, node operators, etc.) that need to signal their support can vary depending on the specific proposal and the method used for activation. However, a common threshold for soft fork proposals is 95% of blocks within a specified period—90% with the Speedy Trial Method.
-
Final: If accepted, the proposal is implemented and becomes part of the Bitcoin protocol. The final stage involves integrating the changes into the Bitcoin software and ensuring that the network adopts the new protocol rules. BIP 141 (SegWit) is a notable example of a proposal that successfully moved through all stages to become a part of the Bitcoin protocol. The passing of a BIP could lead to a consensus change. A consensus change in the context of Bitcoin refers to a modification in the rules governing the Bitcoin network that requires agreement from most participants (nodes) in the network. These changes can be either hard forks or soft forks .
-
Hard Forks: A hard fork is a radical change to the protocol that makes previously invalid blocks/transactions valid (or vice versa). It requires all nodes or users to upgrade to the latest version of the protocol software. If a significant portion of the community does not upgrade, it can lead to a permanent split, with one chain following the old rules and another chain following the new rules. An example is the split between Bitcoin (BTC) and Bitcoin Cash (BCH) in 2017.
-
Soft Forks: A soft fork is a backward-compatible upgrade, meaning that the new rules are a subset of the old rules. Nodes that have not upgraded to the new software can still recognize and validate transactions under the new rules, but they will not be able to take advantage of the new features or improvements. Segregated Witness is an example of a soft fork implemented in Bitcoin. Centralization and Decision-Making in Bitcoin Improvement Proposals (BIPs) Early on, decision-making regarding BIPs was primarily dominated by a small group of core developers. These developers played a significant role in proposing, discussing, and implementing changes to the Bitcoin protocol. This centralization of decision-making was partly due to the technical expertise required to understand and develop protocol improvements. Shift Towards Decentralization In recent years, there has been a noticeable shift towards more decentralized decision-making within the Bitcoin community. This change reflects a broader trend in the crypto space towards greater community involvement and consensus-driven processes.
-
Community Engagement: Increased participation from a diverse set of stakeholders, including miners, developers, users, and businesses, has led to a more democratic process for BIP discussions and implementations.
-
Core Developers’ Stance: As noted by Udi Wertheimer, founder of the “Taproot Wizards” and author of the BIP related to OP_CAT, current core developers are increasingly stepping back from direct involvement in the decision-making process, encouraging the community to reach consensus independently. This hands-off approach aims to empower the community and reduce the risk of centralization. Examples of this move towards Decentralization can be found in some of the more recent BIPs that have passed. During the SegWit implementation process, core developers such as Pieter Wuille and Gregory Maxwell provided the technical foundation but left the decision of activation to the miners and the broader community. The controversy and eventual user-activated soft fork (UASF) demonstrated the community’s role in reaching consensus independently. Another example can be found in the Taproot upgrade: core developers like Pieter Wuille and Anthony Towns contributed significantly to the code but did not dictate the activation method. Instead, they allowed the community to debate and decide between different activation mechanisms such as Speedy Trial or BIP-8, fostering a decentralized decision-making process. Bip Editors and Contributors The appointment of multiple BIP editors and contributors has significantly enhanced the BIP process, fostering greater transparency and decentralization. Historically, there’s been a single BIP editor, however, in recent years Luke Dash Jr., a prominent Bitcoin Core developer and current BIP Editor, expanded the team to better distribute the growing workload. Dash’s proposal to expand the editor team marked a key milestone in improving the governance of the BIP system. Recognizing the risks associated with centralized control, he advocated for the inclusion of new editors who could bring fresh perspectives, technical rigor, and strong ties to various segments of the Bitcoin community. This initiative not only reduced the potential bottleneck of relying on a single editor, while also ensuring that there was greater representation on the team.
The Speedy Trial Method The “Speedy Trial” method represents an innovative approach to activating BIPs in a maneer that balances efficiency with community consensus. This method was introduced as a response to the challenges of achieving timely network upgrades while avoiding prolonged debates and uncertainty that could undermine the stability of the network. The Speedy Trial process features a short signaling period, around 3 months, during which stakeholders signal their support for a proposed change by including specific flags in the blocks that are mined. The mechanism requires around 90% within a defined signaling period. Once the BIP is accepted, there is a waiting period before it is implemented so the changes have time to be made. If the threshold isn’t met, then it is considered rejected and dropped without activation.
The Importance of BIP 2 BIP 2, titled "BIP Purpose and Guidelines," is one of the foundational Bitcoin Improvement Proposals, establishing the structure and processes for how future BIPs are created, discussed, and implemented. Introduced by Amir Taaki in 2011, BIP 2 formalized the framework for Bitcoin’s open and decentralized development process, ensuring consistency and transparency in protocol upgrades. The importance of BIP 2 lies in its definition of the roles, responsibilities, and lifecycle of a BIP. It introduced the concept of proposal stages—Draft, Proposed, and Final—providing clear guidelines for how a BIP progresses from an idea to potential adoption. It also outlined the responsibilities of BIP authors and editors, specifying how proposals should be formatted, documented, and communicated to the community. By creating a standardized framework, BIP 2 ensured that Bitcoin’s development could scale alongside its growing community and technological complexity. This foundational structure has enabled the effective review, debate, and implementation of significant changes to Bitcoin, fostering collaboration and maintaining decentralization in the decision-making process. As a result, BIP 2 has played a critical role in preserving Bitcoin’s integrity while facilitating its evolution.