Process: Activate BIP3

[murchandamus]

This pull request depends on the commits in #1819 and therefore is still only a draft pull request.

However, this is what the application of the changes prescribed by BIP 3 in the section Updates to Existing BIPs should this BIP be Activated would look like. The first commit of this pull request is process: Activate BIP3.

Todos:

• [x] Update of the CI-scripts
• [ ] 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.

[murchandamus]

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]

Rebased on the latest version of #1819.

[ajtowns]

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

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

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]

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]

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]

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]

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]

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]

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

[real-or-random]

@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.

[ajtowns]

Is this waiting on anything?

[murchandamus]

Is this waiting on anything?

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

[murchandamus]

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]

Concept ACK

[davidgumberg]

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]

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]

+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/.

[murchandamus]

ACK dbf2a3f

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

[murchandamus]

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]

(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]

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]

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.)

[polespinasa]

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]

Concept ACK

[melvincarvalho]

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]

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.

1. RFC 7282: visible objection handling
2. 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).

3. 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.

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.

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."