From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 01 Dec 2025 16:31:22 -0800 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vQEIb-0001UL-LD for bitcoindev@gnusha.org; Mon, 01 Dec 2025 16:31:22 -0800 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-450fd003480sf5613349b6e.2 for ; Mon, 01 Dec 2025 16:31:21 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764635475; cv=pass; d=google.com; s=arc-20240605; b=MMkllMWNGorXYFBbtGp3arweo1Va/8fEf3ie11ANncy9JLaBnYk6PqhsT1soFDoyna bnzDhAG/2FgH+U4toXA9e93ZTPVqSEY+FxrsGaBiri0SOq8tqZGBguiQWYg+mADSyKFA a83LbUR4+lOpFGoE9JFH9OkVEK86ZY89cm8dIp3nuX03Ps8ZOTtln81kHquhwP02h3RR Ztm6bCe5Pdk7AcgEw4KtjYS97uXvjVjeKPrdbxm0zGFlsOq3BwXJ+kQ9KBvoDJAMKERd EeTq1x4OREFPq6QnrtcJdxpobiRoXu3OQFbDYJCXMeZvILTWuqi1PRnNSpQcD9VeoDiK CmRg== 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=dZ0GeDNRW7SIm4OIqfJ4ocQgpLRhOzL1Q/2ErazkwMA=; fh=/FeSvqunrW7DSWnT113zjdkFvWxp4ICRcKveibUSv+8=; b=aLJwUInPOEBEeYJVL50hIS7EUi7Tf1q/dLimEHLHN9v5SouSJtSxchmXZ1ajSedMMR DTjBZ7nAUkvDAqZn0xxkFVHK6qNpE1TEwavjgE0aU+ggxyNWJvBcDIFFaBowIb0ZQp6D jfagXWSHl2goASDUa25wR9/m17vW22mHOFFh9Is7tYw2nwKUgHJTFE0/dfbJTtJB1eEa huJAD/jvyoI5RyVpqMNPwV3v4R/CEWJOd/NStzEQwBRxFdf9iFjre7ZgH6Lwu/p0Whtc Xn38di7tsdNiNDfhh46SpkP2nB5D16UpjtnRFanpU9JVOn8fyEIy7+ujyuC1R+p0vOiU fh7g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=O9FHTgp0; 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=1764635475; x=1765240275; 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=dZ0GeDNRW7SIm4OIqfJ4ocQgpLRhOzL1Q/2ErazkwMA=; b=R1Z9nZsi8eccvfMA81g5G8nUJuJZzopEiCNO8PFBc6G+Tj51ad3gKQhKJOaEgHtJYR Yfp7gaichQkrwzmQugq88hek+hEuMSxtXZdnvg9/GNBiQG+LHGNw+DnrxiNe83fEP0hJ 0JTbHB6SRIF+MyCZ62cDbYolH1HMHfETShdNt+2EIZ/PRLWbBfnLjI2wrsOh5ZKF/1ok jUAhY04T0VNuXHgD1mr0685nlne4hw5P7My/dQNXpNgjJIHSlcdUuMqBeyPytJLdWvjs gq8yfu1i0DONGMnt5XesSRJl3M6q058BPYsvRxZ9Fx0Hq5aNgXtTHpPemFA8CxwRKY+W u7pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764635475; x=1765240275; 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=dZ0GeDNRW7SIm4OIqfJ4ocQgpLRhOzL1Q/2ErazkwMA=; b=GK8Tze3MSXkPcFxq8gw0fRlcJ3Yu9UFZUqwG/qsjCL5EAR8Esi/p3hmT6Y3E0G/68R WheG4ph77UOBTQBoo8SoXp3C6gvDJvGy7UXQ5peepwliE0BG0nQliX5fzWQsX5kDBsJO w6Ws6sec28n6dnMynqiQt1HJ0sFBPo4S5F6tH0jeiO7b6on5Swxx+Uw9sOC/vuvdnWzu 6/7I71NbmbyAT6aJdDABtO0xVE36A6dIv87srWvUb2YhV5M6mb/OMlpSDbu9XpBbIPo+ VGqYWxLo5FZ8fPfyLGLbCvmhYTtOpF4xFMpaLp6xWXuRrD5jU5SECHMw9icOsIqRQysa cRHw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUfRhCrmI1brcWuW5rohnKkhAlMbZvpCZxu5CgfVGHy8vz9GmdbwEQpqP7ZW/eBsDJMDjmslKg4e8/T@gnusha.org X-Gm-Message-State: AOJu0YwKvWWM4PO70Ng+IJGvpyvx9ERlD452emkcoW3lhUTdoHkzPep2 vu2OaF8m0+ne6J19Cj7zsPyOTUrg2VTL/USnFZNt1qC1QNnS3GWY9zMi X-Google-Smtp-Source: AGHT+IEZHxRv4e/SKeQRuqZ26vdMDQjL60VH6MaBw+KaTi5sSvddd4PBHhx09MCOblmzSBUItD/FgQ== X-Received: by 2002:a05:6808:2219:b0:450:b947:1da7 with SMTP id 5614622812f47-4514e7f43f0mr11224894b6e.36.1764635474976; Mon, 01 Dec 2025 16:31:14 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bIYYzs9LX75FHjfQXAceyUfQqR77DXAQVI2WsxG3TX8A==" Received: by 2002:a05:6871:2e91:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3f0d2386a7cls3498360fac.0.-pod-prod-09-us; Mon, 01 Dec 2025 16:31:09 -0800 (PST) X-Received: by 2002:a05:6808:c3ef:b0:44f:e1af:21f4 with SMTP id 5614622812f47-4514e65a0b3mr12793438b6e.4.1764635469441; Mon, 01 Dec 2025 16:31:09 -0800 (PST) Received: by 2002:a05:600d:4:b0:471:13aa:415a with SMTP id 5b1f17b1804b1-4790ad9768dms5e9; Mon, 1 Dec 2025 16:29:07 -0800 (PST) X-Received: by 2002:a05:600c:4691:b0:477:58af:a91d with SMTP id 5b1f17b1804b1-477c10c8e61mr380403595e9.5.1764635344489; Mon, 01 Dec 2025 16:29:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764635344; cv=none; d=google.com; s=arc-20240605; b=gYKfCzLmhQz3Rp+mSHRmadO/C0GJyRe61xKD1WRVW6XPRw77NoOzs49p4XW8kBB1kg ErOeY2nbUrfEI70uV2bDW2KJWWjaCkr4UeTLVgv4sL/y0qOSP/Nx/SDvmQINWlw2g7UH Y6ddc1wfa1vI7SlWLdxKzdaTvl7hc2H5GaT+2+CjIJ/mnKKWCAfyTYwm4mYgiIzl3HYV VSnibEk2JW2XFSy7IZuHT7zCwQPgQzhO3hyauuredtuVzum8eLZMcOABoc7dgAgR37Pt mCsuzKzi641Pxwseq892fNs8UPv2qwGkBtbGvFth7x/NcY7TEL+9Fgab34vIdFnlyw1k 7qCA== 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=FSaE8FsqFdk2fck4uXvGuXxvuZipkg+kYo9SD3pZZOg=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=j4MbBmH5Okw2xnHSYMvlPMkOXGA7YwSKt2xf5XZ2k5EIOFc8PJUKwTO4vfq8nTDZWh JEPs9i4gK+nBAfdxShn1liEaAFg/goXSjlheND+OsRQlxzMd5CvJrh3PlwvSYNvR3DxE lnqDZO+QhGHxrrombXsoENeA3Cd7G3kD14Nc1CIKJDVfE0OfSY8AYDJwq/kV543sUy88 CJanN9oGMIurKXvfHb52lMgJMO6bQF6tdU6VUylyOq5ut4Ic/mtRJEcTUfM7P7p1JRox /+kQXJQfl2BsD85U7NoW7Wecf5jHIghCNp/BcGuAersNN4S6joBRIxgiV9QfxcH8TzgC /LuQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=O9FHTgp0; 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-4790ab850e2si1815095e9.0.2025.12.01.16.29.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Dec 2025 16:29:04 -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 365E660DBE for ; Tue, 02 Dec 2025 01:29:04 +0100 (CET) Received: (qmail 14355 invoked by uid 989); 2 Dec 2025 00:29:04 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Tue, 02 Dec 2025 01:29:03 +0100 Message-ID: Date: Mon, 1 Dec 2025 16:29:01 -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=O9FHTgp0; 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 (/) Hello Melvin, Thanks for restating your previous suggestion. It=E2=80=99s not clear to me= why=20 you think that I would be making the call by myself whether there is=20 rough consensus. In my original email, I wrote: =E2=80=9Cwe give all would-= be=20 reviewers another four weeks, =E2=80=A6 before evaluating whether there is = rough=20 consensus=E2=80=9D. The pertinent subject of the sentence being =E2=80=9Cwe= =E2=80=9D. As I pointed out in my prior email, we never had more than two=20 BIP=E2=80=AFEditors until last April. Requiring the existence of two non-au= thor=20 BIP=E2=80=AFEditors to make changes to Process BIPs would mean that we woul= d not=20 even have been able to add more BIP=E2=80=AFEditors under historically norm= al=20 Editor counts. I was not planning on making the call whether there is rough consensus=20 to activate BIP=E2=80=AF3 anyway, but I=E2=80=99m still not convinced it=E2= =80=99s a good idea=20 to generally adopt the criteria you propose. Murch On 2025-11-29 15:00, Melvin Carvalho wrote: >=20 >=20 > ne 23. 11. 2025 v=C2=A00:53 odes=C3=ADlatel Murch napsa= l: >=20 > Hi Melvin, >=20 > Thank you for your sharing your thoughts. >=20 > On 2025-11-14 09:05, Melvin Carvalho wrote: > > Since BIP 3 cites RFC 7282 as its rough consensus framework >=20 > 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: >=20 > =E2=80=9CA proposal is said to have rough consensus if its advancemen= t has been > open to discussion on the mailing list for at least one month, the > discussion achieved meaningful engagement, and no person maintains an= y > unaddressed substantiated objections to it. Addressed or obstructive > objections may be ignored/overruled by general agreement that they ha= ve > been sufficiently addressed, but clear reasoning must be given in suc= h > circumstances.=E2=80=9D >=20 > =C2=B9 https://github.com/bitcoin/bips/blob/master/bip-0003.md#proces= s- > bips bip-0003.md#process-bips> >=20 > 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 sectio= n > > 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. >=20 > The section mentioned above continues to clarify the mechanism for > modifying Process BIPs: > > =E2=80=9CDeployed Process BIPs may be modified indefinitely as lon= g as a > > proposed modification has rough consensus per the same criteria.= =E2=80=9D >=20 > Further, BIP 3 introduces a Changelog section which requires recordin= g > changes to a BIP after it has reached the Complete status (which also > applies for the Deployed status). >=20 > 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, a= s > modifications have to be discussed on the mailing list, and the chang= es > 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. Eve= n > while they don=E2=80=99t take your proposed format exactly. >=20 > 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 tha= t > reiterates the noteworthy changes I described in my prior emails. >=20 > 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. >=20 > 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 th= e > BIP Process to grind to a halt should the Editor count should fall ba= ck > to the levels that were normal for its entire history except the rece= nt > 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. >=20 > 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 brie= f > > explanation, even a single sentence in the PR, would help newcomer= s > > understand expectations and provide editors with a neutral referen= ce > > point if a decision is later questioned. >=20 > 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 s= ome > 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: >=20 > > =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 >=20 > and the README states: >=20 > > =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 >=20 > 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 preve= nts > participants from seeking clarification. I would also like to reitera= te > that a BIP being published does not guarantee or imply adoption >=20 > =C2=B2 https://github.com/bitcoin/bips/blob/master/bip-0003.md#bip-ed= itor- > responsibilities-and-workflow master/bip-0003.md#bip-editor-responsibilities-and-workflow> >=20 > On 2025-11-14 09:05, Melvin Carvalho wrote: > =C2=A0> *4. Status compression and historical clarity* > > > > Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies th= e > > 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. >=20 > The Closed status indicates that =E2=80=9Ca BIP that is of historical= interest > 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, a= nd > 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 th= at > 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. >=20 > =C2=B3 https://github.com/bitcoin/bips/blob/master/bip-0003.md#closed= 11 > >=20 > 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 >=20 > 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 import= ant > > concerns that were raised and addressed as this proposal was > developed.=E2=80=9C- Changes to Process BIPs must be discussed in pub= lic, > 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=9Cconstructi= ve, > 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. >=20 > =E2=81=B4 https://github.com/bitcoin/bips/blob/master/ > bip-0003.md#specification master/bip-0003.md#specification> >=20 > On 2025-11-14 09:05, Melvin Carvalho wrote: > =C2=A0> These small additions strengthen neutrality and transparency= . They > =C2=A0> 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 intend= ed > > 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 w= ork > happening in public in pull requests and on the mailing list, as well= as > per the requirements for the Rationale and Changelog sections, it see= ms > to me that the proposed Process already provides plenty of paper trai= l. > I would hope that if you gave BIP 3 and especially the Rationale sect= ion > 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. >=20 >=20 > Hi Murch, >=20 > Thank you for the reply. I've followed the subsequent discussion with=20 > interest, Tim and Pieter's points on the AI provisions seem well-taken. >=20 > I want to briefly restate my concern for the record. >=20 > BIP 3 defines how Process BIPs achieve rough consensus, and the author=20 > of BIP 3 is evaluating whether that consensus exists. RFC 7282, the=20 > seminal IETF document on rough consensus that BIP 3 cites as related=20 > work, specifically cautions against this kind of overlap. Whether=20 > adopted formally or not, the reasoning applies. >=20 > My suggestion: require that rough consensus for Process BIPs be=20 > confirmed by at least two non-author editors, ideally from different=20 > implementation ecosystems. This is a small structural safeguard that=20 > strengthens legitimacy and, importantly, distributes responsibility,=20 > protecting editors from being placed in an awkward position when=20 > evaluating contentious proposals. >=20 > I also note that PR #2037 proposes several significant edits to BIP 3's= =20 > scope and mechanics, which suggests there is still active disagreement=20 > on some important details. >=20 > Best, > Melvin >=20 >=20 > Best, > Murch >=20 > --=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 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 > fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one>. >=20 > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com=20 > . > To view this discussion visit https://groups.google.com/d/msgid/=20 > bitcoindev/=20 > CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%40mail.gmail.com= =20 > CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%40mail.gmail.com?= utm_medium=3Demail&utm_source=3Dfooter>. --=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/= ad6ccb6d-9845-4a04-82d4-c052306a2218%40murch.one.