From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Murch <murch@murch.one>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Sun, 30 Nov 2025 00:00:25 +0100 [thread overview]
Message-ID: <CAKaEYh+L0NU8UYs32oai7NoCcqgbfmBSQjqS=dZG77e1kOB4Zw@mail.gmail.com> (raw)
In-Reply-To: <fc4472a0-5d39-402e-84c8-07328b4dd893@murch.one>
[-- Attachment #1: Type: text/plain, Size: 12392 bytes --]
ne 23. 11. 2025 v 0:53 odesílatel Murch <murch@murch.one> napsal:
> 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
> <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.
>
Hi Murch,
Thank you for the reply. I've followed the subsequent discussion with
interest, Tim and Pieter's points on the AI provisions seem well-taken.
I want to briefly restate my concern for the record.
BIP 3 defines how Process BIPs achieve rough consensus, and the author of
BIP 3 is evaluating whether that consensus exists. RFC 7282, the seminal
IETF document on rough consensus that BIP 3 cites as related work,
specifically cautions against this kind of overlap. Whether adopted
formally or not, the reasoning applies.
My suggestion: require that rough consensus for Process BIPs be confirmed
by at least two non-author editors, ideally from different implementation
ecosystems. This is a small structural safeguard that strengthens
legitimacy and, importantly, distributes responsibility, protecting editors
from being placed in an awkward position when evaluating contentious
proposals.
I also note that PR #2037 proposes several significant edits to BIP 3's
scope and mechanics, which suggests there is still active disagreement on
some important details.
Best,
Melvin
>
> 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
> .
>
--
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%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 14531 bytes --]
next prev parent reply other threads:[~2025-11-29 23:10 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
2025-11-29 23:00 ` Melvin Carvalho [this message]
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+L0NU8UYs32oai7NoCcqgbfmBSQjqS=dZG77e1kOB4Zw@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