Process: Activate BIP3

murchandamus commented at 3:32 am on April 12, 2025: contributor

This is a first draft of applying the changes prescribed by BIP 3 in the section Updates to Existing BIPs should this BIP be Activated.

It also updates the CI-scripts to align with the new formatting.

Resolved:

@real-or-random’s proposal to update the Licensing scheme
Enforce order of headers in Preamble and fix order in BIPs that don’t conform

Planned for follow-up or parallel PRs:

Evaluate Informational BIPs regarding update to Specification type
BIPs that have had Draft status for extended periods will be moved to Complete or Deployed as applicable in collaboration with their authors.
The authors of incomplete Draft BIPs will be contacted to learn whether the BIPs are still in progress toward Complete, and will otherwise be updated to Closed as described in the Workflow section above.
Make changes or remove non-existent BIPs 40, 41, and 63 (breaks CI)

Assessed Rough Consensus for Activation

ACKs/concept ACKs

The following users have expressed support for activating BIP 3 here on this pull request:

Stale ACKs from before #2051

Useful links

murchandamus added the label Pending acceptance on Apr 12, 2025

murchandamus added the label Process on Apr 12, 2025

murchandamus force-pushed on Apr 12, 2025

in bip-0001.mediawiki:4 in 4c67644571 outdated

0@@ -1,13 +1,11 @@
1 <pre>
2   BIP: 1
3   Title: BIP Purpose and Guidelines
4-  Author: Amir Taaki <genjix@riseup.net>
5-  Comments-Summary: No comments yet.
6-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
7-  Status: Replaced
8+  Authors: Amir Taaki <genjix@riseup.net>

jonatack commented at 1:00 pm on April 13, 2025:

Looks like scripts/buildtable.pl will need to be updated for the BIP3 headers changes.

jonatack commented at 1:04 pm on April 13, 2025:

e.g. update the required fields, Author -> Authors, remove the comments, update title length, update the licenses, update %MiscField, add checks for new fields like Deputies, etc.

murchandamus commented at 6:51 pm on April 14, 2025:

Thanks yes, I’m working on that today.

murchandamus commented at 9:04 pm on April 14, 2025:

@jonatack: This should be done

murchandamus force-pushed on Apr 14, 2025

murchandamus commented at 9:03 pm on April 14, 2025: contributor

I have updated the scripts/buildtable.pl in lock step with each of the changes so that the build script passes for every commit. The remaining tasks should probably be handled in follow-ups as they will take a variable amount of time.

murchandamus force-pushed on Jun 20, 2025

murchandamus commented at 10:46 pm on June 20, 2025: contributor

Rebased on the latest version of #1819.

murchandamus force-pushed on Jun 20, 2025

murchandamus force-pushed on Jun 21, 2025

murchandamus commented at 0:50 am on June 21, 2025: contributor

I can’t reproduce the scripts/diffcheck.sh error locally either with the latest commit of this branch, by bisecting, or after merging the latest upstream/master. I’m thinking that the next step is to improve the script with a more helpful error message, but I’m not going to pursue that today.

ajtowns commented at 5:42 am on July 1, 2025: contributor

You can reproduce the error message and get more info with:

0$ git checkout 187d8859dce80c8433ff7466d012b5dd78ac3136   # master's parent commit (to avoid the conflict)
1$ git merge 5e776c4c92d0a33c15311c7289139835132f2fec      # this PR
2$ scripts/diffcheck.sh
3...
4$ diff -u -B5 /tmp/before.diff /tmp/after.diff
5...

It’s complaining that there are differences in the summaries of BIPs 40 (“Stratum wire protocol”), 41 (“Stratum mining protocol”), and 63 (“Stealth addresses”); which are all changing from “Standard” to “Specification”, but only exist as assigned numbers, with no actual document in the repo. They’re all more than a decade old based on git blame’s output, so could probably just be removed from the README entirely (though doing that would also trigger the same set of errors).

ajtowns commented at 6:39 am on July 1, 2025: contributor

I wonder if it would be worthwhile splitting the list of BIPs in the README by status. I’ve had a go at that in a gist here, including an update for the perl script: https://gist.github.com/ajtowns/5a8c504b6ef0e91437614be2840921d7#file-test-mediawiki (also changed the link text to be BIP-nnn instead of just nnn, to make searching for “bip-3” easier)

murchandamus commented at 1:28 am on July 8, 2025: contributor

It’s complaining that there are differences in the summaries of BIPs 40 (“Stratum wire protocol”), 41 (“Stratum mining protocol”), and 63 (“Stealth addresses”);

Thanks for figuring that out. I was starting to doubt my sanity that evening. :)

They’re all more than a decade old based on git blame’s output, so could probably just be removed from the README entirely (though doing that would also trigger the same set of errors).

I guess I should remove or relabel them in a separate PR, then.

I wonder if it would be worthwhile splitting the list of BIPs in the README by status. I’ve had a go at that in a gist here, including an update for the perl script: https://gist.github.com/ajtowns/5a8c504b6ef0e91437614be2840921d7#file-test-mediawiki (also changed the link text to be BIP-nnn instead of just nnn, to make searching for “bip-3” easier)

I like the change to “BIP-nnn”; it looks nice. And sorting by status neatly highlights what’s deployed, but it not being sorted by numbers looks awfully strange to me—I have probably been staring at it too long that way. It might get some people motivated to update their BIPs to a more adequate status?

However, this Pr already has a lot going on, making me concerned that it will get review, I’m not sure I’d want to open up that can of worms in addition, especially being on the fence.

murchandamus force-pushed on Jul 8, 2025

murchandamus commented at 1:53 am on July 8, 2025: contributor

Thanks @ajtowns! It passes CI now. @real-or-random, what do you think is the best course of action? It would probably make sense to first get the licensing update you propose in?

ajtowns commented at 7:52 am on July 8, 2025: contributor

I wonder if it would be worthwhile splitting the list of BIPs in the README by status.

I like the change to “BIP-nnn”; it looks nice.

However, this Pr already has a lot going on,

I wasn’t meaning to imply it should be part of this PR; my understanding was further improvements could still be made once BIP-3 was active.

murchandamus commented at 2:39 pm on July 8, 2025: contributor

Ah sorry, I misunderstood that. Yeah, afterwards sounds good to me, as the reordering of the README table would conflict with all of the changes here.

murchandamus commented at 8:11 pm on July 8, 2025: contributor

Cherry-picked the commit from #1891 to add support for the Version field to scripts/buildtable.pl, thanks @nothingmuch.

real-or-random commented at 10:03 am on July 9, 2025: contributor

@real-or-random, what do you think is the best course of action? It would probably make sense to first get the licensing update you propose in?

See #1892.

murchandamus added the label PR Author action required on Jul 16, 2025

ajtowns commented at 4:26 am on August 27, 2025: contributor

Is this waiting on anything?

murchandamus commented at 9:55 pm on September 16, 2025: contributor

Is this waiting on anything?

Mostly me needing to redo the work here to rebase on top of the many changes. Also #1970.

murchandamus force-pushed on Oct 8, 2025

murchandamus removed the label PR Author action required on Oct 8, 2025

murchandamus marked this as ready for review on Oct 8, 2025

murchandamus commented at 10:13 pm on October 8, 2025: contributor

Some hours of resolving merge conflicts, redoing edits, and adding the “Created ↦ Assigned” header update, each commit is now passing the buildtable.pl. This should now be ready to deploy, whenever it has been reviewed and the community is ready.

achow101 commented at 10:24 pm on October 8, 2025: member

Concept ACK

murchandamus removed the label Pending acceptance on Oct 8, 2025

davidgumberg commented at 11:26 pm on October 8, 2025: none

Concept ACK, +1 to @ajtowns suggestion of having BIPs organized by status (somewhere, doesn’t necessarily have to replace the numbered list), but I agree with @murchandamus that this should happen in a later PR.

murchandamus commented at 1:19 am on October 9, 2025: contributor

having BIPs organized by status

I just took a look at that again, and noticed that the table in the README is already a "wikitable sortable", but a little more search tells me that GitHub only translates the MediaWiki format to Markdown under the hood, and sortable tables are actually not supported. It might simply not be something that we can natively support in the README, but perhaps the bips repo could also be published as a github.io page at some point or something similar. (Just an idea, not signing up to drive that. ;))

polespinasa commented at 0:17 am on October 10, 2025: member

+1 to @ajtowns and @davidgumberg.

perhaps the bips repo could also be published as a github.io page at some point or something similar.

This could be a nice way to do it, something similar to https://bips.dev/status/.

in README.mediawiki:32 in edc21d1153 outdated

19@@ -20,20 +20,20 @@ Those proposing changes should consider that ultimately consent may rest with th
20 | Amir Taaki
21 | Process
22 | Replaced
23-|- style="background-color: #cfffcf"
24+|- style="background-color: #ffcfcf"

polespinasa commented at 0:21 am on October 10, 2025:

Just curiosity, what do these color changes do? I don’t see any difference in the original file vs. this commit version.

murchandamus commented at 9:02 pm on October 10, 2025:

TBH, I think this is another feature that simply doesn’t render in GitHub. Presumably, it does something when you render the MediaWiki files locally.

in README.mediawiki:38 in 3fa1613c68 outdated

35 |
36 | BIP process, revised
37 | Luke Dashjr
38 | Process
39-| Replaced
40+| Closed

polespinasa commented at 0:46 am on October 10, 2025:

Shouldn’t all closed be background-color: #ffcfcf ? #cfffcf is used for deployed ones if I understood correctly.

(If so, there are multiple files with the wrong color)

murchandamus commented at 9:08 pm on October 10, 2025:

Is it possible that you are getting the grouping of the lines mixed up? Rows start on the lines with |- and the last line belonging to the row has the Status column:

in bip-0135.mediawiki:5 in ebd0e00f00 outdated

1@@ -2,9 +2,7 @@
2   BIP: 135
3   Title: Generalized version bits voting
4   Author: Sancho Panza <sanch0panza@protonmail.com>
5-  Comments-Summary: No comments yet.
6-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0135
7-                https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/
8+	  https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/

polespinasa commented at 0:51 am on October 10, 2025:

why is this link left here under.

polespinasa commented at 0:57 am on October 10, 2025:

Oh I see it’s moved in the next commit ea78303c827c9be35f0bc60a47ac53d3af36b85c Can’t this two just be squashed?

murchandamus commented at 9:11 pm on October 10, 2025:

Given the large amount of changes, I would prefer to keep the commits clear in their purpose, but perhaps it would be better to move the fixes to preambles earlier in the sequence of commits, so that this whitespace amendment to make sure the line is indented correctly isn’t as confusing.

murchandamus commented at 9:26 pm on October 10, 2025:

I reordered the fix to the Preamble of BIP 135 and the Renaming of Post-History to Discussion to go before dropping the Comments-URI and Comments-Summary, so the sequence of changes should now make more sense.

polespinasa commented at 1:12 am on October 10, 2025: member

ACK c356d8e1b5ed90bc63e971fb1cb927bcaecec57b

lgtm, didn’t run scripts locally but checked the changes on github.

murchandamus commented at 9:11 pm on October 10, 2025: contributor

Thanks for the reviews

murchandamus force-pushed on Oct 10, 2025

jonatack commented at 8:16 pm on October 21, 2025: member

ACK dbf2a3f2df7b07585710f5146d98072e38339819

murchandamus commented at 2:22 pm on October 22, 2025: contributor

ACK dbf2a3f

Sorry, I noticed today when looking through the blame that we were still missing the License update which has now been added.

in bip-0002.mediawiki:8 in f9afaf97c7

 4@@ -5,8 +5,7 @@
 5   Status: Closed
 6   Type: Process
 7   Assigned: 2016-02-03
 8-  License: BSD-2-Clause
 9-           OPL
10+  License: BSD-2-Clause OR OPL

jonatack commented at 4:29 pm on October 22, 2025:

Not sure which license “OPL” corresponds to in https://spdx.org/licenses/

jonatack commented at 4:36 pm on October 22, 2025:

idem for “GNU-All-Permissive”

jonatack commented at 4:38 pm on October 22, 2025:

FWIW per https://spdx.dev/learn/handling-license-info/#how, though it pertains to the per-file header:

0  SPDX-License-Identifier: BSD-2-Clause OR OPL

real-or-random commented at 4:41 pm on October 22, 2025:

Was just in the middle of working on a commit that addresses OPL and GNU All Permissive. :D

real-or-random commented at 4:46 pm on October 22, 2025:

(FWIW per spdx.dev/learn/handling-license-info#how):

Yeah, we could do this. Concept ~0. This makes it easier for automated tools (but do we really care?) and it makes it unambiguously clear that this is an SPDX License Expression (but BIP3 also makes this clear). The drawback is that (I think) it looks a bit less nice because then the line stands a bit out among the other lines in the BIP header.

jonatack commented at 5:48 pm on October 22, 2025:

Yes, I don’t have a strong opinion.

murchandamus commented at 8:15 am on October 23, 2025:

I’m gonna pull in the change by @real-or-random to update the instances of OPL and GNU-All-Permissive, but I prefer leaving it in the preamble format.

ajtowns commented at 12:48 pm on October 23, 2025:

FWIW per https://spdx.dev/learn/handling-license-info/#how, though it pertains to the per-file header:

That’s appropriate for giving full context for something added to an existing (source/doc) file where there’s no particular reason to expect a license identifier in the first place. But here we have a definition of what the headers mean, so I think being briefer is fine. We’re just saying License: <spdx-license-identifier/expression> rather than having <spdx-short-form-identifier> as a header directly.

real-or-random approved

real-or-random commented at 3:35 pm on October 23, 2025: contributor

ACK b74629f56e9fa984dd0b53a4148afa575c8f9a04 let’s activate this

jonatack commented at 9:03 pm on October 23, 2025: member

ACK b74629f56e9fa984dd0b53a4148afa575c8f9a04

(nit, a few mentions of “GNU All-Permissive” that perhaps would be less confusing if changed to “FSF All Permissive” per https://spdx.org/licenses/FSFAP)

0bip-0104.mediawiki:75:This BIP is dual-licensed under the BSD 2-clause license and the GNU All-Permissive License.
1bip-0123.mediawiki:21:This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses.
2bip-0135.mediawiki:408:GNU All-Permissive licenses.

murchandamus commented at 11:47 am on October 24, 2025: contributor

Thanks, @jonatack, I amended those three spots to reference FSF All Permissive instead. I decided to not update the uses of GNU-All-Permissive in the BIP2 text, given that this PR would sunset it.

real-or-random commented at 5:33 pm on October 24, 2025: contributor

(nit, a few mentions of “GNU All-Permissive” that perhaps would be less confusing if changed to “FSF All Permissive” per spdx.org/licenses/FSFAP)

I kept them intentionally because i) “GNU All-Permissive” is how GNU calls this license (see https://www.gnu.org/licenses/license-list.en.html#GNUAllPermissive) and ii) I think we shouldn’t edit the contents of the copyright sections. It’s really a declaration from the authors.

But yeah, I also don’t oppose changing them.

jonatack commented at 5:49 pm on October 24, 2025: member

Yes, it’s the discrepancy with the “FSFAP” license headers in those BIPs that gave me pause.

Maybe write “GNU All-Permissive License (editor note: equivalent to FSF All-Permissive License)” – if that is correct.

real-or-random commented at 8:14 am on October 25, 2025: contributor

Yes, it’s the discrepancy with the “FSFAP” license headers in those BIPs that gave me pause.

I guess anyone who really wants to know will figure out that FSFAP is the SPDX identifier for what GNU calls the GNU All-Permissive license. Sure, it’s not elegant but it’s how it is.

Maybe write “GNU All-Permissive License (editor note: equivalent to FSF All-Permissive License)” – if that is correct.

I don’t think that’s better. They’re not just equivalent; these are just two names for the same paragraph of text. That’s why the change doesn’t affect the meaning, and no one can reasonably complain about it.

I just tend to think it’s not the editors’ job to edit the Copyright section. For example, it’s a bad idea from a legal point of view to change copyright notices, and it’s a similarly bad idea to change license notices. (Almost all licenses out there, even the most permissive ones, require you to keep the license notice when distributing the work.)

jonasnick commented at 9:47 am on October 27, 2025: contributor

I’m in favor of activating BIP 3. Concept ACK.

in bip-0341.mediawiki:14 in faed340067 outdated

10@@ -11,8 +11,8 @@
11   Type: Specification
12   Created: 2020-01-19
13   License: BSD-3-Clause
14-  Post-History: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal
15-                2019-10-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017378.html [bitcoin-dev] Taproot updates
16+  Discussion: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal

glozow commented at 6:33 pm on October 27, 2025:

I notice BIP 3 Format and Structure says

0* Discussion: <Noteworthy discussion threads in "yyyy-mm-dd: URL" format>

But previous formatting includes a title as well.

murchandamus commented at 0:51 am on November 6, 2025:

Strictly speaking, the header was then not compliant with BIP 2, which took either a date or a link. Are you suggesting that the Discussion header lines should additionally allow an optional title?

0* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>
… Post-History is used to record when new versions of the BIP are posted to bitcoin mailing lists. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14. Post-History is permitted to be a link to a specific thread in a mailing list archive.

glozow commented at 5:00 pm on November 6, 2025:

Are you suggesting that the Discussion header lines should additionally allow an optional title?

Yes. I may have misinterpreted “yyyy-mm-dd: URL” as precluding any other text being there.

glozow commented at 6:51 pm on October 27, 2025: member

ACK 7749fa2fca4718c017d4f13fa07ed2726b83ff0f

Concept ACK to activating. I think the author has done a good job addressing concerns and gave ample time for people to chime in. I had a look around the google groups discussions, this PR, #1794, #1712 and think this is widely supported.

I had a cursory look at the commits updating statuses and types, and they look correct to me. CI is updated and green, and other minor updates can be in followups.

polespinasa commented at 9:44 pm on October 27, 2025: member

ACK 7749fa2fca4718c017d4f13fa07ed2726b83ff0f

Just did a fast check on the new commits updating the license; changes make much sense to me, although I don’t have a strong opinion on the format discussion. I agree with @real-or-random about not modifying copyright sections (although I don’t believe in intellectual property 🙃).

ACK on activating :fire:

fanquake commented at 11:21 am on November 5, 2025: member

Concept ACK

Penya1313 commented at 8:40 pm on November 9, 2025: none

💪

melvincarvalho commented at 5:05 pm on November 14, 2025: none

I’m writing in response to Murch’s motion to activate BIP 3. I appreciate both the extensive work that’s gone into this proposal and the invitation to raise concerns during this evaluation period.

Since BIP 3 cites RFC 7282 as its rough consensus framework, I reviewed it with that standard in mind. BIP 3 modernizes many aspects of the process, particularly the streamlined status flow and clearer role definitions, and I appreciate these improvements. I’ve spent some time in IETF and W3C processes over the years, including recommending RFC 7282 to this list during the Taproot discussions, so some of the thoughts below reflect lessons learned from those environments. That said, Bitcoin’s governance context is unique, and I may be missing important considerations.

1. RFC 7282: visible objection handling

RFC 7282 emphasizes that rough consensus is demonstrated by documenting objections and how they were addressed. Process BIPs under BIP 3 can self-modify without requiring such a log, which leaves ambiguity around how consensus is determined. A short objections/resolution record, even as simple as a changelog section noting “Objection raised by X regarding Y; addressed by Z”, would address this and provide helpful context for future readers.

2. RFC 7282: neutral consensus evaluation

RFC 7282 discourages authors from judging consensus on their own work. Under BIP 3, a small editor group collectively evaluates numbering, closure, “material progress,” “lack of interest,” and rough consensus itself. This concentration of authority may create perceived conflicts of interest, even with the best intentions.

A minimal safeguard would be requiring two non-author editors, ideally from different implementation communities such as Core and Knots, to confirm rough consensus for Process BIPs. This shares responsibility and provides independent verification. For example, if a Process BIP proposes changing the Draft-to-Complete threshold, this would ensure independent assessment.

3. Subjectivity in number assignment

Declining numbers due to “lack of interest” or “insufficient progress” is reasonable in intent but subjective in effect. A brief explanation, even a single sentence in the PR, would help newcomers understand expectations and provide editors with a neutral reference point if a decision is later questioned.

4. Status compression and historical clarity

Collapsing Rejected/Withdrawn/Obsolete into “Closed” simplifies the system but loses useful distinctions that help readers understand why a proposal didn’t advance. Optional status annotations (e.g., “Closed (Withdrawn by author)” or “Closed (Superseded by BIP X)”) could preserve this context without complicating the core status model.

Lightweight adjustments for RFC alignment and neutrality
Short objections/resolution log for Process BIPs (can be minimal changelog format)
Neutral consensus verification by two non-author editors, preferably cross-ecosystem
Brief explanations for number denials and “stalled” Draft BIPs
Optional annotations for Closed statuses to preserve historical context

These small additions strengthen neutrality and transparency. They also help editors by distributing responsibility and making decisions easier to defend through a clear paper trail. I recognize editors are volunteering substantial time, and these mechanisms are intended to make the role more sustainable, not more burdensome.

I may have overlooked important practical constraints or misunderstood parts of the current process. I’d be interested to hear whether others see value in these additions, have alternative approaches to strengthening neutrality around Process BIPs, or believe the current design better serves Bitcoin’s governance needs.

Looking forward to the discussion.

real-or-random commented at 10:00 am on November 17, 2025: contributor

BIP 3 cites RFC 7282 as its rough consensus framework,

This is not true. BIP 3 cites RFC 7282 as “Related Work”. This indicates in no way that RFC 7282 forms a framework for BIP 3.

RFC 7282: visible objection handling

RFC 7282: neutral consensus evaluation

In any case, a fundamental difference between the processes in the IETF and in the Bitcoin community (which the author of the comment posted under your account appears to be aware of) is that the BIP process requires “rough consensus” only when it comes to Process BIPs. Process BIP are proposed very rarely: In over 14 years, we saw no more than five instances. Substantial changes to Process BIPs are similarly rare. I believe that such rare events do not justify adding more rules (unless it turns out in the future that they are warranted).

Subjectivity in number assignment

[…] A brief explanation, even a single sentence in the PR, would help newcomers understand expectations and provide editors with a neutral reference point if a decision is later questioned.

I agree. But nothing in BIP 3 stops editors from writing such a sentence. A rule that mandates such a sentence would be an unreasonably detailed requirement given the trust we put in BIP editors anyway.

Status compression and historical clarity

Collapsing Rejected/Withdrawn/Obsolete into “Closed” simplifies the system but loses useful distinctions that help readers understand why a proposal didn’t advance. Optional status annotations (e.g., “Closed (Withdrawn by author)” or “Closed (Superseded by BIP X)”) could preserve this context without complicating the core status model.

BIP 3 states: “The reason for moving the proposal to (or from) Closed should be recorded in the Changelog section in the same commit that updates the status.”

murchandamus force-pushed on Dec 16, 2025

murchandamus commented at 1:02 am on December 16, 2025: contributor

This PR was updated to build on top of #2051. It cleanly rebased, since no BIPs had been published or had their statuses updated since the prior update of this PR on Oct 6.

I added one commit to backfill the omitted Version headers to the BIPs that were already using Changelogs with versioning, BIP 3, BIP 77, BIP 85, BIP 155, BIP 352, and BIP 374. BIP 1 and BIP 340 have Changelogs, but did not define versions, so no Version header was added.

murchandamus force-pushed on Dec 16, 2025

ajtowns commented at 5:45 am on December 16, 2025: contributor

ACK 6cce55c343f1cb123c5594cb674304e2b6cca748 fwiw

real-or-random approved

real-or-random commented at 8:13 am on December 16, 2025: contributor

ACK 6cce55c343f1cb123c5594cb674304e2b6cca748

polespinasa approved

polespinasa commented at 4:58 pm on December 16, 2025: member

Somehow I missed #2051 :/

ACK 6cce55c343f1cb123c5594cb674304e2b6cca748

instagibbs commented at 1:52 pm on January 7, 2026: member

ACK on activation (did not review this PR’s 26 commits)

SatsAndSports commented at 3:42 pm on January 7, 2026: none

ACK on activation

michaelfolkson commented at 1:46 pm on January 12, 2026: none

ACK e2fcf8e420e9c249634f9e72e61b8bc748a54741

Exceptional work @murchandamus, seems a much improved process document to me.

A minor nit, I personally dislike the use of the word “activate” in the commit message, pull request header, BIP3 document etc given the connotations of (attempted) activations of consensus rule changes on the network. I’d prefer “merged” or “deployed” given the process for activating a process BIP bears little resemblance to the process for activating a consensus rule change on the network. Process BIPs can also be “modified indefinitely”, unlike consensus rule changes, and so I wouldn’t want to cause confusion that a consensus rule change can be activated in the same way as a process BIP. You’ve steered clear of discussing consensus rule changes in this document (understandably and perhaps wisely given the significant number of changes) but with indefinite modifications possible guidance on these could theoretically be added at a later date.

A Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. A proposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least one month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. Deployed Process BIPs may be modified indefinitely as long as a proposed modification has rough consensus per the same criteria.

EthanHeilman commented at 7:34 pm on January 12, 2026: contributor

ACK on activation

murchandamus commented at 10:10 pm on January 12, 2026: contributor

Thank you, I’ve added you all to the OP with links to your comments.

murchandamus commented at 10:19 pm on January 12, 2026: contributor

Exceptional work @murchandamus, seems a much improved process document to me.

Thanks!

A minor nit, I personally dislike the use of the word “activate” in the commit message, pull request header, BIP3 document etc given the connotations of (attempted) activations of consensus rule changes on the network. I’d prefer “merged” or “deployed” given the process for activating a process BIP bears little resemblance to the process for activating a consensus rule change on the network.

According to BIP 2, “a process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list.” Given that deployment/activation of BIP 3 is subject to BIP 2 rules, the terminology seems fitting to me. BIP 3 changes the term to Deployed which appears to match your preference.

Process BIPs can also be “modified indefinitely”, unlike consensus rule changes, and so I wouldn’t want to cause confusion that a consensus rule change can be activated in the same way as a process BIP. You’ve steered clear of discussing consensus rule changes in this document (understandably and perhaps wisely given the significant number of changes) but with indefinite modifications possible guidance on these could theoretically be added at a later date.

[…snip…] Deployed Process BIPs may be modified indefinitely as long as a proposed modification has rough consensus per the same criteria.

I’m not sure I see the issue here, @michaelfolkson. Changing a deployed Process BIPs requires the same process as deploying a Process BIP, so it doesn’t seem materially different in regard to scrutiny or difficulty whether done as a change to BIP 3 or as a new BIP.

process: Activate BIP3, close BIP2 4f412a4af0

process: Update README to match BIP3 68c12c7f7a

process: Clarify handling of controversial BIPs

It is preferable to close PRs over having them stuck in controversy
limbo indefinitely.

2f497a2bbe

process: Proposed ↦ Complete

Amend CI script to new statuses and update existing status field values
in table and BIPs.

```
sed -z -i 's/Status: Proposed/Status: Complete/' bip-0*.md
sed -z -i 's/Status: Proposed/Status: Complete/' bip-0*.mediawiki
sed -i 's/| Proposed/| Complete/' README.mediawiki
```

6760ba8738

process: Final/Active ↦ Deployed

```
sed -z -i 's/Status: Active/Status: Deployed/' bip-0*.md
sed -z -i 's/Status: Active/Status: Deployed/' bip-0*.mediawiki
sed -z -i 's/Status: Final/Status: Deployed/' bip-0*.md
sed -z -i 's/Status: Final/Status: Deployed/' bip-0*.mediawiki
sed -i 's/| Active/| Deployed/' README.mediawiki
sed -i 's/| Final/| Deployed/' README.mediawiki
```

5d3ceb3773

process: Deferred/Obsolete/Rejected/Replaced/Withdrawn ↦ Closed

```
sed -z -i 's/Status: Deferred/Status: Closed/' bip-0*.md
sed -z -i 's/Status: Deferred/Status: Closed/' bip-0*.mediawiki
sed -z -i 's/Status: Obsolete/Status: Closed/' bip-0*.md
sed -z -i 's/Status: Obsolete/Status: Closed/' bip-0*.mediawiki
sed -z -i 's/Status: Rejected/Status: Closed/' bip-0*.md
sed -z -i 's/Status: Rejected/Status: Closed/' bip-0*.mediawiki
sed -z -i 's/Status: Replaced/Status: Closed/' bip-0*.md
sed -z -i 's/Status: Replaced/Status: Closed/' bip-0*.mediawiki
sed -z -i 's/Status: Withdrawn/Status: Closed/' bip-0*.md
sed -z -i 's/Status: Withdrawn/Status: Closed/' bip-0*.mediawiki
```

```
    sed -i 's/| Deferred/| Closed/' README.mediawiki
    sed -i 's/| Obsolete/| Closed/' README.mediawiki
    sed -i 's/| Rejected/| Closed/' README.mediawiki
    sed -i 's/| Replaced/| Closed/' README.mediawiki
    sed -i 's/| Withdrawn/| Closed/' README.mediawiki
```

66defbdc03

process: Superseded-By ↦ Proposed-Replacement

sed -z -i 's/Superseded-By: /Proposed-Replacement: /' bip-0*.md
sed -z -i 's/Superseded-By: /Proposed-Replacement: /' bip-0*.mediawiki

ff1f3b36f8

process: Standards Track ↦ Specification

```
sed -z -i 's/Type: Standards Track/Type: Specification/' bip-0*.md
sed -z -i 's/Type: Standards Track/Type: Specification/' bip-0*.mediawiki
```

After the scripted changes, the changes to BIP-40, BIP-41, and BIP-63
were undone, because it breaks CI.

These three BIPs only exist conceptually and their proposal documents
are missing which causes changes to them ot break the CI. I defer the
changes to these BIPs to a separate pull request to get CI to pass.

a233bde4af

BIP135: Move discussion to correct header 863573ab0f

process: Post-History ↦ Discussion

Also line up with additional items in the lines below.

```
sed -i -z 's/  Post-History: /  Discussion:   /' bip-0*.md
sed -i -z 's/  Post-History: /  Discussion:   /' bip-0*.mediawiki
```

01352f7f40

process: Remove Comments-URI and -Summary

```
sed -i '0,/Comments-Summary/{/Comments-Summary/d}' bip-0*md
sed -i '0,/Comments-Summary/{/Comments-Summary/d}' bip-0*mediawiki
sed -i '0,/Comments-URI/{/Comments-URI/d}' bip-0*md
sed -i '0,/Comments-URI/{/Comments-URI/d}' bip-0*mediawiki
```

Then reset the BIPs with non-empty comment wikis:

- bip-0037.mediawiki
- bip-0038.mediawiki
- bip-0039.mediawiki
- bip-0042.mediawiki
- bip-0044.mediawiki
- bip-0047.mediawiki
- bip-0049.mediawiki
- bip-0060.mediawiki
- bip-0061.mediawiki
- bip-0074.mediawiki
- bip-0075.mediawiki
- bip-0077.md
- bip-0084.mediawiki
- bip-0090.mediawiki
- bip-0118.mediawiki
- bip-0125.mediawiki
- bip-0150.mediawiki
- bip-0151.mediawiki
- bip-0152.mediawiki
- bip-0171.mediawiki
- bip-0172.mediawiki
- bip-0173.mediawiki
- bip-0174.mediawiki
- bip-0176.mediawiki
- bip-0178.mediawiki
- bip-0199.mediawiki
- bip-0322.mediawiki
- bip-0340.mediawiki
- bip-0341.mediawiki

59730dec4f

process: Author ↦ Authors

```
sed -z -i 's/Author: /Authors: /' bip-0*.md
sed -z -i 's/Author: /Authors: /' bip-0*.mediawiki
```

Also align correctly in case of multiple authors.

5207ef92a5

process: Allow Deputies header 3fddf95984

process: Increase title limit fea4a0b0c5

process: Update license check b712509434

BIP372: Drop redundant Discussions-To Header

BIP2 states that the Discussions-To header should only be used if the
proposal was discussed somewhere else beside the Bitcoin Developer
Mailing List. Therefore, the only use of the Discussions-To header in
the repository is unnecessary and can be removed before the header is
abolished.

38f525beac

process: Drop unused Discussions-To Header 6829b943bd

editor: Remove outdated comment from README table ebefd42cc8

Allow `Version` field in checks as per BIP 3 85c9385e20

process: Created ↦ Assigned

```
sed -z -i 's/Created: /Assigned: /' bip-0*.md
sed -z -i 's/Created: /Assigned: /' bip-0*.mediawiki
```

24e96e870f

Convert licenses to SPDX codes 2885f13d3f

bip134: Remove wrong License header

The Copyright section specifies additional conditions, so the License
header is not correct (or at least misleading). So let's just remove it.
This is pragmatic because the field was only added as part of the
activation of BIP 2 anyway, and there are other old BIPs with a License
header.

7c3fab6fa7

bip2: Use correct SPDX license ids in the text

See https://spdx.org/licenses/

764409cb37

process: Use "official" SPDX identifiers

See https://spdx.org/licenses/

8586c32fa2

process: Fix up license sections to match preamble

Co-authored-by: Jon Atack <jon@atack.com>

76efa4aabf

murchandamus force-pushed on Jan 12, 2026

process: Backfill missing Version headers

…for BIPs that have a Changelog section that mentions a version.
BIP 1 and BIP 340 have Changelog sections, but do not define versions.

4486d6de91

murchandamus force-pushed on Jan 12, 2026

murchandamus commented at 10:42 pm on January 12, 2026: contributor

I rebased this PR to apply the BIP 3 activation changes to BIP 433: Pay to Anchor which has been merged recently.

After pushing the rebase, I realized that BIP 327 updated the version in its “Change Log” section for a recent bug fix, so I also added a version header for it in the last commit “process: Backfill missing Version headers” and renamed the section to “Changelog” to match the prevalent section title and BIP 3 specification.

You can find all the changes from these two pushes here: https://github.com/bitcoin/bips/compare/6cce55c343f1cb123c5594cb674304e2b6cca748..4486d6de91c9b46c256fec215f13fac818410a37

This PR should now apply all prescribed changes of the BIP 3 activation to existing BIPs and cleanly merge again.

fjahr commented at 2:34 pm on January 13, 2026: contributor

Concept ACK, I believe rough concensus for BIP3 has been reached. I have been adapting it for the BIP proposals I am involved with throughout the last few months already and I didn’t see any issues in the content of the BIP.

in bip-0155.mediawiki:10 in 4486d6de91

 6@@ -7,6 +7,7 @@
 7   Type: Specification
 8   Assigned: 2019-02-27
 9   License: BSD-2-Clause
10+  Version: 2.0.0

sipa commented at 4:16 pm on January 13, 2026:

Is this actually v2.0.0 of BIP155, or is the number taken from the fact that it introduces a addv2 message?

murchandamus commented at 4:51 pm on January 13, 2026:

In October, #1975 updated BIP155 to note that Tor v2 is deprecated, introduced a Changelog section and bumped the version to 2.0.0.

sipa commented at 4:17 pm on January 13, 2026: member

LGTM!

murchandamus commented at 7:26 pm on January 13, 2026: contributor

Regarding the proposed changes in #2037, I had addressed each of the six remaining suggestions already five weeks ago, explaining in each case why I did not accept the suggestion. The recent rebase merely resubmits exactly the same suggestions without any response to my explanations, so I consider all suggestions in #2037 already addressed.

RubenSomsen commented at 0:47 am on January 14, 2026: contributor

In my view this has rough consensus. @jonatack @kanzure @Roasbeef, what do you think? Ready for merge?

kanzure commented at 1:23 am on January 14, 2026: contributor

There seems to be rough consensus for activation.

Roasbeef approved

Roasbeef commented at 2:53 am on January 14, 2026: contributor

LGTM 🫛

in README.mediawiki:2 in 4486d6de91

0@@ -1,10 +1,19 @@
1-People wishing to submit BIPs, first should propose their idea or document to the [https://groups.google.com/g/bitcoindev bitcoindev@googlegroups.com] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
2+People wishing to submit BIPs should first describe their idea to the [https://groups.google.com/g/bitcoindev
3+bitcoindev@googlegroups.com] mailing list to get feedback on viability and community interested before working on a

jonatack commented at 5:01 pm on January 14, 2026:

Fixup for a follow-up (s/interested/interest/)

0bitcoindev@googlegroups.com] mailing list to gather feedback on viability and community interest before working on a

murchandamus commented at 5:23 pm on January 14, 2026:

That would be better, yeah.

jonatack commented at 8:51 pm on January 14, 2026:

Done in #2083.

jonatack commented at 5:06 pm on January 14, 2026: member

ACK 4486d6de91c9b46c256fec215f13fac818410a37

jonatack merged this on Jan 14, 2026

jonatack closed this on Jan 14, 2026

murchandamus commented at 5:46 pm on January 14, 2026: contributor

Thank you everyone for your input and support!

ajtowns commented at 7:21 am on January 15, 2026: contributor

Seems that the Discussion: headers are inconsistent amongst:

Discussion: url (no date - see BIP 3, 77, 93, 94, 99, 122, 124, 135, 300, 337, 374, 375)
Discussion: yyyy-mm-dd (just a date, no url - see BIP 11, 14)
Discussion: yyyy-mm-dd url (missing the colon after the date, see BIP 331)
Discussion: yyyy-mm-dd: url (what BIP3 specifies, see BIP 46, 326, 327, 340, 341, 342, 345, 347, 350, 352, 353, 388, 431, 433, 443)

(BIP 11 has a “Post History” section that just has the URL that should presumably go in the discussion header. For BIP 14, the only “post history” I can see is in the wiki, so https://en.bitcoin.it/wiki/Talk:BIP_0014 would be the corresponding discussion?)

murchandamus commented at 5:25 pm on January 15, 2026: contributor

Yeah, BIP 1 specified the Header as Post-History: <date>. BIP 2 specified it as Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>. I think the URL being present is the most important part, but with a URL, it should be quite easy to backfill the date and to fix the formatting.

The BIPs that were Closed should probably also be updated to get Changelogs that capture the reasoning why they were closed.

ajtowns commented at 2:39 am on January 16, 2026: contributor

Ah, BIP 14 links:

Process: Activate BIP3 #1820

Assessed Rough Consensus for Activation

ACKs/concept ACKs

Stale ACKs from before #2051

Useful links