From: Murch <murch@murch.one>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Sat, 22 Nov 2025 15:46:46 -0800 [thread overview]
Message-ID: <fc4472a0-5d39-402e-84c8-07328b4dd893@murch.one> (raw)
In-Reply-To: <CAKaEYh+FHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg@mail.gmail.com>
Hi Melvin,
Thank you for your sharing your thoughts.
On 2025-11-14 09:05, Melvin Carvalho wrote:
> Since BIP 3 cites RFC 7282 as its rough consensus framework
I am not sure how you got this impression. RFC 7282 is only mentioned
once, in the related work section. BIP 3’s section mentioning rough
consensus also defines the term in the context of BIP 3. Specifically,
the _Process BIPs_ section¹ states:
“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.”
¹ https://github.com/bitcoin/bips/blob/master/bip-0003.md#process-bips
On 2025-11-14 09:05, Melvin Carvalho wrote:
> *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.
The section mentioned above continues to clarify the mechanism for
modifying Process BIPs:
> “Deployed Process BIPs may be modified indefinitely as long as a
> proposed modification has rough consensus per the same criteria.”
Further, BIP 3 introduces a Changelog section which requires recording
changes to a BIP after it has reached the Complete status (which also
applies for the Deployed status).
Therefore, I disagree with your interpretations:
- RFC 7282 is not used by BIP 3, it is cited as an inspiration.
- Deployed Process BIPs cannot be modified without a public record, as
modifications have to be discussed on the mailing list, and the changes
need to be recorded in the Changelog section.
- Objections have been addressed per the footnotes in the Rationale
section, as required by the description of the Rationale section. Even
while they don’t take your proposed format exactly.
While technically it is not required, because BIP 3 is not active yet,
I posit that it would be good to add a Changelog section to BIP 3 that
reiterates the noteworthy changes I described in my prior emails.
On 2025-11-14 09:05, Melvin Carvalho wrote:
> *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.
It seems reasonable to me that authors recuse themselves from judging
whether consensus has been reached for their own BIP. Luckily, there are
currently six BIP Editors and I’m the sole author of BIP 3. I am
skeptical of introducing rules for hypothetical issues that have not
been problems in the past, especially when those rules would cause the
BIP Process to grind to a halt should the Editor count should fall back
to the levels that were normal for its entire history except the recent
past. If you would like to propose a concrete change to the BIP text,
I’d be happy to comment on that concretely.
On 2025-11-14 09:05, Melvin Carvalho wrote:
> *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.
While an express goal for BIP 3 was to reduce judgement calls by the BIP
Editors in the BIP Process, the BIP Process does inherently require some
judgement calls to fulfill its function of surfacing relevant documents.
It is my understanding that the BIP Editors are entrusted by the
community to make these judgement calls for the benefit of the entire
audience of the BIPs Repository while adhering to the spirit of the
active BIPs Process. Concretely, the _BIP Editor Responsibilities and
Workflow_ section² states:
> “If the BIP needs more work, an editor should ensure that
> constructive, actionable feedback is provided to the authors for
> revision.”
and the README states:
> “We are fairly liberal with approving BIPs, and try not to be too
> involved in decision making on behalf of the community. The
> exception is in very rare cases of dispute resolution when a
> decision is contentious and cannot be agreed upon. In those cases,
> the conservative option will always be preferred.”
Further, the entire work is happening in public via the mailing list and
pull requests to the BIPs repository. If any announced decisions are
unclear, controversial, or taking longer than expected, nothing prevents
participants from seeking clarification. I would also like to reiterate
that a BIP being published does not guarantee or imply adoption
² https://github.com/bitcoin/bips/blob/master/bip-0003.md#bip-editor-
responsibilities-and-workflow
On 2025-11-14 09:05, Melvin Carvalho wrote:
> *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.
The Closed status indicates that “a BIP that is of historical interest
only, and is not being actively worked on, promoted or in active use”.³
The simplification of reducing the count of statuses is an explicit
design decision of BIP 3 that is explained in detail in the Backward
Compatibility and Rationale sections. My stance is that the Closed
status provides sufficient information at the table overview level, and
BIP 3 requires that the detailed reason for a BIP being set to Closed is
recorded in the Changelog, where it is easily accessible to anyone that
is interested in a specific BIP’s trajectory.
Some of the sunset Statuses have in the past elicited pushback by
Authors (especially Rejected and Deferred). Closed constitutes a more
neutral term, and the Changelog allows a more nuanced description of the
reasoning than single word Statuses.
³ https://github.com/bitcoin/bips/blob/master/bip-0003.md#closed11
On 2025-11-14 09:05, Melvin Carvalho wrote:
> *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
As covered above, it seems to me that all of these points are already
sufficiently covered by the proposed BIP.
- The Rationale⁴ already collects objections:
> ”The rationale should record relevant objections or important
> concerns that were raised and addressed as this proposal was developed.“- Changes to Process BIPs must be discussed in public, I’m not sure that
additional regulation would translate to a further improvement rather
than just more friction.
- The process already requires Editors to provide “constructive,
actionable feedback […] if a BIP needs more work”.
- When a BIP is moved to Closed, it is required to record the reason in
the Changelog.
⁴ https://github.com/bitcoin/bips/blob/master/bip-0003.md#specification
On 2025-11-14 09:05, Melvin Carvalho wrote:
> 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.
Between the BIPs Repository being an append-only record, all of the work
happening in public in pull requests and on the mailing list, as well as
per the requirements for the Rationale and Changelog sections, it seems
to me that the proposed Process already provides plenty of paper trail.
I would hope that if you gave BIP 3 and especially the Rationale section
another read sans the notion that it relies on RFC 7282, you would
find that your concerns are already addressed satisfactorily. Please let
us know if this is not the case.
Best,
Murch
--
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/fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one.
next prev parent reply other threads:[~2025-11-22 23:53 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
2025-11-22 23:46 ` Murch [this message]
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=fc4472a0-5d39-402e-84c8-07328b4dd893@murch.one \
--to=murch@murch.one \
--cc=bitcoindev@googlegroups.com \
/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