TL;DR: Bitcoin upgrades follow a rigorous, multi-stage process: anyone can propose a change through a Bitcoin Improvement Proposal (BIP), developers review code through pull requests on GitHub, and consensus-level changes require overwhelming network agreement before activation. The process is deliberate by design because Bitcoin secures over $1.3 trillion in value, and a single bug could be catastrophic.
A Bitcoin upgrade is any change to the Bitcoin protocol or its reference implementation, Bitcoin Core. Upgrades range from minor performance improvements to consensus-level changes that alter how the network validates transactions and blocks. Every upgrade passes through a formal proposal process, extensive peer review, and voluntary adoption by node operators across the network.
Bitcoin Improvement Proposals (BIPs)
Every significant change to Bitcoin starts with a Bitcoin Improvement Proposal, or BIP. The BIP process, modeled after Python's Enhancement Proposal (PEP) system, provides a structured way for anyone to propose, discuss, and document changes to the Bitcoin protocol.
BIP 1, authored by Amir Taaki in 2011, established the format. BIP 2, authored by Luke Dashjr in 2016, refined it. Anyone can write a BIP. There is no gatekeeping committee, no corporate approval chain. A BIP is a technical design document that describes a proposed change, its rationale, and its specification in enough detail for independent implementation.
Types of BIPs
BIPs fall into three categories:
- Standards Track: Changes that affect the Bitcoin protocol itself, including consensus rules, network behavior, and transaction formats. These are the highest-stakes proposals because they define how Bitcoin works at its core. Examples: BIP 141 (SegWit), BIP 340 (Schnorr signatures).
- Informational: Design guidelines, general information, or explanations that don't propose new features. These help the community understand existing behavior or coordinate on best practices.
- Process: Changes to the procedures and decision-making around Bitcoin development itself. BIP 2 (the BIP process guidelines) is itself a Process BIP.
From Idea to BIP
The lifecycle of a BIP typically follows this path:
- Draft: The author writes a proposal following the BIP format and submits it to the bitcoin-dev mailing list for discussion.
- Discussion: Developers, researchers, and community members critique the proposal, identify edge cases, and suggest improvements. This stage can last months or years.
- Accepted: For Standards Track BIPs, acceptance means the technical community broadly agrees on the specification. Acceptance does not mean activation.
- Implementation: Developers write the actual code. The implementation may differ from the original BIP author's vision based on what review reveals.
- Activation: For consensus changes, the code must be deployed and activated by the network. This is a separate, distinct step from implementation.
The Code Review Process
Bitcoin Core, the reference implementation of the Bitcoin protocol, is an open-source project hosted on GitHub. Changes to the codebase go through what is widely considered the most rigorous code review process in open-source software.
Pull Requests
A pull request (PR) is a proposed code change submitted to the Bitcoin Core repository. Any developer can open a PR, but getting one merged requires passing through layers of review that would be unusual in most software projects.
Each PR undergoes automated testing, then manual review by multiple experienced developers. The review process has no fixed timeline. A simple refactoring might take weeks. A consensus-critical change might take months or years. The codebase does not operate on shipping deadlines.
Review Terminology
Bitcoin Core uses a specific vocabulary for code review that reflects the depth expected at each stage:
| Review Type | Meaning |
|---|---|
| Concept ACK | The reviewer agrees with the goal of the change. "Yes, this problem should be solved, and this is a reasonable direction." No code has been reviewed yet. |
| Approach ACK | The reviewer agrees with the implementation strategy. "The way you've chosen to solve this makes sense." The reviewer has studied the design but may not have read every line. |
| Code Review ACK | The reviewer has read the code line by line, tested it, and approves the change for merging. This is the strongest form of approval. |
| NACK | The reviewer disagrees with the change and explains why. A single well-reasoned NACK from an experienced developer can block a PR indefinitely if the concern is valid. |
| Tested ACK | The reviewer has built the code, run tests, and verified that the change works as described. |
This layered review system means a PR can have broad conceptual support but still be blocked on implementation details. The process privileges correctness over speed.
Why the Review Culture Matters
The review culture is the security model for the codebase itself. Bitcoin has no corporate security team or QA department. The people who review code are often the same people who write it, and they hold each other to a standard where a single overlooked edge case could put billions of dollars at risk.
This culture has a practical effect: the rate of critical bugs in Bitcoin Core is remarkably low for a codebase that has been in continuous production since 2009. The tradeoff is speed. Features that would ship in weeks at a typical software company take months or years in Bitcoin Core.
Consensus Changes vs. Non-Consensus Changes
Not all changes to Bitcoin Core carry the same weight. The distinction between consensus changes and non-consensus changes is fundamental to understanding why some upgrades happen quietly and others become years-long debates.
Consensus Changes
Consensus changes alter the rules that determine whether a block or transaction is valid. Every node on the network must agree on these rules, or the network splits. Examples include new transaction types, changes to block size limits, and new signature verification rules.
Because consensus changes affect every participant in the network, they are extraordinarily rare. Bitcoin has had only a handful of consensus-level upgrades in its entire history. Each one required years of discussion, development, and testing before activation.
Non-Consensus Changes
Non-consensus changes include performance improvements, wallet features, peer-to-peer networking optimizations, user interface updates, and code refactoring. These changes do not alter the fundamental rules of what makes a valid block or transaction. A node running older software will still agree with a node running newer software on the state of the blockchain.
Non-consensus changes are more frequent and less contentious. They still go through rigorous review, but they do not require network-wide coordination for deployment.
Soft Forks and Hard Forks
When a consensus change does happen, it takes one of two forms of fork: a soft fork or a hard fork. The difference determines backward compatibility, deployment risk, and how the network transitions to the new rules.
Soft Forks: Tightening the Rules
A soft fork makes the rules stricter. Transactions and blocks that are valid under the new rules are a subset of what was valid under the old rules. This means nodes that have not upgraded will still accept blocks produced under the new, tighter rules.
For example, SegWit (Segregated Witness, activated in 2017) changed how transaction data is structured, but old nodes could still process SegWit blocks. They simply treated SegWit transactions as "anyone-can-spend" outputs, which was intentionally designed into the upgrade path. Old nodes never saw an invalid block.
Soft forks are backward-compatible. They do not force every node on the network to upgrade simultaneously. This is why Bitcoin strongly prefers soft forks for consensus changes.
Hard Forks: Changing the Rules
A hard fork loosens or fundamentally changes the rules. Blocks that are valid under the new rules would be rejected by nodes running the old rules. This means the network splits unless every node upgrades.
Bitcoin has never deployed a deliberate, contentious hard fork. The 2017 block size debate produced Bitcoin Cash as a hard fork, but the Bitcoin network itself continued under the existing (soft-fork-compatible) SegWit upgrade. The Bitcoin development community treats hard forks as a last resort because they fracture the network and force every participant to choose a side.
Why Soft Forks Win
Soft forks match Bitcoin's design philosophy: backward compatibility, voluntary adoption, and minimal disruption. A soft fork lets the network upgrade gradually. Nodes that upgrade get access to new features. Nodes that do not upgrade continue to function without seeing invalid blocks. No one is forced off the network.
| Property | Soft Fork | Hard Fork |
|---|---|---|
| Rule change | Tightens existing rules | Loosens or changes rules |
| Old nodes | Still accept new blocks | Reject new blocks |
| Backward compatible | Yes | No |
| Network split risk | Low | High |
| Upgrade pressure | Optional (but recommended) | Mandatory to stay on the chain |
| Bitcoin's preference | Strongly preferred | Avoided |
How Upgrades Activate
Writing the code and getting it reviewed is only part of the process. For consensus changes, the code must be activated across the network. Bitcoin has used several activation mechanisms over the years, each reflecting different assumptions about who holds ultimate authority over the protocol.
Miner-Signaled Activation (BIP 9)
BIP 9 formalized version-bits signaling: miners set a specific bit in the block header's nVersion field to indicate support for a particular proposal. Each proposal was assigned its own bit, a start time, and a timeout. Within each retarget period (2,016 blocks, approximately two weeks), if 95% of blocks signaled support, the upgrade would lock in and activate after one additional retarget period.
SegWit used BIP 9 with bit 1, a start time of November 15, 2016, and a timeout of November 15, 2017. Direct signaling never reached the BIP 9 95% threshold, so the User Activated Soft Fork (UASF) via BIP 148 created pressure that led miners to deploy BIP 91, which reduced the effective signaling threshold to 80% for 336 blocks. SegWit then locked in at block 479,808 in early August 2017 and activated at block 481,824 on August 24, 2017.
The UASF: Users Enforce the Rules
The 2017 SegWit activation revealed a critical lesson about Bitcoin governance. Direct miner signaling for SegWit stalled below the required threshold for months, despite broad community support for the upgrade.
In response, a UASF movement emerged. The BIP 148 UASF set a flag day: after August 1, 2017, UASF nodes would reject blocks that did not signal for SegWit. The message was clear: nodes, not miners, enforce consensus rules. Users run the software they agree with, and miners who produce blocks that nodes reject are mining for nothing.
The UASF pressure worked. Miners activated SegWit before the flag day, and the network upgraded without a split. The episode permanently shifted the understanding of power in Bitcoin: miners produce blocks, but nodes decide which blocks are valid.
Speedy Trial (BIP 9 Variant)
Taproot's activation in 2021 used a refined mechanism called Speedy Trial, deployed in Bitcoin Core 0.21.1. Speedy Trial was a BIP 9 variant with lockinontimeout=false and a compressed signaling window: miners signaled using bit 2 between 24 April 2021 and 11 August 2021, the starttime and timeout given in BIP 341's deployment parameters. The threshold was 90% of blocks within any retarget period (1,815 of 2,016 blocks). If miners did not signal in time, the community would have time to choose a different activation path. Taproot reached 90% miner signaling in the signaling period ending June 12, 2021, locked in, and activated at the separately specified minimum activation height, block 709,632, on November 14, 2021.
Activation Mechanisms Compared
| Mechanism | Used For | Signaling Threshold | Signaling Window | Key Feature |
|---|---|---|---|---|
| Flag day | Early soft forks (pre-2015) | N/A | N/A | Activates on a fixed date regardless of miner readiness |
| BIP 9 (version bits) | SegWit (2017) | 95% of blocks per retarget period | 1 year (Nov 2016 - Nov 2017) | Miners signal via nVersion bit; gives miners effective veto power |
| BIP 148 (UASF) | SegWit activation pressure (2017) | N/A (node-enforced) | Flag day: Aug 1, 2017 | Nodes reject non-signaling blocks; users enforce the rules |
| Speedy Trial (BIP 9 variant) | Taproot (2021) | 90% (1,815 of 2,016 blocks) | ~3 months (May - Aug 2021) | Shortened signaling window with lockinontimeout=false; faster resolution |
Major Upgrades in Bitcoin's History
SegWit (2017)
Segregated Witness, defined in BIP 141, was Bitcoin's most consequential upgrade since its launch. SegWit restructured transactions by moving signature data (the "witness") into a separate structure outside the base block. This fixed three problems simultaneously:
- Transaction malleability: Before SegWit, a third party could modify a transaction's ID without changing its economic effect. This made building reliable payment channels (like Lightning) impossible. SegWit eliminated this attack surface.
- Block capacity: By moving witness data out of the base block, SegWit replaced the 1 MB block size limit with a 4 million weight unit (4 MWU) block weight limit. Transactions became smaller in terms of the space they consumed, reducing fees.
- Script versioning: SegWit introduced a versioning system for Bitcoin scripts, making future upgrades (like Taproot) far easier to deploy as soft forks.
SegWit was deployed as a soft fork. Old nodes saw SegWit transactions as valid (treating them as "anyone-can-spend"), while upgraded nodes enforced the new witness rules. The upgrade enabled the Lightning Network, a layer-2 payment protocol that depends on non-malleable transaction IDs.
Taproot (2021)
Taproot, specified across BIP 340, BIP 341, and BIP 342, was Bitcoin's first consensus upgrade since SegWit. It introduced three tightly connected improvements:
- Schnorr signatures (BIP 340): Replaced ECDSA for Taproot outputs with Schnorr signatures, which are mathematically simpler, enable efficient multisig aggregation, and produce smaller signatures. A multisig transaction using Schnorr key aggregation looks identical on-chain to a singlesig transaction.
- Taproot outputs (BIP 341): Introduced a new output type where the common spending path (a single key or aggregated key) looks like a standard payment. Complex spending conditions (timelocks, multisig thresholds, hash locks) are hidden in a Merkle tree and only revealed if that specific branch is used. In the normal case, nobody can tell whether a transaction used a simple key or a complex script.
- Tapscript (BIP 342): Updated Bitcoin's scripting language for Taproot, adding new opcodes and making future script upgrades easier through the versioning mechanism SegWit introduced.
Together, these three improvements strengthen on-chain privacy. Before Taproot, multisig transactions were visibly different from singlesig transactions on-chain, and complex spending conditions were exposed whenever the transaction was spent. After Taproot, the cooperative spending path is indistinguishable from a simple payment, and only the executed branch of a script tree is ever revealed.
Taproot also benefits Lightning Network implementations. Core Lightning (CLN), the Lightning implementation maintained by Blockstream, leverages protocol-level improvements like Taproot to build more efficient and private payment channels.
Why Bitcoin Changes Deliberately
Bitcoin's upgrade pace frustrates developers accustomed to rapid iteration. Features that would ship in a sprint at a software startup take years in Bitcoin.
The Stakes Are Different
Bitcoin secures over $1.3 trillion in value. A consensus bug that allows double-spending, inflation, or chain splits would undermine the monetary properties that make Bitcoin valuable in the first place. There is no "rollback" button. There is no customer support line. A mistake at the consensus layer affects every bitcoin holder on the planet.
The review process, the multi-year discussion cycles, and the conservative activation mechanisms all serve the same goal: making sure that the thing that works keeps working.
Deliberate Conservatism
Bitcoin's conservatism is deliberate. Every other property of Bitcoin depends on the protocol being predictable and stable. The 21 million supply cap is only credible if the rules are hard to change. The censorship resistance is only meaningful if no small group can push through changes unilaterally.
The difficulty of upgrading Bitcoin is directly proportional to the trust people place in it. If Bitcoin were easy to change, it would be easy to corrupt. The deliberate upgrade process is what makes Bitcoin's monetary policy credible over a multi-decade time horizon.
Rough Consensus and Running Code
Bitcoin development follows a principle borrowed from the Internet Engineering Task Force: "rough consensus and running code." There is no formal voting mechanism and no executive or board that approves changes. Instead, the community converges on solutions through technical merit, open discussion, and demonstrated code.
"Rough consensus" means near-universal agreement among technically informed participants. A single well-reasoned objection from an experienced developer carries more weight than a hundred casual endorsements. The threshold for consensus changes is intentionally high because the cost of getting it wrong is permanent.
Proposals Under Discussion Today
Several proposed upgrades are under active discussion as of early 2026. Proposals for new opcodes like OP_CTV (BIP 119, Check Template Verify) and OP_CAT aim to expand Bitcoin's scripting capabilities, enabling covenants, vaults, and more expressive smart contracts directly on the base layer. None have reached the activation stage, and the debate around each reflects the same careful process that produced SegWit and Taproot.
Separately, work continues on non-consensus improvements: better peer-to-peer network privacy through encrypted transport (BIP 324, already deployed), wallet descriptor standardization, fee estimation improvements, and mempool policy refinements. These changes ship in regular Bitcoin Core releases without requiring network-wide coordination. Blockstream researchers, including Andrew Poelstra (Director of Research), have contributed to multiple Bitcoin upgrade proposals, and the company funds several contributors who participate in the BIP review process.
The tension between "Bitcoin needs more expressiveness" and "Bitcoin needs to remain simple and secure" is the defining technical debate of this era. The upgrade process exists precisely to let that debate play out on its own timeline, with the burden of proof always on the side proposing change.
Frequently Asked Questions
Who decides what gets upgraded in Bitcoin?
No single person or organization decides. Bitcoin upgrades emerge through a decentralized process: anyone can write a BIP, any developer can submit code, and every node operator chooses which software to run. For consensus changes, overwhelming agreement across developers, miners, and node operators is required. The 2017 UASF demonstrated that nodes (run by users) hold the ultimate authority, not miners or developers.
How long does a Bitcoin upgrade take from proposal to activation?
There is no fixed timeline. SegWit took approximately three years from initial proposal (2015) to activation (2017), including a contentious community debate. Taproot took about three years from the initial BIP drafts (2018) to activation (2021), though it had broader community support. Non-consensus changes can ship in months through regular Bitcoin Core releases.
Can a Bitcoin upgrade be reversed once activated?
Technically, a soft fork could be reversed by another soft fork that re-allows what was previously restricted, but this has never happened and would require the same level of consensus as the original upgrade. Consensus changes are designed to be permanent. Reverting one would undermine confidence in Bitcoin's stability and could invalidate transactions made under the new rules.
What happens if I don't upgrade my Bitcoin node?
For soft forks, your node continues to function normally. It will accept blocks produced under the new rules because soft forks only tighten rules (new blocks are still valid under the old, looser rules). For hard forks, your node would reject blocks produced under the new rules and follow the old chain. Bitcoin's preference for soft forks means users are rarely forced to upgrade.
Is Bitcoin's deliberate upgrade process a weakness?
The upgrade pace is a direct consequence of Bitcoin's design goals. A monetary network that secures over $1.3 trillion cannot afford to "move fast and break things." The deliberate process ensures that changes are thoroughly vetted, backward-compatible where possible, and adopted voluntarily. The difficulty of changing Bitcoin is what makes its monetary policy credible.
What is the difference between a BIP and a pull request?
A BIP is a design document that describes a proposed change at the specification level. It defines what the change does and why. A pull request is actual code submitted to the Bitcoin Core repository that implements a change. Not every BIP results in a PR (some are informational), and not every PR implements a BIP (many PRs are non-consensus improvements that do not need a formal specification).
What is the difference between a soft fork and a hard fork?
A soft fork tightens Bitcoin's rules, so nodes still running older software accept blocks valid under the new rules. Because it is backward-compatible, everyone can keep running their existing software. A hard fork loosens or changes the rules, so old nodes reject the new blocks and the network splits unless every node upgrades. Bitcoin strongly prefers soft forks because they avoid forcing upgrades and keep the network unified. SegWit and Taproot were both soft forks.
What is a Bitcoin Improvement Proposal (BIP)?
A Bitcoin Improvement Proposal (BIP) is a formal design document that describes a proposed change to Bitcoin, its rationale, and a detailed specification. Modeled on Python's PEP process, the BIP system gives anyone a structured way to propose changes and lets the community evaluate them. BIPs fall into three types: Standards Track (protocol changes), Informational, and Process. A BIP defines what a change does; it does not, by itself, activate that change on the network.