From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 22 Nov 2025 15:53:12 -0800 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vMxPj-0007Tp-Kd for bitcoindev@gnusha.org; Sat, 22 Nov 2025 15:53:12 -0800 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-6574c2a5530sf3995420eaf.1 for ; Sat, 22 Nov 2025 15:53:11 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763855585; cv=pass; d=google.com; s=arc-20240605; b=dUtjBt5FRdYXdNICY2q5Hz/g+NSOM8ukwuPRYoID0p3+dK4Cp9u8WTZiL4vkYyNbdr bVh4wXNLJljss4I64J6AUK+xPiVC1VKyLIANbj+eEwVz8DU2E75pa1tazsn8eYDXVnrY QsWLv+CBHwXlOwq/OP05DGyvyb7TFYnYw9Iczm0JTK5lto0XYVSj3CIsOBhfPTfUow1X EjKPBfnrE1g+Miy/J2lMrYVNnB7SCTzmzIg+1jcAs3HC7W45HBf7Um9A1AyMOltRM0jE zlGwMxC1DfvFg6CuH848kmrIfoQNvL9J7x//ir3NI6TwEUCtmi9zWr4DszSsGpTMrIuz zLNg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=wHtzMUx4/aKNqVttXwmIHhZaUaF91YMtywRDGRQ53I4=; fh=ICmTiOvgWAU6wxy8P5Ixi5ar7dp2HmOGiMhmbclGQqA=; b=DdUJj8SllXHXr2KmY48iYRichWq1Tt4ziNfntNc1tLfnPzB5vUrKNAViG3jyD+WtPA 2dRurYIFlRfupezvirPSb3p28ZDcCLCqpeDCMG2tdnIuTzJD1wuky/jGFWWzxXzPoXPb mlxvWtnH50AcQm9ihlzTApDAEspVTlnRqeOLa5TPyT0hfVsxhpu93lFv9I0H3vLztXQO 6ZxyydVRY3liH3ZsGh5ryFeZMKhhTEmkujW1qC6jwGngOdEN53UQ1C+966IJtSD5qKtz 8IM1rwaXvdIgAFAgFRfqs0Rz5/NWUm7Gdt75mCcyH/EvI6sLpcuk5MNCBAqo5SOGyBOA jO8w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="OCffZ/Sc"; spf=pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763855585; x=1764460385; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=wHtzMUx4/aKNqVttXwmIHhZaUaF91YMtywRDGRQ53I4=; b=V4DVF6hxLHSCbj8MHsVEgiYBCKzr9rP2aRjD5uHxHjh76oR3Yc+/ThK7qzwD79Ihtd 1+4U4nve9P3iLQIbjQVQ6E7Mm3qIgFyZLrVRyErDbdK8oAx41WT9cT3UKeYymGsM6FDa CPzYkuU+p94YhbnFQY7TByhHfEw2UsJc3LbwkqvBNfWtrysUnPpOt/364SR0Nij9W9Ae IVqLiiyx8VSU+M0UhLrIrmiqBi6uOUlf5jUvHJ3RtdyNGAMUl7QvjBvGSo8YZ+p5GYIA 18Sg92Rk2MWUuxlcGq2GMk54T3CIAzeYVqln0ThI4nagSUAwSbf1GCbBgtNfNkGQu4Be y8qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763855585; x=1764460385; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=wHtzMUx4/aKNqVttXwmIHhZaUaF91YMtywRDGRQ53I4=; b=OT23l/BrqkgqLsOfeq7sKneztclb9N7jJn+jlm9DGyVfldX0wubLWawTgP5XV9MAWb +4su+4Ba487VW2P7vFXSGbfot1W1pCa6NcEdsVK1k+cqlgu9atcq+kdtJs4LtTWdwkQt zrjshlTysJBsUGks5na/QmnVGVI7uFnYe1GOEX8O8V+0xX9Bp2wxv8ntGg9HQFl8TyEC cY6maWN4THPqD/U//HO9GgWa+W6E+dWp+5Y/rANJ84vLFxMaOip7G6WDfFXXqdTeqluf IuRyDkn11XumbhYgjAg1OPwyBQgWHEM5RttVeoy+LUKNrvaqwQufPlDKlO2EpBI8lFAo pulQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWgTuOP9MpcWmUqpcirAvtzbQb2CEScxBhTFT9yjOIkTgdYOksu2aNIGmAZ+LndAhKyLYWjQAwvP+eT@gnusha.org X-Gm-Message-State: AOJu0YzWridy2SporYSuatfaGzHLg7goXeQ83Ytl38dnMFiE1kmV0NwJ w7OgNE2+ExOkbCaM741A9iyo47rb6xHPNM5wBK+1xXasp1rSah+TcZ3v X-Google-Smtp-Source: AGHT+IFVMffevg47Y0txAbxjPIiY+j9laxnqqpAzdRp0nmtJgHQusmCrZr+OFgIdDMqMALrDgiO49Q== X-Received: by 2002:a05:6808:309f:b0:450:bf48:8352 with SMTP id 5614622812f47-451128c8abbmr2875273b6e.11.1763855585168; Sat, 22 Nov 2025 15:53:05 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bLp2jTyPdapWK4gRbBE0zKeGnfGmp4B+4gAM8IthXTxw==" Received: by 2002:a4a:b785:0:b0:654:f519:683f with SMTP id 006d021491bc7-657837ec8c7ls1137831eaf.0.-pod-prod-08-us; Sat, 22 Nov 2025 15:53:00 -0800 (PST) X-Received: by 2002:a05:6808:6d81:b0:437:dade:463f with SMTP id 5614622812f47-45112b728c3mr2725665b6e.34.1763855579877; Sat, 22 Nov 2025 15:52:59 -0800 (PST) Received: by 2002:a05:600c:c108:b0:477:b663:eee5 with SMTP id 5b1f17b1804b1-477bfd88015ms5e9; Sat, 22 Nov 2025 15:46:53 -0800 (PST) X-Received: by 2002:a05:600c:3b09:b0:477:a3f9:fda5 with SMTP id 5b1f17b1804b1-477c016e425mr52595255e9.9.1763855210846; Sat, 22 Nov 2025 15:46:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763855210; cv=none; d=google.com; s=arc-20240605; b=C9JKwzTSs52H3UbyTgZtaSvT3r/Q+kJ4LwRLM9EYrz16nw4gWXvPeDTnRLNoQJiAGS KRYuiTxQKx9oAeV1MvHIh1zwu3FuCnejWvrkSoWMifemh2Di7PlV2JVCEKsVeFuSzGFt T+XpuCIsrHaaKALgEIO8IzjXtSOxGXYifIg7RXwwdqmo3ODbOImcF8F63g/dZuRnmjTg fR2N6dSLsFBTThM8cIqVhCkjmKTfmjmbfncXm/hWtt645Jv1q+7J7AlJvXahatak85Kd Gh2rK1CKV73O6EQUnM2fewso4VRwW5NDc1WqCQ6Dckyuxgo7LHm55PTote8I2vpz6dCk 7JjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=yc6hc+qYb1pNmYsZZm4c4wGENbi2Z31d/WeGMTl1mAQ=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=N32PdAH812brgmJY7q4lC3dRpWh/rx7av/S/b27V0LdbrM1i39bSk6JOUGpgB8lFl2 erH3KjxY/9lPOD+f//deq2lpNwFnt+vELvOOPGAMPKN9Aszz+WOPGJPVqhRpiRWavfEf 5KnIxKISUy4CcL7TPp+M9Fe6pcBHcR7ywxvDLK2QQN6X3ObEGOdQmgLsJxPE6sigpQWG +Fz+wD7iHGXquAZ+NlYKsJ2IB/7IGKpHVvpimZ46i8w7qsKwgTXkffmOYkGyb333K8l3 df1Uqyawsz6TjJmjKNQBbp1nJPjVaUytLudtOIhYa5CPocFtD2Ej2WxJ1mQfLQ7Ai/7z SuHg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="OCffZ/Sc"; spf=pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate01.uberspace.is (mailgate01.uberspace.is. [2001:1a50:11:0:c83f:a8ff:fea6:c8da]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-477b6645549si985305e9.2.2025.11.22.15.46.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Nov 2025 15:46:50 -0800 (PST) Received-SPF: pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) client-ip=2001:1a50:11:0:c83f:a8ff:fea6:c8da; Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate01.uberspace.is (Postfix) with ESMTPS id 56ECA608AC for ; Sun, 23 Nov 2025 00:46:50 +0100 (CET) Received: (qmail 28736 invoked by uid 989); 22 Nov 2025 23:46:50 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Sun, 23 Nov 2025 00:46:49 +0100 Message-ID: Date: Sat, 22 Nov 2025 15:46:46 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] Motion to Activate BIP 3 To: bitcoindev@googlegroups.com References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> Content-Language: en-US From: Murch In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-2.999999) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.089999 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="OCffZ/Sc"; spf=pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) smtp.mailfrom=murch@murch.one Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) 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=E2=80=99s section mentioning rough consensus also defines the term in the context of BIP 3. Specifically, the _Process BIPs_ section=C2=B9 states: =E2=80=9CA 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.=E2=80=9D =C2=B9 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* >=20 > RFC 7282 emphasizes that rough consensus is demonstrated by=20 > documenting objections and how they were addressed. Process BIPs=20 > under BIP 3 can self-modify without requiring such a log, which=20 > leaves ambiguity around how consensus is determined. A short=20 > objections/resolution record, even as simple as a changelog section=20 > noting =E2=80=9CObjection raised by X regarding Y; addressed by Z=E2=80= =9D, would=20 > address this and provide helpful context for future readers. The section mentioned above continues to clarify the mechanism for modifying Process BIPs: > =E2=80=9CDeployed Process BIPs may be modified indefinitely as long as a= =20 > proposed modification has rough consensus per the same criteria.=E2=80=9D Further, BIP 3 introduces a Changelog section which requires recording changes to a BIP after it has reached the Complete status (which also=20 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=20 while they don=E2=80=99t 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=20 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* >=20 > RFC 7282 discourages authors from judging consensus on their own=20 > work. Under BIP 3, a small editor group collectively evaluates=20 > numbering, closure, "material progress," "lack of interest," and=20 > rough consensus itself. This concentration of authority may create=20 > perceived conflicts of interest, even with the best intentions. >=20 > A minimal safeguard would be requiring two non-author editors,=20 > ideally from different implementation communities such as Core and=20 > Knots, to confirm rough consensus for Process BIPs. This shares=20 > responsibility and provides independent verification. For example,=20 > if a Process BIP proposes changing the Draft-to-Complete threshold,=20 > 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=E2=80=99m 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=E2=80=99d be happy to comment on that concretely. On 2025-11-14 09:05, Melvin Carvalho wrote: > *3. Subjectivity in number assignment* >=20 > 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.=20 It is my understanding that the BIP Editors are entrusted by the=20 community to make these judgement calls for the benefit of the entire=20 audience of the BIPs Repository while adhering to the spirit of the=20 active BIPs Process. Concretely, the _BIP Editor Responsibilities and=20 Workflow_ section=C2=B2 states: > =E2=80=9CIf the BIP needs more work, an editor should ensure that=20 > constructive, actionable feedback is provided to the authors for=20 > revision.=E2=80=9D and the README states: > =E2=80=9CWe are fairly liberal with approving BIPs, and try not to be too= =20 > involved in decision making on behalf of the community. The=20 > exception is in very rare cases of dispute resolution when a=20 > decision is contentious and cannot be agreed upon. In those cases,=20 > the conservative option will always be preferred.=E2=80=9D 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 =C2=B2 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* >=20 > Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies the=20 > 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 =E2=80=9Ca BIP that is of historical inter= est only, and is not being actively worked on, promoted or in active use=E2=80= =9D.=C2=B3 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=E2=80=99s 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. =C2=B3 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* >=20 > * Short objections/resolution log for Process BIPs (can be minimal=20 > changelog format) >=20 > * Neutral consensus verification by two non-author editors,=20 > preferably cross-ecosystem >=20 > * Brief explanations for number denials and "stalled" Draft BIPs >=20 > * 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=E2=81=B4 already collects objections: > =E2=80=9DThe rationale should record relevant objections or important > concerns that were raised and addressed as this proposal was developed.= =E2=80=9C- Changes to Process BIPs must be discussed in public, I=E2=80=99m= not sure that additional regulation would translate to a further improvement rather than just more friction. - The process already requires Editors to provide =E2=80=9Cconstructive, actionable feedback [=E2=80=A6] if a BIP needs more work=E2=80=9D. - When a BIP is moved to Closed, it is required to record the reason in the Changelog. =E2=81=B4 https://github.com/bitcoin/bips/blob/master/bip-0003.md#specifica= tion 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=20 decisions> easier to defend through a clear paper trail. I recognize editor= s > are volunteering substantial time, and these mechanisms are intended > to make the role more sustainable, not more burdensome. >=20 > 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 --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one.