ShopWhen Bitcoin launched in 2009, the original software could generate addresses, authorize transactions with private keys, and maintain the blockchain. Over the years, enhancements were added through a formal, open process called the Bitcoin Improvement Proposal (BIP) system.
Bitcoin has no central authority and no mechanism for imposing updates. Changes require genuine consensus across an independent global network, making them rare and deliberate. Those that have been adopted have added capability in privacy, efficiency, and functionality without altering Bitcoin's core monetary properties.
What are Bitcoin Improvement Proposals?
A Bitcoin Improvement Proposal (BIP) is a formalized way to propose, debate, and coordinate changes to the Bitcoin protocol. The process exists because Bitcoin has no defined leadership and no mechanism for mandating changes: proposed modifications must be openly documented, publicly reviewed, and voluntarily adopted by the independent participants who make up the network.
To understand why BIPs exist, it helps to distinguish between three things that share the name "Bitcoin":
-
The Bitcoin asset. Bitcoin (BTC) is a digital bearer asset. Each unit is transferred between peers on a public ledger, and ownership is proved with a private key, not an account or username.
-
The Bitcoin network. The network is the global set of independent participants running compatible Bitcoin software. Each node validates transactions and blocks, relays them to peers, and enforces its own copy of the rules. No single participant controls the network.
-
The Bitcoin protocol. The protocol is the shared ruleset that every node enforces by running the software. It defines what constitutes a valid transaction and a valid block, including the 21 million supply cap, the requirement for a valid cryptographic signature on every spend, and how nodes communicate across the peer-to-peer network.
BIPs can address any of those three layers. A BIP can focus on the fundamental rules of the protocol, governing what counts as a valid transaction or block. Others can define how nodes find and communicate with each other to form the network. Others can work at the application layer, covering how the bitcoin asset is transferred, how wallets derive keys, how transaction fees are structured, and how signing devices communicate with wallet software.
Adoption of a BIP is intentionally difficult. Bitcoin has no leadership that can decide when a rule takes effect, and no one can push a software update to someone else's node. Every change is entirely opt-in.
A contributor who wants a proposal adopted must convince enough independent participants the change is sound and worth running on their own nodes. The BIP process is the formal coordination mechanism for that.
The Structure of a BIP
A BIP is a design document whose format was modeled on Python's PEP (Python Enhancement Proposal) process. BIP-1, written by Amir Taaki in 2011, defined the BIP process itself.
Each BIP is a plain text file. The structure varies between BIPs because older proposals predate the formal template, but most technical BIPs contain some combination of the following:
- Header. The metadata block identifying the BIP number, title, author, type, and status.
- Abstract. A brief summary of the proposal and what it changes or introduces.
- Motivation. An explanation of the problem being solved and why the existing protocol or standard is insufficient.
- Specification. The technical definition of the proposed change. In practice this is often broken into labeled subsections rather than appearing under a single heading.
- Rationale. An explanation of the design choices made and why alternative approaches were not taken. Present in many BIPs but not all.
- Backwards Compatibility. An assessment of how the proposal interacts with existing software. Typically included when a change risks breaking something; omitted for entirely new standards.
- Test Vectors. Concrete input and output examples that allow implementers to verify their code produces correct results. Common in cryptographic and wallet standard BIPs.
- Reference Implementation. Working code demonstrating the proposal is feasible. Expected for most Standards Track proposals.
- References. Links to related BIPs, academic papers, or other source material.
The full repository is publicly readable and open to anyone to browse, read, and contribute to.
How Does a BIP Become a Standard?
A BIP becomes a standard through adoption, not approval. There is no committee that reviews proposals, no authority that certifies a BIP as accepted, and no vote that makes a change official. What matters is whether the developers, wallet authors, and node operators who make up the network choose to implement it.
Before adoption, a BIP goes through an extended period of public advocacy, review, and debate. Contributors discuss proposals on developer mailing lists and in GitHub pull request threads. Independent reviewers, including cryptographers, security researchers, and experienced developers, assess the technical claims and publish their findings. Bitcoin conferences, podcasts, and local meetups worldwide also feature talks and debates on proposed changes.
For significant changes, this process can take months or years before any implementation begins.
Anyone can read or engage with a BIP. The full repository is publicly readable at github.com/bitcoin/bips, and the discussion surrounding each proposal is visible alongside the document itself.
The formal lifecycle stages of BIPs are:
- Draft. Under active development by the author. Not yet submitted for review.
- Proposed. Submitted to the repository. A BIP editor reviews format and assigns a BIP number. Community discussion begins.
- Active. In ongoing, open-ended use. BIP-1 itself is Active rather than Final.
- Final. The specification is complete and stable. Most wallet and signing standards reach this status.
- Withdrawn. Pulled by the author before finalization.
- Rejected. Not accepted after community review.
- Replaced. Superseded by a newer BIP covering the same ground.
- Deferred. Postponed, not abandoned.
BIP editors review format compliance, not whether the idea is good. That assessment happens in public discussion. "Final" status signals that a specification is stable and worth building on, not that every node or wallet must implement it.
The Case for Stability
Not everyone in the Bitcoin community believes the protocol should keep changing. A significant school of thought holds that Bitcoin's base layer should eventually stop changing altogether. This position is often called "ossification."
The reasoning for ossification is straightforward. Bitcoin derives much of its value from predictability. The 21 million supply cap and the rules governing valid transactions are trustworthy precisely because they are not subject to revision. Every change to the protocol, however well-intentioned, carries the risk of unexpected interactions with existing software, potential attack surfaces, and errors that are difficult to reverse once deployed.
The analogy often made is to TCP/IP, the foundational internet protocol that has barely changed since the 1980s. Applications built on top of it have evolved enormously, but the base layer's stability is what makes it reliable infrastructure. The argument is that Bitcoin should aspire to the same level of stability.
In practice, the BIP process already reflects this preference. The bar for consensus-layer changes is extremely high, the process is deliberately slow, and community resistance to unnecessary changes has grown over time. Many regard SegWit and Taproot as Bitcoin's last major upgrades for the foreseeable future.
This does not mean BIPs become irrelevant as Bitcoin matures. Application-layer standards, wallet conventions, and tooling will continue to develop. For changes that touch Bitcoin's core rules, the community's default position is increasingly conservative, and that conservatism is widely regarded as a feature, not a limitation.
Types of Bitcoin Changes
Not every improvement to Bitcoin requires a BIP, and different types of BIPs have different scopes and audiences.
| Type | What it covers | Who must act |
|---|---|---|
| Standards Track (Consensus) | Protocol rules governing what blocks and transactions are valid | Every node and miner |
| Standards Track (Peer Services) | How nodes communicate over the P2P network | Node operators |
| Standards Track (API/RPC) | Interface standards for software | Software developers |
| Standards Track (Applications) | Wallet formats, address types, key derivation, signing standards | Wallet software authors |
| Informational | Guidance and best practice documents | No adoption required |
| Process | BIPs about the BIP process itself | BIP editors and contributors |
The type determines who needs to care about a given BIP and what happens if they do not adopt it. A wallet standard that only one vendor implements causes interoperability problems but does not affect the network. A consensu rule change that only half the network adopts can split the chain entirely.
-
Standards Track (Consensus). These are the highest-stakes BIPs. When a proposal changes the rules governing what constitutes a valid block or transaction, every node on the network must adopt it for the chain to remain unified.
If some nodes adopt the new rules and others do not, the network can split into two separate "forks". The mechanics of soft forks and hard forks determine whether that split is temporary or permanent. Bitcoin Forks Explained covers both types in detail.
-
Standards Track (Peer Services). These BIPs define how nodes find each other, exchange transactions, and propagate blocks across the peer-to-peer network. They matter to node operators but do not require wallet changes or miner upgrades. A node that skips a peer services BIP can still participate in the network, just less efficiently. BIP-152, which introduced compact block relay to reduce bandwidth requirements for block propagation, is a well-known example.
-
Standards Track (API/RPC). These BIPs standardize the interfaces that software uses to communicate with Bitcoin node implementations. They are relevant primarily to developers building applications on top of Bitcoin Core or other node software, not to end users or wallet authors.
-
Standards Track (Applications). These are often the most directly relevant BIPs for self-custody users. They define how wallets generate keys, derive addresses, encode seed phrases, and sign transactions. No node upgrade is required, and wallet software authors independently choose to implement them.
A wallet that follows BIP39 and BIP32 can be recovered in any compatible software, while a wallet using a proprietary scheme cannot. There is no network-level consequence either way, but the personal consequence is significant: wallets that don't follow these BIPs may be irrecoverable with standard tools.
-
Informational and Process. Informational BIPs document existing practices, conventions, or guidance without proposing any change. They require no adoption by anyone. Process BIPs govern the BIP process itself, covering how proposals are submitted, reviewed, and advanced through lifecycle stages. BIP-1 and BIP-2 are both process BIPs. Neither type changes Bitcoin's rules or interoperability requirements.
Some changes require no BIP at all. Individual node operators can configure local policy settings, including what transactions to relay, how large a mempool to maintain, and how aggressively to filter certain transaction types.
Bitcoin Core and its alternative implementation Bitcoin Knots are both consensus-compatible but differ in their default relay policies and configurable options. These are local decisions, not protocol changes, and they require no BIP or community consensus to implement on your own node.
Soft Forks and Hard Forks
When a consensus-level BIP is adopted, the way it is adopted determines whether it creates a split in the network.
When a consensus-level BIP is adopted, the way it is adopted determines whether it creates a split in the network.
-
A soft fork tightens Bitcoin's existing rules in a backward-compatible way. Transactions that were valid before remain valid after, so nodes that have not upgraded still process the new blocks correctly. A soft fork does not require every participant to upgrade simultaneously, and it does not risk splitting the network.
SegWit in 2017 and Taproot in 2021 were both soft forks. If you held bitcoin through either upgrade, your funds were unaffected and new features were optional.
-
A hard fork changes rules in a way that is not backward-compatible. Nodes that have not upgraded reject blocks from upgraded nodes as invalid. If a significant portion of the network does not upgrade, the chain splits into two independent histories.
Bitcoin Cash (2017) and Bitcoin SV (2018) are the most prominent examples. In both cases, groups that wanted to change Bitcoin's rules found the network unwilling to follow. They forked away, creating separate coins on separate chains. Bitcoin continued on its own chain, unchanged. Neither BCH nor BSV represents an upgrade to Bitcoin, rather they are separate networks that share only Bitcoin's early transaction history.
If you held your own private keys at the time of a contentious hard fork, you hold coins on both resulting chains. Your keys work on both. If your bitcoin was on an exchange, the exchange decided whether and when you received any fork credit.
For a full treatment of how forks work, what backward compatibility means in practice, and what happens to your funds, see Bitcoin Forks Explained.
The BIPs Behind How Your Wallet Works
Most of what happens when you set up a hardware wallet or generate a seed phrase is governed by BIPs. The features are invisible in ordinary use, but understanding which BIP defines each one tells you what your wallet can recover, what software can reconstruct it, and what a proprietary alternative cannot.
-
Seed phrases (BIP39). The 12 or 24 words a hardware wallet generates are a BIP39 output. BIP39 defines the 2,048-word list and the algorithm that converts random entropy into a mnemonic. The four-letter uniqueness property of the word list allows words to be abbreviated on metal backups. BIP39 also defines the optional passphrase, sometimes called the "25th word," which generates a completely separate wallet from the same seed. For more on how this works in practice, see What is a Bitcoin Seed Phrase?.
-
HD wallets and derivation paths (BIP32, BIP44, BIP84, BIP86). BIP32 defines how a single root seed generates an entire tree of key pairs through a parent-child derivation process. Every address in a wallet is derived deterministically from that root. The specific path followed depends on the address type. BIP44 covers Legacy (P2PKH, "1..." addresses). BIP84 covers Native SegWit (P2WPKH, "bc1q..." addresses), which is the current standard for most singlesig wallets. BIP86 covers Taproot (P2TR, "bc1p..." addresses). A wallet that follows these standards can be recovered in any compatible software. A wallet with proprietary derivation cannot. For the full derivation path system, see Bitcoin Derivation Paths.
-
Partially signed bitcoin transactions (BIP174). The PSBT format is what makes hardware wallet signing possible. BIP174 defines a container format that carries a transaction from construction through signing to broadcast, passing between separate roles that can run on different devices. This separation is what allows air-gapped signing: the unsigned PSBT travels to the hardware wallet physically, which adds its signature without needing a live connection to the internet. BIP370 extended the format for multisig and CoinJoin workflows. For a full treatment, see What is a PSBT?.
-
Taproot and Schnorr (BIP340, BIP341, BIP342). BIP340 defines the Schnorr signature scheme for Bitcoin's secp256k1 curve. BIP341 defines Taproot spending rules, introducing P2TR addresses ("bc1p..."). BIP342 defines Tapscript, the scripting rules for Taproot's script spending path. Together they form Bitcoin's most significant protocol upgrade since SegWit, activated at block 709,632. One important privacy property: a 2-of-3 multisig wallet spending via the Taproot key path is indistinguishable from a singlesig transaction on-chain.
-
Output descriptors (BIP380-386). The output descriptor is the document that encodes a wallet's complete spending policy. For singlesig wallets, a seed phrase alone is enough for recovery. For multisig wallets, the descriptor is a required second backup, containing all extended public keys, derivation paths, and the m-of-n threshold. BIP380-386 define the descriptor language, making wallet policies portable and machine-readable across compatible software.
A more detailed list of BIPs can be found at The Most Important BIPs.
How to Follow Bitcoin Development
BIPs are the paper trail of Bitcoin's evolution. Following them does not require a technical background.
-
github.com/bitcoin/bips is the authoritative BIP repository. Every BIP is a text file. New BIPs appear as pull requests before they are merged, so community discussion is visible alongside the document itself. You can browse by number, search by keyword, and read every revision in the commit history.
-
bips.dev provides a cleaner, browsable interface for reading BIPs without navigating GitHub. It offers status badges, cross-references to related BIPs, and a readable layout — useful as a quick reference.
-
Bitcoin Optech is the best resource for understanding what each BIP means in practice. Optech publishes practical explanations of every significant BIP and its implications for wallet developers and users. The weekly Optech Newsletter summarizes notable Bitcoin development activity in readable form.
-
Bitcoin Wiki BIP index is a community-maintained index of BIPs with brief descriptions and status annotations.
Using AI to review BIPs: Current AI tools can read BIP text directly and explain what a proposal changes, what the trade-offs are, what potential attack vectors or edge cases exist, and how it interacts with existing BIPs. If you want to evaluate a proposed change, paste the BIP text (from the GitHub raw file) into a conversation and ask for a plain-language summary and a pros/cons assessment. This is a practical way to engage with Bitcoin development without requiring deep cryptographic or protocol expertise.
The curated list of BIPs most directly relevant to a self-custody setup is covered in The Most Important BIPs.
Related articles
Bitcoin Forks Explained
What soft forks and hard forks are, how they differ, and what happens to your bitcoin in each case.
The Most Important BIPs
A curated reference list of the BIPs that directly shape a self-custody user's experience.
What is a Bitcoin Seed Phrase?
The sequence of 12 or 24 words that generates every key in a Bitcoin wallet and serves as the sole recovery backup.
Bitcoin Derivation Paths
How HD wallets derive every key from a single seed, and what the derivation path numbers mean.