Skip to content
Basis Desk

New: Basis Desk Verify for Chrome & Firefox — fact-check crypto news on any page, free.Get the extension →

Tech & Protocols · 4 min read Last reviewed October 29, 2026

How Bitcoin Changes: Bitcoin Core and BIPs Explained

Bitcoin operates without a central authority, yet its underlying software requires updates. The process relies on Bitcoin Improvement Proposals, developer review, and node activation to ensure only widely supported changes take effect.

Editorial oversight: Julian Mercer, Chief Editor
Neutral

Key points

  • Bitcoin upgrades rely on rough consensus among developers rather than a central leader.
  • BIP authors do not assign their own proposal numbers; the BIP editor handles this assignment.
  • Network upgrades require activation by nodes and miners, often using thresholds defined in BIP 9 or BIP 8.
  • The slow development pace is an intentional design choice to prioritize network security and stability.

Bitcoin functions without a central leader or corporate board. However, the software that powers the network requires maintenance, bug fixes, and occasional upgrades to address new challenges. The mechanism for changing Bitcoin relies on a deliberate, conservative process centered around Bitcoin Improvement Proposals (BIPs), extensive developer review, and activation by network participants 1.

The Role of Bitcoin Core

The most widely used software implementation of the Bitcoin protocol is Bitcoin Core. It is an open-source project maintained by a decentralized group of developers worldwide. Anyone can review the code, suggest modifications, or contribute improvements 2.

Because Bitcoin Core serves as the reference implementation for the network, changes to its codebase are scrutinized heavily. There is no lead developer who can unilaterally force a change into the software. Instead, developers rely on a process called rough consensus. This means that a proposed change must receive broad agreement among the active contributors, and any significant technical objections must be addressed before the code is merged. This system ensures that updates do not compromise the security or stability of the network. For a deeper look at how the network is structured, read our guide on Understanding Bitcoin: The Architecture of Decentralized Digital Scarcity.

What is a Bitcoin Improvement Proposal (BIP)?

When a developer or researcher wants to introduce a significant change to the Bitcoin protocol, they draft a Bitcoin Improvement Proposal (BIP). A BIP is a formal design document providing information to the Bitcoin community, describing a new feature, process, or environment change 3.

The BIP process is governed by BIP 2, which outlines the workflow for submitting and updating proposals. First, an author drafts the proposal and discusses it on development mailing lists or forums to gauge interest and gather initial feedback. If the idea gains traction, the author formats it according to specific guidelines and submits it to the BIP editor. Crucially, authors do not assign BIP numbers themselves; the BIP editor reviews the submission for formatting and clarity, and then assigns it an official BIP number 3.

BIPs fall into three main categories: Standards Track (changes to the network protocol, block, or transaction validation rules), Informational (design issues or general guidelines), and Process (processes surrounding Bitcoin development).

Developer Review and Rough Consensus

Once a BIP is published, it enters a rigorous peer review phase. Developers across the ecosystem analyze the proposal for potential vulnerabilities, inefficiencies, or unintended consequences. This review process can take months or even years.

Discussions occur openly on mailing lists, GitHub repositories, and developer meetings. The goal is to reach rough consensus, where the overwhelming majority of developers agree that the proposal is technically sound and beneficial, and no severe technical objections remain unaddressed. If a proposal is contentious or introduces unacceptable risks, it is typically withdrawn, rejected, or sent back for major revisions.

How Upgrades Go Live: Node Activation

Merging code into Bitcoin Core does not automatically enforce a new rule on the $BTC network. Network participants—specifically, node operators and miners—must adopt the upgraded software.

For backward-compatible changes (soft forks), Bitcoin relies on activation mechanisms to coordinate the upgrade without splitting the network. A common approach is a Miner Activated Soft Fork (MASF). Under this model, miners signal their readiness for the upgrade by altering the version bits in the blocks they mine, as outlined in BIP 9 4.

For example, a BIP-9 activation might require a 95% threshold over a specific period. Assume a difficulty adjustment period lasts exactly 2,016 blocks. To lock in the upgrade, at least 1,915 of those 2,016 blocks must contain the specific version bit signaling readiness. If this threshold is met within the predefined timeframe, the upgrade locks in and activates after another 2,016-block period, giving the rest of the network time to upgrade their nodes. If the threshold is not met before the timeout date, the proposal fails.

Another mechanism is BIP 8, which is similar to BIP 9 but can include a "Flag Day" provision. If the signaling threshold is not met by a specific block height, the upgrade can be programmed to activate automatically, effectively requiring miners to enforce the new rules or risk having their blocks rejected by the network.

Why Bitcoin Upgrades Move Slowly

The slow pace of Bitcoin development is an intentional design choice. The network secures hundreds of billions of dollars in value, and a critical bug could lead to catastrophic loss of funds or network downtime.

Prioritizing stability and security over rapid innovation ensures that Bitcoin remains a reliable base layer for the financial ecosystem. The lack of a central authority means that coordinating upgrades requires immense social and technical consensus. This friction prevents contentious changes from being forced upon unwilling participants, preserving the network's decentralization and predictability.

Common Misconceptions

  • Developers control Bitcoin: While developers write the code, they cannot force the network to run it. Node operators and miners independently choose which version of the software to run. If developers release an update the community disagrees with, the network simply will not adopt it.
  • Miners dictate network rules: Miners order transactions and secure the network, but they do not dictate the consensus rules. Fully validating nodes enforce the rules; if a miner creates a block that violates these rules, the nodes will reject it, and the miner will forfeit their block reward.
  • BIP numbers imply approval: An assigned BIP number simply means the proposal met the formatting and editorial requirements to be published as a draft. It does not indicate that the proposal has achieved consensus or will ever be implemented.

What to Watch

As the network scales, the tension between maintaining base-layer stability and introducing necessary features will persist. Future upgrades will likely focus on enhancing privacy, improving scaling mechanisms like the Lightning Network, or addressing long-term security threats, such as those detailed in the Bitcoin Developers Propose BIP 360 to Mitigate Long-Exposure Quantum Vulnerabilities report. Monitoring which BIPs achieve rough consensus offers insight into the technological trajectory of the network and its fundamental value proposition.

Questions this story raises

Who decides which Bitcoin upgrades get implemented?
No single entity decides. Upgrades require a combination of developer consensus to merge the code and network consensus from node operators and miners who choose to run the updated software.
What happens if miners reject an upgrade?
If a proposed upgrade relies on miner signaling (like a standard BIP-9 MASF) and fails to reach the required threshold before its timeout date, the upgrade does not activate.
Can developers reverse a Bitcoin transaction?
No. Developers only propose and maintain the protocol software. They do not have administrative access to the live network or the ability to alter transaction history.

References

  1. [1] Bitcoin Core Documentation — Bitcoin.org
  2. [2] BIP 9: Version bits with timeout and delay — Bitcoin GitHub Repository
  3. [3] BIP 2: BIP purpose and guidelines — Bitcoin GitHub Repository

Evergreen explainer written by Basis Desk's system and checked by an independent model pass for factual errors and advice language. Figures, fees and rules change — the references above are where to verify current specifics. Market figures marked "at the time of writing" come from live exchange data. Report an error: corrections@basisdesk.news · corrections policy.

The Daily Brief, in your inbox at 07:00 ET

Five stories, the numbers that moved, what to watch. Three minutes. No hype, no advice, unsubscribe in one click.

Not financial advice. Basis Desk publishes information, not recommendations. Crypto assets are volatile and you can lose what you invest.