BIP Process (BIP 2)

The BIP process is the documented procedure by which changes to Bitcoin and its surrounding conventions are proposed, discussed, and recorded. A Bitcoin Improvement Proposal (BIP) is a design document that describes a new feature, gathers community input on a design, or documents a process or convention. The process is self-describing: it is defined in BIP 2, which superseded the original BIP 1 (itself adapted from Python's PEP process). Because Bitcoin has no central authority, the BIP process is a coordination tool rather than a decision-making body — a BIP does not become a consensus rule by being assigned a number, and plenty of numbered BIPs were never adopted by anyone.

Types and statuses

BIPs fall into three categories. Standards Track BIPs affect interoperability or consensus across implementations — transaction formats, script upgrades like Taproot, or peer-to-peer messages such as compact block relay. Informational BIPs offer design guidelines or general information that the community may freely ignore. Process BIPs describe changes to procedure itself and generally require rough consensus to adopt. Each document advances through statuses — Draft, Proposed, Final, Active, Rejected, Withdrawn, Replaced, and (under BIP 2) Deferred or Obsolete — and a proposal that sees no progress for an extended period may be marked Rejected simply to keep the index honest. Status reflects reality on the network, not editorial preference: a Standards Track BIP reaches Final only once it has real-world adoption.

The champion and the editors

An author — the champion — is expected to vet an idea publicly, historically on the Bitcoin developer mailing list, before formal submission, then shepherd the discussion, absorb criticism, and revise the document. BIP editors perform a deliberately administrative role: assigning numbers, checking formatting, completeness, and licensing, and merging documents into the repository. Editors do not judge technical merit, and number assignment is not an endorsement. This separation matters more than it looks. It keeps the index a neutral record of proposals rather than a gatekept list of approved changes, which is exactly what you want in a system where no one has the authority to approve changes in the first place.

Why a document process matters in a leaderless system

The BIP process is how a decentralized ecosystem builds shared reference points without a standards committee. Wallets in different countries implement the same seed-phrase and derivation conventions because BIPs 32, 39, and 44 gave everyone one document to build against; miners and pool software interoperate because the relevant messages were specified, argued over, and frozen in public. The process documents intent and specification — activation of any consensus change is a separate, harder matter handled through soft fork activation mechanisms such as miner-activated or user-activated soft forks. That gap between "specified" and "activated" is a feature: it keeps the power to change Bitcoin with the people running nodes, not with whoever writes the most persuasive document.

Reading BIPs like an operator

For a node runner or miner, the BIP index is the primary source: when marketing copy claims a wallet "supports Taproot" or a pool "supports version rolling," the underlying BIP tells you precisely what that means on the wire. Discussion typically begins on the Bitcoin developer mailing list, and the repository history shows how each design evolved under review. Learning to read a BIP directly — motivation, specification, rationale, backward compatibility — is one of the most durable skills a sovereign Bitcoiner can build, because it replaces trust in summaries with verification at the source.

A good starting exercise: pick one BIP your own stack depends on — BIP39 for your seed words, BIP152 for your node's block relay — and read it end to end. The documents are shorter and clearer than their reputation suggests.

Full open-data reference: Bitcoin BIPs Reference — CSV / JSON + REST API, CC BY 4.0.