The BIP process

Wonder

1. If a BIP is just a document, how does it alter the behavior of millions of computers?
2. Why do editors assign numbers to proposals without ever voting on their merit?
3. What prevents a single developer from forcing a rule change onto the entire network?

Explore

1. Amir Taaki introduced Bitcoin Improvement Proposals (BIPs) in August 2011, modeled directly on Python’s PEPs. BIP1 established the framework for documenting protocol changes and general information. Luke Dashjr revised it in 2016 with BIP2, and in 2025 BIP3, ‘Updated BIP Process’ by Mark Erhardt, replaced BIP2. First hosted on a wiki, BIPs now live in a version-controlled repository on GitHub, so every change is tracked and reviewable.
2. Under BIP3 there are three types. Specification BIPs describe changes to the protocol or to interoperable software, such as new transaction rules, wallet standards or network messages. Informational BIPs give guidance or context without requiring anything. Process BIPs describe how development itself works, including the BIP process. Older BIPs keep the ‘Standards Track’ label they were written under, which corresponds to today’s Specification type.
3. Each proposal is driven by its authors, who write it, defend it on the mailing list and in review, and revise it in response to criticism. Authorship carries no power to enforce adoption. A BIP remains a document until node or wallet software implements it and people choose to run that software. There is no vote; a consensus change happens only if enough of the network upgrades.
4. Discussion occurs on the bitcoin-dev mailing list, in code review pull requests, and at conferences. There is no formal authority or binding vote. Editors assign numbers and check form but do not decide adoption. Under BIP3 a proposal’s status runs Draft, then Complete when its authors consider it finished, then Deployed once it is in use; proposals that are abandoned or superseded are marked Closed. The status field in the repository reflects this lifecycle.
5. Well-known BIPs illustrate the process’s impact. BIP16 introduced Pay-to-Script-Hash (P2SH) in 2012. BIP32 defined Hierarchical Deterministic wallets, and BIP39 standardized seed phrases for recovery. BIP141 enabled Segregated Witness (SegWit), which activated in August 2017 at block 481,824. BIPs 340-342 introduced Schnorr signatures and Taproot, activating in November 2021. Each required careful coordination between developers, miners, and users to ensure backward compatibility or a clean fork.
6. Open the BIPs repository on GitHub. Locate three BIPs: one Standards Track (e.g., BIP141), one Informational (e.g., BIP50), and one Process (e.g., BIP3). Read the status field for each. Note when each was created and how its status changed. This exercise reveals that technical merit alone is insufficient; social consensus and economic alignment are the true gatekeepers of Bitcoin’s evolution.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Amir Taaki, Bitcoin Improvement Proposal #1 (2011)
• Luke Dashjr, BIP2: BIP Process, revised (2016); M. Erhardt, BIP3: Updated BIP Process (2025)
• github.com/bitcoin/bips