Since 2024, Bitcoin developer Mark “Murch” Erhardt has logged over 210 hours on a project to improve how Bitcoin improves. His reviewers contributed hundreds more reading drafts, leaving feedback, and debating edge cases. Murch conservatively estimates “over 300 hours” were spent on the effort, he told Blockspace.
The result is BIP 3, the first major overhaul to Bitcoin’s Improvement Proposal (BIP) process since 2016.
BIP 3 is now officially active, replacing the old BIP 2 as the de-facto document for how BIPs get submitted, reviewed, and tracked. With BIPs, developers can propose changes to Bitcoin’s code, how the code is managed, and the other janitorial aspects of maintaining Bitcoin’s codebase.
The way Bitcoin changes at a network level is intentionally ambiguous and murky, but the process for defining the proposals to change Bitcoin doesn’t have to be. That’s what the BIPs repo essentially does: catalogues and tracks proposed changes to Bitcoin.
BIPs are tracked by numbers in a github repository (BIP 1, BIP 148, etc) but the process for assigning numbers, standardizing, and navigating discussion of the proposals, has been somewhat dysfunctional over the years.
While you would think it should be a strictly technical process, it has been a point of friction for Bitcoin in recent years due to unclear procedural definitions and, of course, the frictious human element of code review.
BIP2 was the BIP that defined how BIPs should be submitted to the repository, but it had some issues (explained later). So one of the first orders of business in repairing the BIPs process is fixing the process itself.
That’s where BIP3 comes in, and after two years, it is now live.
Why Bitcoin needs BIP 3
In early 2024, the process for code changes had ground to a halt. Pull requests sat unreviewed for months. Proposals like Ordinals and OP_CAT couldn’t get numbers assigned.
In February, Ava Chow posted to the mailing list proposing new editors be added. “The problem was that Luke was the only BIP editor,” she explained. “It just ended up being that Luke didn’t have time for this.”
In response, five new editors were appointed: Murch, Bryan “Kanzure” Bishop, Ruben Somsen, Roasbeef, and Jon Atack.
What BIP 3 changes about the Bitcoin Improvement Proposal process
BIP3 simplifies the entire Bitcoin improvement proposal process. Here’s what’s different:
Nine statuses become four. The old system had nine different statuses (Draft, Proposed, Final, Active, Deferred, Withdrawn, Rejected, Obsolete, and Replaced). Now there’s just Draft, Complete, Deployed, and Closed.
Editors check formatting, not merit. Under BIP 2, editors were supposed to evaluate “technical soundness.” In practice, this created bottlenecks and accusations of gatekeeping. BIP3 makes it explicit: editors simply verify that proposals are on-topic and properly formatted. Editors are less on the hook for judgement of the proposal. That’s left up to the community of engaged developers.
“Specification” replaces “Standards Track.” This fixes longstanding confusion about what made something a “standard.” The new label is clearer: if you can implement it and check compliance, it’s a Specification BIP.
Process BIPs become living documents. This one is subtle but important. Under the old rules, all BIPs were supposed to never change once finalized. But that created absurd situations. Murch explained: “It doesn’t make sense to require a whole new BIP to change a line in the process.” This only applies to Process BIPs, which are BIPs that just define procedural convention and not major things like Bitcoin consensus.
New BIP feature: Deputies
BIP 3 introduces a new concept called “Deputies.” These are stand-in owners/helpers of the BIP who can shepherd a BIP when authors themselves need help, want to just stick to the code, or want to disappear.
Murch is pretty candid about whether this will actually get used.
“The Deputies came out of a few instances in which other people took over ownership of BIPs recently, or helped an Author out temporarily. I’m a little on the fence about it in hindsight. I think it might end up not being used a lot, and then it would just have been a needless complication of the process,” he told Blockspace.
But this is also where the “living document” nature of Process BIPs comes into effect. If Deputies aren’t working out, they could be removed from the BIP3.
The long road to BIP 3
BIP3 took nearly two years from conception to activation. A brief timeline:
- February 2024: Ava Chow proposes adding new BIP editors
- April 2024: Five new editors appointed
- Mid-2024: Murch begins drafting BIP 3
- 2024 – 2025: Lots of discussion, review, revisions.
- January 2026: BIP 3 goes live, BIP 2 marked as closed
“My reviewers contributed lots of great ideas,” Murch said. “The updated license format by Tim Ruffing, improvements to the CI script by AJ and Yuval, lots of suggestions to naming, and lots of phrasing improvements especially by Jon.”
A part that might surprise you: people were already following BIP 3 when submitting code before it was official.
“In the past few months we often had people submit already with formatting following BIP3 guidance,” Murch noted. “So I think it was causing friction to have it on the cusp.”
How BIP 3 got activated (the thorny question)
Process BIPs like this one face a unique challenge. They require “rough consensus” to activate but Bitcoin doesn’t have a voting body, no formal definition of what “rough consensus” is.
“Process BIPs are unique in that they need Rough Consensus to be deployed,” Murch explained. “And since we don’t have a well-defined set of participants of the BIP Process, it’s not obvious how to measure if rough consensus has been achieved.”
For Specification BIPs — technical proposals — the signal is clearer. Projects either deploy support on mainnet or they don’t. But process documents require reading social signals over weeks or months.
“It took a little longer than I had originally hoped when I asked people to comment in November,” Murch said. “But I think by just going from the people chiming in and giving them several more weeks, the signal eventually became clear.”
BIP3 seems to have rough social consensus. You can go read the 4 PRs yourself, the multiple mailing list discussions, or just ask Claude to summarize it for you.
Initial responses have been positive but, as with all things Bitcoin development, time will have to tell!
