From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 14 Nov 2025 09:09:04 -0800 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vJxIF-0007EM-RC for bitcoindev@gnusha.org; Fri, 14 Nov 2025 09:09:04 -0800 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-656edc694adsf4447807eaf.1 for ; Fri, 14 Nov 2025 09:09:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763140137; cv=pass; d=google.com; s=arc-20240605; b=VZXks65lXowYo1qRoTVF54mA61TyjRRSvWuUv2pUtfIPvg2NZ/DbW//Zn0L7kY0qCi HFFHuZ9KaUIZuOvwnhzY9+6RzI/zXsZ5QuJ3mI95qg4FI3DjF5H6p2yx7uK+7yEd++c3 oOs3IGkPkVpeoOd7kw94sq8qLOPzOpgbAZYA4jwYfRnD4QlVypUeuiCQhfhxq7vVKLE0 XW/XSRWnc3+0fT4VlV8/5hK2+2U+Oytw9DMMu2udv9DQTqDAjcNu+1tCdLwXM0XzcdTm 1t6NnICy5W6+87vXxedpexM9QK/K9/lkSy29jK77fkwfKf4q/IikfPP6F4yuGcYBDmh4 HREg== 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=lN5vlCG+bbDVmmPbWgAB1GfK+0TXvGM7u3SMJ+9vZTM=; fh=2xgNXgazFT3DdjHTpTVnGfaGeYKdDsrO51ELXx1QXQw=; b=GoUWCzbMNnt5Wcf4v56H3qGievTa/nm/+Yb7h/CN2iHILWdhkt9RfEkCSxh23l/V/V O07ZwxxXpy+S1MkLBC4GN0QTh3t69vMypDJHhcjE1CM4tL/6j3KqoUEvSe7sXpn2U+Sr OfAHiH7JGfEx6v4a8vRDC/48MWAWc42zqaJz4i2Pgz7Mr7CxrQadoDd29LE3uXD7iMe5 Botz85YsZUwYEbYK6qnuqCXl0pZVzyjbPzsUrQNsPuwL4WmupSQbv7JFy5xxfC5AUySm yWrHjg5IXuv11mmba0BcCS9Rva5rFFOTWy5DxaZUGAb8zpAz1XalHiCyrEFwlkkm1orz QWvA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="A/GUs2GL"; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102c 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=1763140137; x=1763744937; 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=lN5vlCG+bbDVmmPbWgAB1GfK+0TXvGM7u3SMJ+9vZTM=; b=MHqFhW6j/eMZda5Y9QsLgdHBzOcaxlAOE21J8hwYp/ApWQ322GABf4gORWAIMNL4N2 /K9GtbZYp7/HP04yt64+lcKgoq0lDdqAcef8xfbjXUAnY2f2p1rXRYwZGbt+RAwziT3W XPXh2ODQrIVowCiwW/rZ4MadOBfhWBt2pQl0ih34bDcalUfHj49hL9sAFyMFWBEK+qEV wlYjdR8t5+INmKyuZpIeXOkgzIsm+BU5Ie6vMhFhQzf1e2MLTeTWFHuKXN1RiJZyANrE 7/NTQi4KreW3ku2fOGiMiJA8tT2D0e2dshfD+juK0SsWE4BTO5id+B7tKgzl96hMyNDn HWKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763140137; x=1763744937; 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=lN5vlCG+bbDVmmPbWgAB1GfK+0TXvGM7u3SMJ+9vZTM=; b=h2XBlE8jCm+hSNJC6WcWqBzmPBz90+Jb1S59byISUuJx7D4+HIBuHveZXDD7863Hna Wa1PPQvMPesIiuU4rlmZkNPPxD0mwDBk8Z3qtqMUyLXr1tuY1GnHDzt+AeDxBbDiChls JWdnINClpupO5QzLvxO9SCVLGgq6BlEunldBSV9xpFCvA85kyqEE1FT22MGCPvVnb6f4 OJoxoaXs93uxUqSnQ97NZ0HjP0q6IZCoesIN4iE+IHMaxRSGcwP7aWfUZTvQUCfPGmiH 62EZF2tImmeZvyflr3rGoazBdt+LKLr4W13GYFiC4RJrBq17Kv9S8Bd2wazcVRkBVHZz 1+Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763140137; x=1763744937; 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=lN5vlCG+bbDVmmPbWgAB1GfK+0TXvGM7u3SMJ+9vZTM=; b=rDhGpXaXQKNooshNp8uUBo/7OEyoqoEafSliNtnxOcgsf2lzRR7FyGM9NeqdqQIFLf ePBHW6O7teDf76doCZn2ra/C7VmkzxrZeDzjqGdQp/IUsEocivs0TJBwh65kvEq+KJnA uMd6LG5HvdYt9QyIkGuRsBD29q6/s7EFA1yBZPFxEtF2mdXXBpfZFxBI2LvBRMBUeia3 40L5CUd6f/9gj178elZTPfe91m5qvdX6VH7dj3CJttB8MgVr2km/Opmzv8hyX/y2C9zv MnSY1lLGmpGD65Ia0EwFWzkWWNnTtjja6CyTPXTG+Lo9zSckrD1EezDmNLPb8aXsRZUm iwsw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXYlQQIM9h4iMygMOKClsb0jnzfN7GVnnimaNaHJ1MjEVqhipJ1Rmmh0tAd2CD1IgLGxr8zjBswvGVb@gnusha.org X-Gm-Message-State: AOJu0YxRDJEiVt02KpHrCBzwGNQFEw4ZD6jvIM/qvZRMzs6v7MzbxRox DivQ3ytx0ySDkzLDfLc0PJNVlIyOOLpbMHc+zjeLiGRz4WyzlXBxE8dY X-Google-Smtp-Source: AGHT+IFfb5Ngd6FygSjta0je2pxOdrrzfaMX4VKz7YuVXWQ6yAro849YSKHCc5anzaRDGgkaHdoELg== X-Received: by 2002:a05:6871:22c5:b0:33f:dc6b:ba35 with SMTP id 586e51a60fabf-3e8691b56c5mr1739065fac.36.1763140136829; Fri, 14 Nov 2025 09:08:56 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a7/i7+SS+gfapAiGxqKdck7eorMNTm+DBwTjxmwtQRAQ==" Received: by 2002:a05:6871:10f:b0:3d6:eb45:2889 with SMTP id 586e51a60fabf-3e84bd24a4els328148fac.1.-pod-prod-05-us; Fri, 14 Nov 2025 09:08:52 -0800 (PST) X-Received: by 2002:a05:6808:178c:b0:450:50d:c6c2 with SMTP id 5614622812f47-450974e80dbmr1633982b6e.33.1763140132034; Fri, 14 Nov 2025 09:08:52 -0800 (PST) Received: by 2002:a05:6808:83c3:b0:44f:fe66:38a2 with SMTP id 5614622812f47-45096b83c6fmsb6e; Fri, 14 Nov 2025 09:05:52 -0800 (PST) X-Received: by 2002:a05:6e02:156b:b0:433:2aad:9873 with SMTP id e9e14a558f8ab-4348c938062mr63243565ab.29.1763139951522; Fri, 14 Nov 2025 09:05:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763139951; cv=none; d=google.com; s=arc-20240605; b=ChdH5crxmz60ymOX6qyoCQI19/062sfNOt+zzOb5kRp+/HvhugccQ0iNehz3+rSqim 5y3MtqGegCGS9hEAKp86lwbKSytCXlwG8gn4VqMN3YMraVXEp6DMGMTCa/znni1/1UPM 30xAsvAs1LIXpXmGGDX8mN51OR4Kz13PlmxYAIH4CtOZwFAikZhZZivrC+ie3XrCWXc6 9WpPVxdF7QBGn9JaFycTenMIqH1BOi+fB1WNtdqpG2QUcDyi4srCpZSqcCsq2NN+eMCN 9MFx2Q48Ud07cpFYhQ9frhwXSlYSNnWqFWRWa4bX0CPV9iPNzvXRM0IbWyR7KdxMIGbJ V7qA== 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=QBxl4cuXVsax2L3+n8yT9tuNaqi99LV0toC3rl7iA+o=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=Y1WsXY+lH8VW4bbayWThOQEWZPuizWPCcznEPwva36OE6kuwwbtP83Soy/6F0FOJ9N lZ+zc27zzXsHNsPF7vVR24UCa25eOWlrSNgHGKa95EcWrlHrlISXqDmN04gPUMWDF2QN Bq4qyn8hPlpB129CNpIm5hCXbchC5+klsRtaS3bnbQTHAuOmDkGdFFkxJU+Eu42AwS0m VGmbmIEsJsAssrPSOsyGMbG6xurbNW5VHbjpn2yLLNQHZuWSsUMlxxbHAkAevrEMCgq0 +eQpuiCWp7pDUEJ5IzrAoOze2Va5hYN/AheAh51VhklSGW0axz7K/DpBAmX9xp4JErtu MfzA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="A/GUs2GL"; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102c 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-pj1-x102c.google.com (mail-pj1-x102c.google.com. [2607:f8b0:4864:20::102c]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-434839a39bcsi3096185ab.5.2025.11.14.09.05.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Nov 2025 09:05:51 -0800 (PST) Received-SPF: pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) client-ip=2607:f8b0:4864:20::102c; Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-3437c093ef5so2135297a91.0 for ; Fri, 14 Nov 2025 09:05:51 -0800 (PST) X-Gm-Gg: ASbGncuFyaYApfTcbZ8lK7uhrcqCwb55melCIO4qO2ppeTsgYmD08EhUO7X8acjsvet 9OaECKL9dCKfUVjmx3qld5+2tc9Dy2BLy3aj740KC5ZpR6LyDkPpYAqfQbv7O3g9Lg6X/epSJ0z 4G4XX7zi2PWJ7D7lCE6KB808oWUJQ34hb8MSIz05XZ4QLcqCfBTZ8yBoBWA/76KL50ZY3puDr5L tPvS5V1sfHLq4b+/uF8tV7IMPQWtEqg0folYYLeNVqh/odfVfMERGt76+NxjEdnxuvaG+eh26M+ J+sfECTJEfn6WfG0iV3b2PYYte6lEE9o1OCiz1sSUjfL69DM4msL/quzeQbocozK8Q== X-Received: by 2002:a17:90b:4c0d:b0:343:e2ba:e8be with SMTP id 98e67ed59e1d1-343f9eaddb1mr4037656a91.10.1763139950551; Fri, 14 Nov 2025 09:05:50 -0800 (PST) MIME-Version: 1.0 References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> In-Reply-To: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> From: Melvin Carvalho Date: Fri, 14 Nov 2025 18:05:38 +0100 X-Gm-Features: AWmQ_bmrGHG330-GSOZf7sRKdNun8gISJDd8e0ldBqm0na-EMTRA3T1L13haEzY Message-ID: Subject: Re: [bitcoindev] Motion to Activate BIP 3 To: Murch Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000007126b4064391028b" 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="A/GUs2GL"; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102c 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 (/) --0000000000007126b4064391028b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable st 5. 11. 2025 v 2:11 odes=C3=ADlatel Murch napsal: > Dear list, > > After planned work on BIP=E2=80=AF3=E2=81=B0 finished in February, BIP=E2= =80=AF3 was advanced to > Proposed in March 2025=C2=B9. A few minor adjustments were made to BIP=E2= =80=AF3 > since then (see below). I have since April maintained a pull request > that would activate BIP=E2=80=AF3: https://github.com/bitcoin/bips/pull/1= 820. > > At this point,=E2=80=AFBIP=E2=80=AF3 has received over 600 comments on Gi= tHub 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=E2=80=AF3 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=E2=80=AF3 to replace BIP=E2=80= =AF2 as our BIPs > Process. > > Since BIP=E2=80=AF2 doesn=E2=80=99t specify a procedure for activating Pr= ocess 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=E2=80=AF3 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=E2=80=AF3 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=E2=80=AF3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions=C2=B2 > - 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=C2=B2 > - The =E2=80=9CCreated=E2=80=9D header has been renamed to =E2=80=9CAssig= ned=E2=80=9D=C2=B3 > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository=E2=81=B4 > - that authors should establish viability of their proposal on the > mailing list=E2=81=B4 > - the distinction between publication, acceptance, and adoption of > proposals=E2=81=B4 > - when Draft BIPs can be closed due to not making progress=E2=81=B4 > - that BIPs submissions may not be generated by AI/LLM=E2=81=B5 > > =E2=81=B0 https://github.com/bitcoin/bips/blob/master/bip-0003.md > =C2=B9 https://github.com/bitcoin/bips/pull/1794 > =C2=B2 https://github.com/bitcoin/bips/pull/1892 > =C2=B3 https://github.com/bitcoin/bips/pull/1970 > =E2=81=B4 https://github.com/bitcoin/bips/pull/1819 > =E2=81=B5 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 =E2=80=9CObjection raised by X regardi= ng Y; addressed by Z=E2=80=9D, 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-264f= c6e0e70b%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%2BFHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg%40mail.gmail.com. --0000000000007126b4064391028b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


st 5. 11. 2025 = v=C2=A02:11 odes=C3=ADlatel Murch <murch@murch.one> napsal:
=
Dear list,

After planned work on BIP=E2=80=AF3=E2=81=B0 finished in February, BIP=E2= =80=AF3 was advanced to
Proposed in March 2025=C2=B9. A few minor adjustments were made to BIP=E2= =80=AF3
since then (see below). I have since April maintained a pull request
that would activate BIP=E2=80=AF3: https://github.com/bitco= in/bips/pull/1820.

At this point,=E2=80=AFBIP=E2=80=AF3 has received over 600 comments on GitH= ub 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=E2=80=AF3 by leaving an A= CK 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=E2=80=AF3 to replace BIP=E2=80=AF2= as our BIPs
Process.

Since BIP=E2=80=AF2 doesn=E2=80=99t specify a procedure for activating Proc= ess 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=E2=80=AF3 has long been proposed and the activation PR has been o= pen
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=E2=80=AF3 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=E2=80=AF3 was advanced to Proposed:

- The License header now uses SPDX License Expressions=C2=B2
- 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=C2=B2
- The =E2=80=9CCreated=E2=80=9D header has been renamed to =E2=80=9CAssigne= d=E2=80=9D=C2=B3
- The BIP text has been improved to clarify:
=C2=A0=C2=A0 - the purpose of the BIPs repository=E2=81=B4
=C2=A0=C2=A0 - that authors should establish viability of their proposal on= the
mailing list=E2=81=B4
=C2=A0=C2=A0 - the distinction between publication, acceptance, and adoptio= n of
proposals=E2=81=B4
=C2=A0=C2=A0 - when Draft BIPs can be closed due to not making progress=E2= =81=B4
=C2=A0=C2=A0 - that BIPs submissions may not be generated by AI/LLM=E2=81= =B5

=E2=81=B0 https://github.com/bitcoin/bips/blo= b/master/bip-0003.md
=C2=B9 https://github.com/bitcoin/bips/pull/1794
=C2=B2 https://github.com/bitcoin/bips/pull/1892
=C2=B3 https://github.com/bitcoin/bips/pull/1970
=E2=81=B4 https://github.com/bitcoin/bips/pull/1819
=E2=81=B5 https://github.com/bitcoin/bips/pull/2006

Hi all,

I'm writing in response to Murch's motion to activate BIP 3. I a= ppreciate both the extensive work that's gone into this proposal and th= e 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, an= d I appreciate these improvements. I've spent some time in IETF and W3C= processes over the years, including recommending RFC 7282 to this list dur= ing the Taproot discussions, so some of the thoughts below reflect lessons = learned from those environments. That said, Bitcoin's governance contex= t 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-m= odify without requiring such a log, which leaves ambiguity around how conse= nsus is determined. A short objections/resolution record, even as simple as= a changelog section noting =E2=80=9CObjection raised by X regarding Y; add= ressed by Z=E2=80=9D, would address this and provide helpful context for fu= ture readers.

2. RFC 7282: neutral consensus evaluation

RFC 7282 discourages authors from judging consensus on their own work. U= nder BIP 3, a small editor group collectively evaluates numbering, closure,= "material progress," "lack of interest," and rough con= sensus itself. This concentration of authority may create perceived conflic= ts of interest, even with the best intentions.

A minimal safeguard would be requiring two non-author editors, ideally f= rom 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 t= he Draft-to-Complete threshold, this would ensure independent assessment.

3. Subjectivity in number assignment

Declining numbers due to "lack of interest" or "insuffici= ent progress" is reasonable in intent but subjective in effect. A brie= f explanation, even a single sentence in the PR, would help newcomers under= stand 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" simplifie= s the system but loses useful distinctions that help readers understand why= a proposal didn't advance. Optional status annotations (e.g., "Cl= osed (Withdrawn by author)" or "Closed (Superseded by BIP X)"= ;) could preserve this context without complicating the core status model.<= /p>

Lightweight adjustments for RFC alignment and neutrality

  • Short objections/resolution log for Process BIPs (can be minimal changel= og format)

  • Neutral consensus verification by two non-author editors, preferably cro= ss-ecosystem

  • Brief explanations for number denials and "stalled" Draft BIPs=

  • Optional annotations for Closed statuses to preserve historical context<= /p>

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 su= bstantial time, and these mechanisms are intended to make the role more sus= tainable, not more burdensome.

I may have overlooked important practical constraints or misunderstood p= arts of the current process. I'd be interested to hear whether others s= ee value in these additions, have alternative approaches to strengthening n= eutrality around Process BIPs, or believe the current design better serves = Bitcoin's governance needs.

Looking forward to the discussion.

Best,
Melvin

=C2=A0


--
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/205b353= 2-ccc1-4b2f-964f-264fc6e0e70b%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%2BFHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg%40ma= il.gmail.com.
--0000000000007126b4064391028b--