Glossary

Bitcoin Improvement Proposal (BIP)

The formal process for proposing and documenting changes to the Bitcoin protocol, similar to Python's PEPs or Ethereum's EIPs.

Key Takeaways

  • A Bitcoin Improvement Proposal (BIP) is a formal design document for proposing changes to Bitcoin: from consensus-layer upgrades like Taproot to wallet standards like BIP 39 mnemonic seed phrases.
  • BIPs follow an open, permissionless process: anyone can submit a proposal, and BIP editors evaluate formatting and relevance rather than technical merit, preserving Bitcoin's decentralized governance.
  • Acceptance and activation are distinct: a BIP can be published and reviewed without ever being deployed. Consensus changes require network-wide adoption through mechanisms like soft fork signaling.

What Is a Bitcoin Improvement Proposal (BIP)?

A Bitcoin Improvement Proposal (BIP) is a standardized document that describes a new feature, process, or informational guideline for Bitcoin. BIPs serve as the primary mechanism for introducing ideas, documenting design decisions, and building community consensus in a system with no central authority.

The BIP system was created by Amir Taaki in August 2011, when he submitted BIP 1 ("BIP Purpose and Guidelines"). The format was modeled directly after Python's Enhancement Proposal (PEP) system. Since then, BIPs have become the backbone of Bitcoin's open development process, with the BIP repository on GitHub containing over 450 proposals.

Every major Bitcoin upgrade, from Segregated Witness to Taproot, started as a BIP. Wallet interoperability standards like hierarchical deterministic wallets and mnemonic seed phrases are also defined through BIPs.

How the BIP Process Works

The BIP lifecycle begins when an author drafts a proposal and submits it to the BIP repository as a pull request. BIP editors review the submission for proper formatting, licensing, and on-topic relevance. Editors do not evaluate whether a proposal is technically sound or likely to be adopted: that judgment belongs to the broader community.

Once a BIP receives a number and is merged into the repository, it enters the community review phase. Developers discuss the proposal on mailing lists, in pull request comments, and at developer meetups. For consensus-layer changes, this review can span months or years.

BIP Types

BIPs are classified into three types, each serving a different role in the ecosystem:

  • Specification BIPs (formerly Standards Track): technical rules that affect interoperability. These cover consensus changes, peer services, transaction validation, and address formats. Examples include BIP 341 (Taproot) and BIP 174 (PSBT).
  • Informational BIPs: design guidelines or general information for the community. These do not propose protocol changes and do not require community consensus to be published.
  • Process BIPs: procedures and governance changes for the development process itself. BIP 2, which defined the original BIP workflow, is a Process BIP. The recent BIP 3 (deployed in 2025) overhauled the process for the first time in nine years.

BIP Statuses

Under the current process defined by BIP 3, proposals move through four possible statuses:

StatusMeaning
DraftAuthor is still working on the proposal
CompleteAuthors have finished planned work and recommend adoption
DeployedIn active use with evidence of implementation
ClosedHistorical interest only, no longer actively developed

BIP 3 simplified the previous system, which had nine statuses (Draft, Proposed, Final, Active, Deferred, Withdrawn, Rejected, Obsolete, and Replaced). The consolidation makes the process easier to follow and reduces ambiguity about where a proposal stands.

BIP Editors

BIP editors are responsible for evaluating proposals on formatting and relevance, assigning BIP numbers, and merging accepted pull requests. As of 2024, the editor team includes Bryan Bishop, Murch, Ruben Somsen, Olaoluwa Osuntokun (Lightning Labs CTO), and Jon Atack. Editors are expected to be liberal with publishing and do not serve as gatekeepers for technical decisions.

Notable BIPs

Several BIPs have fundamentally shaped how Bitcoin works today. They fall into three broad categories: wallet standards, protocol upgrades, and transaction formats.

Wallet Standards

These BIPs define how wallets generate keys, derive addresses, and back up funds:

BIPTitleImpact
BIP 32HD WalletsOne seed generates an entire tree of keys, enabling backup and recovery from a single root
BIP 39Mnemonic Seed PhrasesStandardized 12 to 24 word recovery phrases, making seed phrases human-readable
BIP 44Multi-Account HierarchyDefined the derivation path structure for multi-coin, multi-account wallets
BIP 84Native SegWit DerivationDefined derivation for native SegWit (bc1q) addresses
BIP 86Taproot DerivationDefined derivation for Taproot (bc1p) addresses

Together, these BIPs created the modern HD wallet stack that most Bitcoin wallets rely on today. For a deeper look at how address types evolved, see the research on Bitcoin address types from P2PKH to Taproot.

Protocol Upgrades

These BIPs changed Bitcoin's consensus rules through soft forks:

  • BIP 141 (SegWit): activated in August 2017, this upgrade fixed transaction malleability, increased effective block capacity, and enabled Layer 2 solutions like the Lightning Network.
  • BIP 340 (Schnorr Signatures): activated in November 2021, introducing smaller, more efficient signatures with support for batch verification and key aggregation via schemes like MuSig2.
  • BIP 341 (Taproot): activated alongside BIP 340, making complex transactions (multisig, timelocks) look identical to simple payments on-chain, which improves both privacy and efficiency.
  • BIP 342 (Tapscript): updated Bitcoin Script for Schnorr and Taproot compatibility.

The Taproot and Schnorr signatures deep dive explains how these upgrades work together to unlock new capabilities.

Transaction Formats

BIP 174 introduced Partially Signed Bitcoin Transactions (PSBT), a standardized format for passing unsigned or partially signed transactions between wallets, hardware signing devices, and coordination software. PSBT is essential for multisig workflows, CoinJoin coordination, and any scenario where multiple parties or devices collaborate on a single transaction.

BIP Acceptance vs. Activation

A common source of confusion is the difference between a BIP being accepted and a BIP being activated. These are distinct processes:

  • Acceptance is a social and editorial process: a BIP receives a number, is published in the repository, and undergoes community review. Any well-formatted, on-topic proposal can be accepted.
  • Activation applies only to consensus-layer changes (soft forks and hard forks). New rules must be enforced by the network, which requires miners and node operators to adopt the updated software.

Bitcoin has used two primary activation mechanisms. BIP 9 (Version Bits with Timeout) requires 95% of miners to signal readiness within a defined window: if the threshold is not reached, the upgrade fails. BIP 8 (Version Bits with Lock-in by Height) adds an optional flag that forces activation at a predetermined block height even without miner supermajority, giving node operators more control.

A BIP can be widely accepted and thoroughly reviewed without ever being activated. For example, OP_CHECKTEMPLATEVERIFY (BIP 119) has been discussed for years but has not achieved sufficient consensus for activation.

Recent Developments

The BIP process itself continues to evolve. BIP 3, authored by Murch and deployed in 2025, represents the first major overhaul of the process in nine years. It simplified statuses, clarified editor responsibilities, and updated terminology.

Several notable BIPs are currently under discussion:

  • BIP 347 (OP_CAT): reintroduces the concatenation opcode in Tapscript, enabling covenants and enhanced smart contracts. It reached Complete status in 2024. See the OP_CAT covenant debate for context.
  • BIP 352 (Silent Payments): privacy-enhancing reusable addresses that generate unique on-chain addresses per payment without requiring interaction between sender and receiver.
  • BIP 345 (OP_VAULT): a specialized covenant opcode for secure vault custody with time-delayed spending and recovery paths.
  • BIPs 446 and 448: draft proposals merged in early 2026 for Taproot-native covenant opcodes, targeting use cases like eltoo-style payment channels.

Why BIPs Matter

BIPs are more than technical documents: they are the governance mechanism for a system that manages hundreds of billions of dollars in value with no CEO, no board, and no central development team. The process ensures that changes to Bitcoin are deliberate, transparent, and subject to broad scrutiny.

For developers building on Bitcoin, BIPs provide the interoperability standards that make wallets, exchanges, and Layer 2 protocols work together. When a wallet implements BIP 32 and BIP 39, users can recover their funds in any compatible wallet. When a Layer 2 protocol like Spark builds on Taproot primitives defined in BIP 341, it inherits the security guarantees of a rigorously reviewed standard.

The BIP model has been adopted across the blockchain industry. Ethereum uses EIPs (Ethereum Improvement Proposals), and most major protocols maintain similar processes. The approach reflects a broader principle: decentralized systems need formal, transparent mechanisms for coordinating change.

Risks and Considerations

Slow Pace of Change

Bitcoin's conservative development culture means that even well-supported BIPs can take years to move from draft to activation. Taproot took roughly four years from initial proposal to activation. This deliberate pace prioritizes security and stability but can frustrate developers who want faster iteration.

Political Dynamics

Despite the formal process, BIP discussions can become contentious. The SegWit activation in 2017 was one of the most polarizing events in Bitcoin's history, ultimately leading to the Bitcoin Cash hard fork. The open process does not eliminate disagreement: it channels it into structured debate.

No Guarantee of Adoption

A BIP number does not imply endorsement. Many BIPs remain in Draft or Complete status indefinitely. Developers and users should evaluate proposals on their technical merits and community support rather than treating publication as validation.

Coordination Complexity

For consensus-layer BIPs, activation requires coordinating thousands of independent node operators and miners. The lack of a central authority makes upgrades safer in the long run but creates short-term uncertainty about whether and when a change will activate.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.