How does a BIP go from draft to deployed?

You may have noticed a little post earlier this month about a motion to activate BIP 3 (#1274597). In the context of Bitcoin, "A motion to activate" may sound foreign, but never fear: it's all part of the loose set of practices that have gotten Bitcoin this far.

This particular motion was put forward by @murch, the author of BIP 3, who notes in his motion

Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I suggest that people who wish to state their support leave an ACK on #1820 or reply in this thread. Similarly, I would like to invite anyone to state concerns or raise objections here or on #1820. While BIP 3 has long been proposed and the activation PR has been open for over half a year, I suggest that we give all would-be reviewers another four weeks, until 2025-12-02, before evaluating whether there is rough consensus for merging the activation pull request. This should be ample time to review and discuss BIP 3 as well as the activation PR, even for people that have so far not engaged with the material.

You can learn quite a lot about Bitcoin from this paragraph. Notable highlights are:

There are BIPs
Activation is based on rough consensus
It's a slow process
There is a "we" (the BIP editors)

What is this BIP thing of which you speak?

BIP 3 replaces BIP 2 which replaced BIP 1 which describes how to write a BIP.

Amir Taaki¹ started the whole BIP process in 2011 when he proposed BIP 1 as a way to gather the information about proposed changes to Bitcoin and create a record of past proposals.

We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. - BIP 1

Modeling the BIP process on Python's PEPs, Taaki set in place a lot of the traditions that Bitcoin developers still follow today:

BIPs have a brief header identifying the author, the date it was created and some other info
There are three kinds of BIPs: Standards, Informational, and Process
A diagram of the BIP workflow (and a long description)
BIPs generally get announced on the Bitcoin developer mailing list first

Here's the diagram that was included in BIP 1:

And here is Taaki's original post proposing this system to the Bitcoin developers mailing list:

Making BIPs make more specific

Luke Dashjr proposed a BIP in 2016 that provided "clarifications on the Status field for BIPs"

This proposal became BIP 2 and largely kept the structure established by BIP 1 while adding a number of clarifications:

This Process BIP will require rough consensus from the Bitcoin-dev mailing list to become Active (see BIP 2 for the procedure, which I intend to use for its own activation due to absence of a clear process defined in BIP 1). -Luke Dashjr

Of course, BIP 2 provided a nice new diagram, too:

Here comes BIP 3

You may not be surprised to discover that my favorite part of BIP 3 is the new diagram:

Note that BIP 3's diagram looks a lot less complicated than the diagram for BIP 2. This is consistent with most of the changes that BIP 3 suggests.

Broadly, the changes that BIP 3 makes fit into one of two categories:

Simplifying the structure of a BIP
Reducing the places where BIP editors must make judgment calls

Some of the changes suggested by BIP 3 include removing the mandatory comment section on all BIPs (the BIP repository never really became a natural place for discussion, most comments being made on the mailing list or in the drafting phase of a BIP).

If you really want to go deep on BIP 3 and what it changes, check out this very detailed presentation by Jon Atack from earlier this year.

Some important points about BIPs

1. No one enforces BIPs 2. BIPs can be about anything in Bitcoin, not just block validation rules (consensus) 3. Things can change in Bitcoin without a BIP 4. BIP editors are caretakers

1. No one enforces BIPs. BIPs are proposals, they may be adopted by people working in Bitcoin or not. For instance, BIP 39 proposed a system for encoding private keys as a series of 12 or 24 "seed" words. While many wallets have adopted this BIP, some wallets have not. Even BIPs that affect block validation rules can be ignored -- although this can carry more risk. For instance, BIPs 340, 341, and 342 proposed changes that are collectively called Taproot. If you disagree with these chances, you can run an older version of Bitcoin Core and more or less ignore them.

2. BIPs can be about anything in Bitcoin, not just block validation rules (consensus). BIPs sometimes just describe a desired best practice (have a look at BIP 177). Anyone can propose a BIP and it the BIP can concern anything that is broadly relevant to the Bitcoin community.

3. Things can change in Bitcoin without a BIP. I don't have a good example for this, but the BIP process is meant to be something that allows Bitcoiners to better work together and describe clear standards that allow for better interoperability. If you have a really good idea for Bitcoin, it probably makes sense to follow the BIP process, but at the end of the day, it's possible to change Bitcoin without it.

4. BIP editors are caretakers. "BIP editors are do NOT evaluate whether the proposal is likely to be adopted." Their role is to keep the BIP repo clean and workable so that it remains useful for the community at large. One of the things BIP 3 does really well is clarify the role of BIP editors

So, how does a BIP go from draft to deployed?

In general, a BIP is first talked about as an idea in the Bitcoin community and on the Bitcoin developer mailing list. If it seems like a good idea, someone may write a draft of the idea following the BIP format. After more discussion and if there seems to be rough consensus that it is a good idea, the BIP editors may change the status of the BIP to active (BIP 2 uses active, BIP 3 uses deployed) in the BIPs repo. Then its up to Bitcoiners individually to decide whether they will follow the proposal or not.

Links

- BIPs repo - Reader friendly BIPs - Bitcoin Mailing List archive

One of the best things about Bitcoin is all the interesting people who have been involved with it. Amir Taaki was in Bitcoin from a very early point, active on BitcoinTalk in 2010, starting the Libbitcoin Project (originally SubvertX or SX) in 2011, organizing the first Bitcoin conference, setting up an exchange called Intersango, all before going to fight with Syrian Kurds. Taaki now works on a project called dark.fi ↩

222 sats \ 0 replies \ @Murch 2h

Thanks for the continued coverage, @Scoresby! Great write-up.

There is a "we" (the BIP editors)

Actually, I was thinking of “we” here as all of us, the self-selected participants of the BIP process.

Also, slightly embarrassing, your post here made me notice that BIP 2 actually already stated:

After working on BIP 3 for nearing two years, I thought that this section was something that was introduced in BIP 3. So, I was incorrect, when I stated that BIP 2 doesn’t specify how to activate process BIPs. Thank you for surfacing this. — Luckily, my proposed approach is compatible with BIP 2 either way.

123 sats \ 1 reply \ @k00b 2h

Thanks for writing this up. These process BIPs are so meta, so self-referential, it's easy to get lost in the sauce.

The main thing that stands out to me is that the process is minimally restrictive, yet restrictive enough to keep the BIP repo from getting trashy. I also appreciate the simplified state diagram. I found the prior ones confusing.

121 sats \ 0 replies \ @Scoresby OP 2h

I may have focused too much on the history rather than just explaining BIP 3 and why it's an improvement to the BIP process. Sadly, I'm a sucker for history.