From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Murch <murch@murch.one>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Fri, 14 Nov 2025 18:05:38 +0100 [thread overview]
Message-ID: <CAKaEYh+FHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg@mail.gmail.com> (raw)
In-Reply-To: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one>
[-- Attachment #1: Type: text/plain, Size: 7669 bytes --]
st 5. 11. 2025 v 2:11 odesílatel Murch <murch@murch.one> napsal:
> Dear list,
>
> After planned work on BIP 3⁰ finished in February, BIP 3 was advanced to
> Proposed in March 2025¹. A few minor adjustments were made to BIP 3
> since then (see below). I have since April maintained a pull request
> that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820.
>
> At this point, BIP 3 has received over 600 comments on GitHub and has
> been discussed in multiple threads on this list. The proposal has been
> Proposed for over seven months, and while several minor improvements
> were proposed and processed, the proposal has no unaddressed objections
> stated here or on the activation pull request. A growing list of people
> has expressed explicit support for activating BIP 3 by leaving an ACK on
> the pull request after reviewing the BIP:
> https://github.com/bitcoin/bips/pull/1820#issue-2990155954
>
> I formally propose a motion to adopt BIP 3 to replace BIP 2 as our BIPs
> Process.
>
> 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.
>
> Best,
> Murch
>
> ----
>
> Summary of changes since BIP 3 was advanced to Proposed:
>
> - The License header now uses SPDX License Expressions²
> - The License-Code header was dropped in favor of requiring that the
> license terms of the auxiliary files be specified in the respective
> directory or folder per a license header or LICENSE file²
> - The “Created” header has been renamed to “Assigned”³
> - The BIP text has been improved to clarify:
> - the purpose of the BIPs repository⁴
> - that authors should establish viability of their proposal on the
> mailing list⁴
> - the distinction between publication, acceptance, and adoption of
> proposals⁴
> - when Draft BIPs can be closed due to not making progress⁴
> - that BIPs submissions may not be generated by AI/LLM⁵
>
> ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md
> ¹ https://github.com/bitcoin/bips/pull/1794
> ² https://github.com/bitcoin/bips/pull/1892
> ³ https://github.com/bitcoin/bips/pull/1970
> ⁴ https://github.com/bitcoin/bips/pull/1819
> ⁵ https://github.com/bitcoin/bips/pull/2006
Hi all,
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.
Best,
Melvin
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYh%2BFHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9789 bytes --]
next prev parent reply other threads:[~2025-11-14 17:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 1:10 Murch
2025-11-05 1:53 ` Ruben Somsen
2025-11-12 19:03 ` [bitcoindev] " Greg Sanders
2025-11-13 0:23 ` Murch
2025-11-13 18:54 ` Greg Sanders
[not found] ` <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com>
2025-11-13 19:35 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-11-13 21:43 ` Murch
2025-11-14 17:05 ` Melvin Carvalho [this message]
2025-11-22 23:46 ` Murch
2025-11-29 23:00 ` Melvin Carvalho
2025-12-02 0:29 ` Murch
2025-11-15 22:01 ` Luke Dashjr
2025-11-18 4:26 ` Greg Maxwell
2025-12-02 22:46 ` Murch
2025-11-18 15:47 ` David A. Harding
2025-11-19 1:12 ` Greg Maxwell
2025-11-19 1:20 ` Bryan Bishop
2025-11-19 21:21 ` Jon Atack
2025-11-19 6:25 ` David A. Harding
2025-11-19 6:58 ` Bitcoin Error Log
2025-11-20 1:22 ` Bitcoin Mechanic
2025-11-20 9:06 ` Oghenovo Usiwoma
2025-11-20 17:23 ` Greg Maxwell
2025-11-22 15:14 ` Jon Atack
2025-11-22 19:30 ` Sjors Provoost
2025-11-22 20:53 ` /dev /fd0
2025-11-28 15:35 ` Tim Ruffing
2025-11-28 16:34 ` Jon Atack
2025-11-28 19:21 ` Pieter Wuille
2025-11-22 21:06 ` Bill MacDonald
2025-11-20 20:14 ` Mat Balez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKaEYh+FHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg@mail.gmail.com \
--to=melvincarvalho@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=murch@murch.one \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox