A Bitcoin Improvement Proposal (BIP) is a design document that describes a new feature, standard or procedure for Bitcoin. BIPs cover everything from changes to the consensus rules of the Bitcoin blockchain to wallet formats, peer-to-peer messages and the rules for writing BIPs themselves. They are published in a public repository on GitHub, numbered by a small group of editors, and discussed openly on the Bitcoin development mailing list.
The process was introduced in 2011 by BIP 1, written by Amir Taaki and modelled on Python's enhancement proposals. BIP 2, from 2016, replaced it, and BIP 3, which reached "Deployed" status in 2025, replaced BIP 2 with a simpler set of statuses. A BIP is only a description: it does not change Bitcoin by itself. Changes take effect only if software such as Bitcoin Core implements them and users, miners and businesses choose to run that software. Ethereum's equivalent is the Ethereum Improvement Proposal.
BIPs in plain terms
Think of a large shared recipe book that nobody owns. Anyone may suggest a new recipe or a change to an old one, but only on a standard form: what the change is, why it is needed, exactly how to make it, and how it fits with the recipes already in the book. A few volunteer librarians check that the form is complete and give it a number, but they do not decide whether anyone cooks it.
Whether the recipe is actually used depends on the cooks. If most kitchens adopt it, it becomes part of how everyone cooks. If they ignore it, it stays on file as a numbered idea. BIPs work the same way for Bitcoin's software.
How the BIP process works
An author first floats an idea on the mailing list or other public forums to test interest and find obvious flaws. If it holds up, the author writes a draft in the standard format (preamble, abstract, motivation, specification, rationale, backward compatibility and reference implementation) and opens a pull request to the bitcoin/bips repository. The BIP editors check format and scope, then assign a number. The author remains responsible for the proposal, gathers review and updates the text.
Under BIP 3 each proposal has a type and a status:
- Specification BIPs define technical rules that implementations must follow to interoperate, including consensus changes, network messages and wallet standards.
- Informational BIPs describe design issues or give general guidance without requiring anything.
- Process BIPs describe or change procedures around Bitcoin, including the BIP process itself.
- Statuses are Draft (being developed), Complete (the authors consider it finished and recommend adoption), Deployed (settled and in active use) and Closed (of historical interest only). BIP 2 used a longer list, including Proposed, Final, Rejected and Withdrawn.
Landmark BIPs
- BIP 16 (2012). Pay-to-Script-Hash, which made multi-signature wallets practical, activated as a soft fork.
- BIP 32, BIP 39 and BIP 44. Hierarchical deterministic wallets, the mnemonic word lists behind most seed phrases, and a standard path structure for accounts. Together they let one backup restore every private key in a wallet, and they are used well beyond Bitcoin.
- BIP 9. A method for miners to signal readiness for soft forks using bits in the block version field.
- BIPs 141, 143 and 144. Segregated Witness (SegWit), activated in August 2017.
- BIP 173 and BIP 350. The bech32 and bech32m address formats that start with
bc1. - BIPs 340, 341 and 342. Schnorr signatures, Taproot and Tapscript, activated in November 2021.
- BIP 94 and BIP 325. Testnet4 and signet, the public test networks developers use before changes reach mainnet.
From proposal to activation
For a consensus change, a complete BIP is only the start. Code must be reviewed and merged into one or more node implementations, the activation mechanism must be agreed, and enough of the network must upgrade. Because Bitcoin's culture strongly favours backward compatibility, consensus BIPs are almost always designed as soft forks rather than hard forks, and activation has historically taken years. Taproot was assigned its BIP numbers in 2020 and activated at block 709,632 on 14 November 2021; SegWit was proposed in late 2015 and activated in August 2017.
Non-consensus BIPs, such as wallet and address standards, spread differently: each wallet or exchange decides whether to support them, and they become standards through common use.
Criticism and debate
The BIP process is praised for transparency. Every proposal, comment and revision is public, and the documents form a detailed technical record of the network's design. It is also criticised for being slow and informal about the most important question, which is how to decide that the community actually supports a consensus change. There is no vote, and governance happens through a mix of developer review, miner signalling and the choices of people running a full node.
Disputes have also arisen over editorial capacity. In April 2024 several new editors were added after complaints that proposals were waiting months for review and numbers. Supporters of the open-source model argue that this friction is intentional: changing money that millions rely on should be hard.