From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 29 Nov 2025 15:10:52 -0800 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vPU5a-0005IQ-Sx for bitcoindev@gnusha.org; Sat, 29 Nov 2025 15:10:52 -0800 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-3ec76d47b56sf2732687fac.0 for ; Sat, 29 Nov 2025 15:10:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764457845; cv=pass; d=google.com; s=arc-20240605; b=EYXYYKU+xQe618xnyzE6jX5jA1e5RJhH8m0ZUHFBG9tUqltLzF37Ex/GLin7OwZEvg DhIkdimQVQ3j8y0vLii/PNlS/GSKzZV05W6a5LRbI9X1S+OFI0FLxDMHJ9SmUDSWdBGN 0UN1MnnuuHLkTTCwzXVWFjljHZDiPq2gRcGuFTdZGEKkxJOqOwA9wrycWOqb2BoKGrJM i3g0vmmcwszJHFQ+5KDZ9RnU8Xf5aMHtSViBcn9xTJmTmjFr4ZqSinvZYfBtV7fvYfBy keV5lc+P7WtT0xFC3duTKeSfJJcWAiB25uj0Zf5Y/TrCf09W8jdVMzf2crYqu3B75SSl H72w== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=3MU/uzxLcQjoSEo5s9NqhqDj2kbrOalYZcpA174RrwM=; fh=Q1Zf0ow61ok9+WXVL8LO3re58gL3JHf7WnN9W6ZCroc=; b=Aphj3XCglXt/CsMVz8OJ4Wtdoxoc6aQl5F7hia/vWKIIA/XkSQfcXqXIX0P8MeNeCF suvnFIH2jbdCZtDLn7RcYA6tfchcTcVgmggjeOFyqKrJow1Name/TclA/K6EV/hZB0aN 6VSXHFhApvpTGJZm62nNH8mSR2yxKNMNmVnm94RiRYiCSUnVVFIzxoBp0C5cqul6YF1y 1ouk4yP81vx/48feNEKmbkpgqaECZdZri/ZRnoocMLYHPai8Oswi5OSld1WwTllJfKvt mvwx/Z7pwiFpYTO8UjCcnPEyzdQE8cg+ZQFHSzjSlEm5/CtSyPo+5IsxeKfdRtCLgK+M YOgQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=KenS1rCm; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764457845; x=1765062645; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=3MU/uzxLcQjoSEo5s9NqhqDj2kbrOalYZcpA174RrwM=; b=FE84XEBYKycWOKeBbSJ4TbEU5oTy/uf12CJ+cVt0i9aoD0D8YT6hz38cqlXqLsp4Sl QB4L/htGBo/Q89pCXVyOar4sfjmnGaLo0P4JbiQSzhX+tCJEkCND1n9NCDYjTIJxQu/O oUOydMdI4P+niREJPJF0yCgro0LVgrgVOk9PPr7XncHWYrbKxE97yo8ioNCAfaxuvB1m nnVHOlum/5B9IkufH52BqFCWXsF+cCGJy0aYznTUuGyRclUwmfb4I8ImDqKPA0nnzKf/ sw6FBs0yeP481/h0EvMS9scvxeYrP/KMWVwSfJDhrp+xciUEGj03jvBT/9vruYmQRyjs 2Vlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764457845; x=1765062645; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3MU/uzxLcQjoSEo5s9NqhqDj2kbrOalYZcpA174RrwM=; b=fubVvAqXFr4CH8qQufyzElLFHgkUF/ftC5RSHHbkiFVtQ8jkfAUheE/fUkAlcfYeNZ uozk3StmPivVQ7Amm1xV8t/Ol5OU0OKh81TWmpjzVSoc5KAbBMqUjpdSeoI7MyXzK8HK NGFfeuFoCHYS4pQQV1ZPUaraYGmUgjQaXXPKeOjl2hKrZRDXXgZ09s63koEPa/bUSTbM kuqKOK8ARfUiLum1lmuXksP61iDlOq7aui9uZlEgFPY4HeQRDKAWLsEjkoLbEYBukmfb 40jpYX/RInB9ZCwXSNrwmRe++iWAk40QtYM5LNb65JbR0ou7DpiV/Jn1L4JgKlrDHzR1 mgrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764457845; x=1765062645; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=3MU/uzxLcQjoSEo5s9NqhqDj2kbrOalYZcpA174RrwM=; b=R87aEHSrmP97MKmJFYsXiQmyFB3qlMdNxiO9yoAyn2jurPePp/77XdzKihni0vW3YM v+DOynGAfZBu2n3vC7VKgJwvs8b85dw5rNZRDVfVRem/nWZ2x8Md+KSmUbCke71xOP7K RFFiw/l6yc93Y5K342BT6WTAQGogI9dvm8nXtAe7WAXKHpAVFhSPgGmoJ7WHnv9kkC2Y KL2Cpy67LqXk62ROKl+Iw6sZdu1DUPfIBiLOEw7Huuk8JzX+vtNpD8goM/wZFOmg38X8 aV6Wu06fwufHhBusPS9LWpHZs2/PWgGMSR1Jaaj0LA9z/PoG+5yumPDf3PGh8618qK7Q pg4w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUS2fnqQBrGGnkc/uOafSDh4IlyrYHNjQo9GVVoK5XUnuYVCsd413Pm14DbmQeIC46rrS7LV4bs8qeQ@gnusha.org X-Gm-Message-State: AOJu0YwDQwiGOY9rTncCDvn2SKRLkmXe05pPq7+ps7aNxv4+KTNYYcye zvMEKMfK/c1pTdN1wxa/rDtuzvISOVZcJrKB008mUrTqBNIZjLu5VHK7 X-Google-Smtp-Source: AGHT+IEiWGX8XZJPfyZZBQxYSfHQ62oG2URLEciIzW+xwKfXhohCrak7wYt/XoOPwC43d2n1yfnxOg== X-Received: by 2002:a05:6870:1644:b0:3e0:788f:2622 with SMTP id 586e51a60fabf-3ecbe4f51dbmr18220784fac.32.1764457844325; Sat, 29 Nov 2025 15:10:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Yw+xpYnHZQR0SF/cpgxHFIOqzOdtoui+ekhFH4CcWGgg==" Received: by 2002:a05:6871:286:b0:3ec:461d:1e8f with SMTP id 586e51a60fabf-3f0d28c0147ls1325836fac.2.-pod-prod-03-us; Sat, 29 Nov 2025 15:10:38 -0800 (PST) X-Received: by 2002:a05:6808:6d83:b0:450:ae23:54f8 with SMTP id 5614622812f47-451128ef641mr13723180b6e.19.1764457838547; Sat, 29 Nov 2025 15:10:38 -0800 (PST) Received: by 2002:a05:6808:8182:20b0:450:c180:fd79 with SMTP id 5614622812f47-4515e803c45msb6e; Sat, 29 Nov 2025 15:00:40 -0800 (PST) X-Received: by 2002:a17:902:da4d:b0:298:2e7a:3c47 with SMTP id d9443c01a7336-29b6bf5c107mr367317535ad.42.1764457239371; Sat, 29 Nov 2025 15:00:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764457239; cv=none; d=google.com; s=arc-20240605; b=Stcq6gJN3uBzH/StiuaJ1aH2cklnHOWw9eb4SFKAFuVy6qaup8KFMKwXwIS8Slnf5m Kd+WEXpuksh8IH2DOH9X2w3gwfcWUnkWFGWZQP8B9L+jRjU56by+sgZRjz5U8XsXE0+z pnbGlrVlwDYiokDxG4FvzBK9cGF2eyXUmHsm8oCvcpVynthNTqFHZNI/qI+4Scg5lKs7 82lDWd3VJtjnAblKMCTG73qlDL+dwRrMHnYvc0XVIX29qeO9UABPoxt0qWcncvFKHJyb GgUDSOcwSOcUK1lAPrX3jLMjoXbrlWeX84dgDslc2EGq+arYHjQ3H/eBNXIY2cRBtaXs l0EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=LKdnnv8UCEfQSg663p3zRbFFrQubKH8W/gZbj6u4KFg=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=MwRU/NNsS9GLPnBw8FS/TzDFuoNQ28R1660j2wKkoUn/+7iTqsLJxlq/vUje1aBJRl Q51exLZsof2ONuWMYARTFAqHvwsz01Mj4pE3gklhpgMJVCpUlYIDlAEvDiPrXHCPi9O1 1Y3N8ge5VTM8HKI6o1vx4Uu/b4+fFhaOwLwDgbMqAxnVm2kS9lm7YSWlEPkqC+wMXeIG mCA3+eObXIaT1tlkAiUZP/DPCwzyFUhSDZb/upTzsulNdAQHiWA5B4L2X0leN4cCyy8Y jMka18x3Z/mLYrUoo+JiJxppP9+O0lI3eUgrUcSlyA1W7IoVOfzUkhOpXnYz/Zx1V2il LVVw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=KenS1rCm; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com. [2607:f8b0:4864:20::62e]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3477b72f30fsi66308a91.3.2025.11.29.15.00.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 15:00:38 -0800 (PST) Received-SPF: pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) client-ip=2607:f8b0:4864:20::62e; Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-2956d816c10so33244355ad.1 for ; Sat, 29 Nov 2025 15:00:38 -0800 (PST) X-Gm-Gg: ASbGncuFIYZdpYCS9B96BFjCHVBcsc5KEjFR9gx7vYZnmd10NQn6qEa5p9EUQ87zB5R yS7WP7uQXStGBdWKo5s7kMhOx+LDN6EDclNRy/TSequK+rT+93JuqZaifyNgsqiw5r1o4Xlj1VR qzolb6qMN18gD6lzs1hAXSFECTRpb79uLNPVWM9id9ne9d4aZtxyopcSsEg4fqIUwMryWPxrmj3 enqxexu91C3fIEZjf6CsIbmCymOswFqTDQg69DAk1GXE6GORdmzmNQrQ+FLLgr1Zirm8Qwa/BPM FT+xd5Qfz5iij2hBn3p4cDSPRuOQik8NSmT6/xHhu6WBuPcZUBTwuTA= X-Received: by 2002:a17:903:17c5:b0:294:f310:5218 with SMTP id d9443c01a7336-29b6bd580aamr391367545ad.0.1764457237556; Sat, 29 Nov 2025 15:00:37 -0800 (PST) MIME-Version: 1.0 References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> In-Reply-To: From: Melvin Carvalho Date: Sun, 30 Nov 2025 00:00:25 +0100 X-Gm-Features: AWmQ_bl9EfH8YfDhZ89pFC3dNkBUzvgoevy8i_6y_lFZIAJLYicuC1kNDXoXl_g Message-ID: Subject: Re: [bitcoindev] Motion to Activate BIP 3 To: Murch Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000ddb2c10644c3b63b" X-Original-Sender: melvincarvalho@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=KenS1rCm; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --000000000000ddb2c10644c3b63b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ne 23. 11. 2025 v 0:53 odes=C3=ADlatel Murch 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=E2=80=99s section mentioning rou= gh > 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 ha= s 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-bi= ps > > 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 =E2=80=9CObjection raised by X regarding Y; addressed by Z=E2=80= =9D, would > > 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 > > 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 > 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=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 > 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=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* > > > > 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=C2=B2 states: > > > =E2=80=9CIf the BIP needs more work, an editor should ensure that > > constructive, actionable feedback is provided to the authors for > > revision.=E2=80=9D > > and the README states: > > > =E2=80=9CWe are fairly liberal with approving BIPs, and try not to be t= oo > > 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.=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* > > > > 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 =E2=80=9Ca BIP that is of historical int= erest > 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* > > > > * 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=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#specifi= cation > > 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-0732= 8b4dd893%40murch.one > . > --=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/= CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%40mail.gmail.com. --000000000000ddb2c10644c3b63b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


ne 23. 11. 2025= v=C2=A00:53 odes=C3=ADlatel 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=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/bitcoi= n/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 =E2=80=9CObjection raised by X regarding Y; addressed by Z=E2= =80=9D, would
> 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
> 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
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=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
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 inter= est," 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=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*
>
> Declining numbers due to "lack of interest" or "insuffi= cient
> progress" is reasonable in intent but subjective in effect. A bri= ef
> 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=C2=B2 states:

> =E2=80=9CIf the BIP needs more work, an editor should ensure that
> constructive, actionable feedback is provided to the authors for
> revision.=E2=80=9D

and the README states:

> =E2=80=9CWe 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.=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:
=C2=A0> *4. Status compression and historical clarity*
>
> Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplif= ies the
> system but loses useful distinctions that help readers understand
> why a proposal didn't advance. Optional status annotations (e.g.,<= br> > "Closed (Withdrawn by author)" or "Closed (Superseded b= y 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/bi= ps/blob/master/bip-0003.md#closed11

On 2025-11-14 09:05, Melvin Carvalho wrote:
=C2=A0> *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
=C2=A0> 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<= br> > 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=99= m 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/bi= tcoin/bips/blob/master/bip-0003.md#specification

On 2025-11-14 09:05, Melvin Carvalho wrote:
=C2=A0> These small additions strengthen neutrality and transparency. Th= ey
=C2=A0> also help editors by distributing responsibility and making
decisions> easier to defend through a clear paper trail. I recognize edi= tors
> 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 need= s.
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 Mur= ch,

Thank you for the reply. I've followed the subsequent discus= sion with interest, Tim and Pieter's points on the AI provisions seem w= ell-taken.

I want to briefly restate my concern for the record.
<= br>BIP 3 defines how Process BIPs achieve rough consensus, and the author o= f BIP 3 is evaluating whether that consensus exists. RFC 7282, the seminal = IETF document on rough consensus that BIP 3 cites as related work, specific= ally 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 safegu= ard that strengthens legitimacy and, importantly, distributes responsibilit= y, protecting editors from being placed in an awkward position when evaluat= ing contentious proposals.

I also note that PR #2037 proposes severa= l significant edits to BIP 3's scope and mechanics, which suggests ther= e is still active disagreement on some important details.

Best,
M= elvin
=C2=A0

Best,
Murch

--
You received this message because you are subscribed to the Google Groups &= quot;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/fc4472a= 0-5d39-402e-84c8-07328b4dd893%40murch.one.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%= 40mail.gmail.com.
--000000000000ddb2c10644c3b63b--