The Bitcoin Improvement Proposal (BIP) process is the standardised social and technical workflow by which proposed changes to the Bitcoin protocol, best practices, and informational standards are drafted, reviewed, debated, and either accepted or rejected by the Bitcoin developer community. It defines the lifecycle of a proposal from Draft through Proposed, Final, Active, Withdrawn, or Rejected, providing a structured mechanism for decentralised protocol governance without a centralised authority.
Content
- The BIP process was established by Amir Taaki in 2011 via BIP-1, which defined the process itself, modelled on Python Enhancement Proposals. Luke Dashjr updated the governance documentation in BIP-2 (2016) to reflect how the process had evolved in practice. The process deliberately avoids formal voting or a central committee, relying instead on social consensus demonstrated by miner signalling, node operator adoption, and developer agreement. This design reflects Bitcoin’s founding philosophy of decentralisation and resistance to capture by any single party.
- Technically, a Standards Track BIP progresses through Draft (initial proposal), Proposed (considered complete and ready for community consideration), and then either Final (widely deployed and not intended to change) or Active (a living document updated by community practice, such as BIP-1 itself). Consensus-layer BIPs—soft forks—additionally require an activation mechanism. Historic methods include IsSuperMajority (used for BIP-66), BIP-9 versionbits (used for Segwit), and BIP-8 with configurable LOT (lock-in on timeout) used in the debate over Taproot. Speedy Trial (BIP-91-derived) was ultimately used for Taproot activation (block 709,632).
- The ecosystem supporting the BIP process consists of the bitcoin-dev mailing list (now hosted on groups.io after the Linux Foundation discontinued hosting), the BIP repository on GitHub (github.com/bitcoin/bips), and informal coordination through IRC (Libera.chat bitcoin-core-dev), Twitter/X, and developer conferences. BIP editors (historically Gavin Andresen, Luke Dashjr, and currently a rotating set of contributors) are responsible for assigning numbers and maintaining metadata but do not gate proposals on technical merit.
- As of 2024–2025 the BIP process faces tensions between its deliberately slow, consensus-requiring nature and market pressure for new features. High-profile proposals including OP_CHECKTEMPLATEVERIFY (BIP-119), OP_CAT (BIP-347), and LNHANCE (a bundle of opcodes for Lightning improvements) have been in extended community debate, illustrating the difficulty of achieving soft-fork consensus without a central arbiter. Some contributors advocate for a more structured evaluation framework, whilst others consider the current resistance to change a safety feature. The process remains the central legitimising mechanism for Bitcoin protocol development.