BIP 2 vs BIP 3: the old and new BIP process
BIP 3, written by Murch, replaced Luke Dashjr's BIP 2 as the rulebook for how Bitcoin Improvement Proposals are written, numbered and tracked. The most visible change is the status field: BIP 2's nine statuses were reduced to four (Draft, Complete, Deployed and Closed), and the Standards Track type became Specification.
Updated · 4 min read
At a glance
| BIP 2 | BIP 3 | |
|---|---|---|
| Title | BIP process, revised | Updated BIP Process |
| Status | Closed | Deployed |
| Type | Process | Process |
| Assigned | 2016-02-03 | 2025-01-09 |
| Authors | Luke Dashjr | Murch |
| In plain English | A revised version of the proposal process that replaced BIP 1, clarifying how proposals move between statuses, how comments are gathered, and which licenses are allowed. It aimed to make the path from idea to accepted standard more predictable. | Replaces BIP 2 with a streamlined set of rules for preparing, submitting and publishing proposals, including the role of the editors who manage them. It keeps the process workable as the number of contributors and proposals grows. |
What BIP 2 set out
BIP 2 replaced BIP 1 with a more defined process. A champion discussed the idea on the bitcoin-dev mailing list, opened a pull request, and a BIP editor assigned a number and labelled it Standards Track, Informational or Process. It used nine statuses: Draft, Proposed, Final, Active, Deferred, Rejected, Withdrawn, Replaced and Obsolete.
BIP 2 tried to make status changes objective. A soft fork needed a clear miner majority expressed through blockchain signalling before it could be Final, and API, RPC and application BIPs needed two independent, compatible implementations. A Draft or Proposed BIP could be marked Rejected, on anyone's request, if it had made no progress for three years. BIP 2 also added a wiki-based comment system, linked from Comments-URI and Comments-Summary headers in each BIP.
What BIP 3 changed
BIP 3 keeps the core flow, with the mailing list first, then a pull request, and editors assigning numbers, but simplifies it and moves several judgment calls from editors to authors and readers. Its "Changes from BIP 2" section lists, among others:
- Statuses: reduced from nine to four. Proposed was renamed Complete; Final and Active became Deployed; Deferred, Obsolete, Rejected, Replaced and Withdrawn were gathered into Closed.
- Types: Standards Track was superseded by Specification; Informational and Process remain.
- Comments: the wiki comment system and its headers were dropped, because few BIPs ever received comments.
- Stalled proposals: the three-year rejection rule is gone. A Draft can be Closed after a year without progress if its authors don't say within four weeks that they're still working on it, and a Complete BIP can stay Complete indefinitely unless its authors close it.
- Headers: Created became Assigned, Author became Authors, Post-History became Discussion and Superseded-By became Proposed-Replacement; optional Deputies and Version headers were added, and titles may now have 50 characters instead of 44.
- Changelog: changes after a BIP reaches Complete must be recorded with a version number, date and description.
- Licenses: written as SPDX expressions, with a shorter list of acceptable licenses for new BIPs.
- Process BIPs: treated as living documents that can be amended with rough consensus.
BIP 2 vs BIP 3 at a glance
| BIP 2 | BIP 3 | |
|---|---|---|
| Number of statuses | 9 | 4: Draft, Complete, Deployed, Closed |
| Types | Standards Track, Informational, Process | Specification, Informational, Process |
| Type chosen by | A BIP editor | The authors (editors check it) |
| Status for adopted BIPs | Final, by objective adoption criteria per layer | Deployed, on evidence of active use such as mainnet releases or met activation criteria |
| Inactive proposals | Rejected after 3 years without progress, on request | Draft may be Closed after 1 year; Complete may stay indefinitely |
| Community comments | Wiki pages linked from the header | Removed |
| Tracking changes | Git history | Git history plus a Changelog section and Version header |
| Helpers besides authors | None defined | Optional Deputies |
How BIP 2 statuses map to BIP 3
| BIP 2 status | BIP 3 status |
|---|---|
| Draft | Draft |
| Proposed | Complete |
| Final, Active | Deployed |
| Deferred, Rejected, Withdrawn, Replaced, Obsolete | Closed |
BIP 3 says that after its activation, existing BIPs whose status didn't fit were updated to the corresponding new values. That is why every BIP on this site shows one of the four new statuses. Browse them on the Deployed, Complete, Draft and Closed lists.
What it means for you
If you read BIPs, Deployed now means "in active use" and Closed means "of historical interest only", whatever the original reason. BIP 3 also stresses that a BIP is its authors' recommendation, not a decision: "No formal or informal decision body governs Bitcoin development or decides adoption of BIPs."
If you write a BIP, follow BIP 3: discuss the idea in a dedicated thread on the Bitcoin Development Mailing List first, choose Specification, Informational or Process, use an acceptable license, include a reference implementation and test vectors before moving a Specification BIP to Complete, and keep a Changelog after that. What is a BIP? covers the basics, and the BIP glossary entry gives a short definition.
Frequently asked questions
What are the BIP statuses under BIP 3?
There are four. Draft means the proposal is being worked on; Complete means the authors consider it finished and recommend adoption; Deployed means it is in active use, shown by evidence such as mainnet releases or a soft fork's activation; Closed means it is of historical interest only, whether abandoned, rejected or replaced. They replace the nine statuses of BIP 2.
What happened to the Final and Active statuses?
BIP 3 merged both into Deployed. Final was BIP 2's status for adopted specifications, and Active its status for Process BIPs that had reached rough consensus. Proposed became Complete, and Deferred, Rejected, Withdrawn, Replaced and Obsolete all became Closed. For future moves to Closed, BIP 3 asks that the reason be recorded in the BIP's Changelog.
What replaced Standards Track BIPs?
The Specification type. BIP 3 explains that some interoperable features had been filed as Informational because Standards Track was misread as a general recommendation. Specification covers any BIP that can be implemented and complied with, and it needs a reference implementation and test vectors before it can be marked Complete.
Who decides whether a BIP is accepted?
Nobody, formally. BIP 3 states that no formal or informal decision body governs Bitcoin development or decides adoption of BIPs. A BIP is its authors' recommendation; editors check that it is on-topic, well-formed and sound, but do not judge whether it is likely to be adopted. Adoption happens when projects and users choose to implement it.
Why is the BIP date now called Assigned?
BIP 3 renamed the Created header to Assigned because authors had been filling in different dates: when they started writing, when they opened a pull request, or when they got a number. BIP 1 and BIP 2 both described the field as the date the number was assigned, so the new name matches the rule.