From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 02 Dec 2025 14:55:19 -0800 Received: from mail-ot1-f62.google.com ([209.85.210.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 1vQZHC-0006o4-Hr for bitcoindev@gnusha.org; Tue, 02 Dec 2025 14:55:19 -0800 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7c702347c6esf3992465a34.1 for ; Tue, 02 Dec 2025 14:55:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764716112; cv=pass; d=google.com; s=arc-20240605; b=E9XkJTkt4MDvthkNLKVpPJ/ydHDPZ6cwraF61pDyPv8vOyfKCwpdvIYgErZoQHHAxA pFNe+trPTeR6+BhFuLOWs16SiQU8cPVeCGBQvPXZC9JJHX/5muz2Zhn3FQvw9P2JC792 oXPJdZojHis5q0XtO6rETBhMSBsLyBBa3sJU+llYwmhgPeCHqXw2TR5a7TLKJeLfwJ+P YhC1Mw9U9YiKM5HS5iuRBRkdAbwHYBJXhqxb5sTY5K93JaR32eg3ll8EQHEMiT8kcsiZ 6NaYR+I4c5IVDCIBkg+ympVbFm0RWYuIQvQ4Pej04lGVUBbz+EhroTYC4DborKcvP8bn VGUA== 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:content-language:references:to:subject:from:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=aY7F73LnX3cHHGvX0YzhNEZOlzNP22J2Tz7bsvFMIHA=; fh=x8Hl/Oiv56+36Us3ZjxWnX3tvcHM1gZyN0sBBZwvYTQ=; b=kW1Bx8oKZRNkRd4uxSmdyCxjo0peEAMnp1wkssxGJZ/F1ZT+ymgR1dMKAT5dGVI9GE ZoMHoXWP1MZIBHpWvbaNUdrbhi1vsJI/pQ5qU54GKdY8WBMOUDk5wyJFmmLlWZhwu0sc SAWBO3NuuKoj8hrman0TAaimSC8cK1nEBop4Rs83C6YiJoRpGS5+TPaSeufB/3BBTaNQ e5lB/DQ3uVxMDyXdp+Lb7klnvSxOh7fYTl9gTAASCtm8pcnbW5QpW2U1UnCc01Jv8F6M dS3KvD1nKEye0RfhQ8a+0HarK62TfLQnLnNGNDrl7FYp9ci2YHXxQvR0UyYRHWDjzveF rSxw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="KOEPoHJ/"; 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=1764716112; x=1765320912; 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 :content-language:references:to:subject:from:user-agent:mime-version :date:message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=aY7F73LnX3cHHGvX0YzhNEZOlzNP22J2Tz7bsvFMIHA=; b=ChMQ9hQ9gLk6Ye7nLxGDOirKZa5r/kQYlOWdTMhvA5AjNLtW8e6YmtBCFuKTzQ/W+W yiZXSQT28G5G1myNyXkGWEqQnmPzeWiDR3BL2AhFFdNQDM3/hqWWNZYt/RHQYQUgxrxy nAR8GDBmaQmpxIcl8jVV41Wj7nvy1jJQ4uz/Klde9mqP+iV3obrogiar7skWd1cTtiOe 2aQ7GHhFdV4pahDndnnbUAxnWhGY+ghNR0Dh97jH1jvw0UMRsrykh9kF1q/p5XJqfBeR fLH/Qs8xH6Aj+sry09VXeJDG5W9nHl1VXC/R8rpd7y1ClFUnrXOAVm/yGwdyQi3EihM4 skRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764716112; x=1765320912; 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 :content-language:references:to:subject:from:user-agent:mime-version :date:message-id:x-beenthere:x-gm-message-state:sender:from:to:cc :subject:date:message-id:reply-to; bh=aY7F73LnX3cHHGvX0YzhNEZOlzNP22J2Tz7bsvFMIHA=; b=Cue0+N4lbTkgyqsjJf8GwctcoY3tTygQKgahiwNMTNNcmfspDuYfdiCrprBZIK8fND D9xZKVa23Yx80kZYCUzG8sc89Zirdth/OtdV3zPq5K6tyr0l2ZmtlePmGCiW1A60MDyu MNjqJ7q2FkdY7HtPes6yx7AJx+rf7yBCxFTFleNYFVMV0DrCrxyzaLI4kwfEL5vd1uyR 789vavoG9187DgpXS9/4TR79VdJj72wo8a2zxPXO3V7MTxqZQAWLRYEF4jI80HWcF/Fq A6njxFbATBkeAK9VwVl2XPJNSN6oiKNHErr1GUSrlnW7ebXxvBMn7gT3LKuGUsJsfcGS 6qoQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXEXC4/XArLPMMV1HxbEeB3jcNJ1lrMIOt+0oGXqt6f9+r28YXjLKVCv6TwgDsBaYMGXDqwsfBS6NR4@gnusha.org X-Gm-Message-State: AOJu0YxkQJNDOmRIjny8wI3nz1jhm89fwu7vmWIwMhmnS1rQPhU1KWrm ou33fbvEUz36KE5xn+qyQulMZibbnuVaT5TqRfZyiGBh4E/R1+4/3YD7 X-Google-Smtp-Source: AGHT+IFAECz4KXt/pyxHqLK+olns+O0LNKYl7zidIaPCeccJTBvMDxS43U7YacFGOv/LTfKwJtqazA== X-Received: by 2002:a05:6830:2e13:b0:7c7:5b4a:2752 with SMTP id 46e09a7af769-7c94dc41390mr188121a34.27.1764716112184; Tue, 02 Dec 2025 14:55:12 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+alLcecafG2qrsQC0VZZo9XM8zHtTYk3i2qb4HjsTsfjg==" Received: by 2002:a05:6820:2b16:b0:656:d2f6:eae5 with SMTP id 006d021491bc7-6592fe6039bls1282696eaf.0.-pod-prod-04-us; Tue, 02 Dec 2025 14:55:07 -0800 (PST) X-Received: by 2002:a05:6808:c2ca:b0:44d:aa05:ce74 with SMTP id 5614622812f47-4536e3f0af0mr59196b6e.19.1764716107634; Tue, 02 Dec 2025 14:55:07 -0800 (PST) Received: by 2002:ab3:109e:0:b0:2d1:a641:6210 with SMTP id a1c4a302cd1d6-2d36a18312dmsc7a; Tue, 2 Dec 2025 14:46:59 -0800 (PST) X-Received: by 2002:a05:651c:31da:b0:37b:b8c0:b5e1 with SMTP id 38308e7fff4ca-37e638e35e1mr1163931fa.27.1764715616295; Tue, 02 Dec 2025 14:46:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764715616; cv=none; d=google.com; s=arc-20240605; b=XHeqpYSr0IbCMOAua76lsCPuSAEhSLQ6xBMX6egdVKDQY+CV1uwI7FavRgSx++rYgk xrprbPZAR67r24sUDeUfnT3X4OGryiNW23UtvB6AkbEu2alchtAkTZ/rsB2I7eaCJ9Bx mT1p132QSXvar2YFhhmmcZfADGOTXcEVufFCtGaxphms4HE/Jk1bETKn7ibvPjtm5UFO gwhX/PesTjIqSiAfhd9xwAn+IIkjUA0JN1IBHXiu5dTXJy8sbz6IfZPCiAY3/i4eAORa IqnTHRGwdY2piAlPr/UGQZnnFN/8fsJ4B+XxPmHDQsQVFknTD5OL2owdJZ8fZuWx+INA 7H1A== 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 :content-language:references:to:subject:from:user-agent:mime-version :date:message-id; bh=c2hO/NbFF/Vha5FeRzj1ssSTUm+LsWfXc3LgMsO8ARM=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=boJOKhcxlpT8a5MnYmHlB2j8sC7I8NffWMjKeBMHuFjeNgBgWivkLQwYCK2hENiKh9 HGm1k9wNIsfiGC3HPpKJUmzqGX0h8QbKoQORMVOD+fExrpn/YvPbiQHjCDttdIwEQqTf LOoF0+P7/APne47xVCM1P6Xwnnmz6MiZTT+2gvARYBJtwTag6WbkW1sr9N2PoMCxoprr wnKxEgW6MgKkA/xR6jt90y59pzhEP3eiGmUgtyBY/AEvD0zYLSHO16PKfFpU45o78ATf nC7IiPclsdTlXhJr3pxxWifJlIUVlTLzrEQ0bRYLPYjkRE2Url8/n5D/zEytidHV72Gx ZtTw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="KOEPoHJ/"; 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 38308e7fff4ca-37d236ad495si1901021fa.1.2025.12.02.14.46.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Dec 2025 14:46:56 -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 7C57260D22 for ; Tue, 02 Dec 2025 23:46:55 +0100 (CET) Received: (qmail 32235 invoked by uid 989); 2 Dec 2025 22:46:55 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Tue, 02 Dec 2025 23:46:55 +0100 Message-ID: Date: Tue, 2 Dec 2025 14:46:52 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Murch Subject: Re: [bitcoindev] Motion to Activate BIP 3 To: bitcoindev@googlegroups.com References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> <9456f7d3-1a45-489a-81b8-bb8fdabb7a9b@dashjr.org> Content-Language: en-US In-Reply-To: <9456f7d3-1a45-489a-81b8-bb8fdabb7a9b@dashjr.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-2.999992) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.089992 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="KOEPoHJ/"; 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 (/) Thanks for the review, Luke. On 2025-11-15 14:01, Luke Dashjr wrote: > I have completed my review of the current BIP 3 proposal, and opened PR= =20 > #2037 to address these issues: >=20 > * It misses that BIPs should be relevant to more than just one Bitcoin=20 > project. No, it doesn=E2=80=99t. It states so in the _Workflow > Ideation_ subsectio= n. > * AI/LLM usage disclosure is too much. As long as no content is LLM-=20 > generated, we should be fine. It looks to me like the prevailing opinion is that the change regarding=20 AI should be rolled back either way. > * Authors/Deputies assumes the champion (Author) was involved in writing= =20 > the document. This is a deviation from the current process where the=20 > champion can be reassigned by editors if the current one is MIA. While I don=E2=80=99t think BIP3 says that, it is generally the case that t= he=20 Authors were involved in creating the document. Also, the line that you=20 propose to change in your pull request describes the Deputies, not the=20 Authors, which seems odd in the context of the commit message and your=20 assertion here. Either way, BIP3 redefines Owner roles by introducing Deputies, so if an=20 Author is MIA, someone that takes over the BIP could be assigned either=20 as an Author or as a Deputy under BIP3. If the document is still in=20 draft and the new owners are expected to evolve the document=20 significantly, I don=E2=80=99t see an issue with them being referred to as= =20 Authors, if they are just advocating for the proposal, they could be=20 Deputies. I=E2=80=99m not convinced this is a significant issue. > * Required sections lacks an actual content section (typically=20 > Specification). Informational BIPs don=E2=80=99t need a Specification section. The BIP=E2= =80=AFTypes=20 section clarifies that Specification BIPs need a Specification section,=20 while heavily implying that Process BIPs do as well per =E2=80=9CProcess BI= Ps=20 are like Specification BIPs, but [apply to Process]=E2=80=9D. > * Reference Implementation is probably too specific with aux file or PR= =20 > requirement. One might conceive BIPs where the reference is an=20 > independent/new software repository, for example. Sure, including dedicated repositories for providing Reference=20 Implementations seems reasonable. > * Editors have always been able to assign numbers for their own BIPs -=20 > that isn't considered self-assignment, and recent confusion in the=20 > community suggests this should be clarified. I don=E2=80=99t recall anyone claiming that you weren=E2=80=99t allowed to = assign a=20 number, merely people pointing out that according to BIP2, no number has=20 been assigned to dathonohm-reduced-data, yet. Your suggested rephrasing=20 seems fine. > * The requirement for public discussion/feedback/interest is new, and=20 > inappropriate. While typically this may be the case, it should be=20 > possible to put forward BIPs without relying on other contributors. Your proposed change keeps the criteria exactly as are: correctly=20 formatted, on-topic, and materially progressed beyond ideation phase.=20 You only propose to remove the list of examples for how =E2=80=9Cprogressed= =20 beyond ideation phase=E2=80=9D might present. A list of examples is not generally considered to be exhaustive, and the=20 provided examples are in line with the modus operandi =E2=80=94 at least si= nce=20 we were appointed, no BIP numbers had been assigned before at least one=20 reviewer commented on the BIP and the BIP author had addressed some=20 comments. I don=E2=80=99t see how dropping the examples addresses above sta= ted=20 issue. It would make more sense to me if you were to propose adding=20 another example or were to suggest rephrasing =E2=80=9Cmaterially progresse= d=20 beyond ideation=E2=80=9D, but as it is, the proposed change is a disimprove= ment. > * Test vectors may not be applicable to all specification BIPs. In that case, stating that should suffice, similar to the Backward=20 Compatibility section being required even if just to say that there are=20 no issues to be addressed. > * "Compliant" is often the wrong term, as BIPs are recommendations.=20 > "Compatible" seems more appropriate. The terminology is correct. It must be possible to be compliant with a=20 Specification BIP, i.e., a Specification BIP must lay out requirements=20 in a way that implementers can conform with the requirements. > * Avoid implying every BIP Editor must reply to every new idea sent to=20 > the ML The respective sentence already uses =E2=80=9Cshould=E2=80=9D, not =E2=80= =9Cmust=E2=80=9D, but I=E2=80=99m fine=20 with it being made more explicit that it is not necessary for BIP=20 Editors to respond to every new BIP idea being posted to the mailing list. > * The recent addition of "proposed by one of the authors [to the ML]" is= =20 > confusing and contradictory: it doesn't make sense to require the author= =20 > to have initiated the discussion himself, and the person who did may not= =20 > be interested in taking on the champion role (and may not be willing to= =20 > cooperate with submitting it and subsequently trasferring it) Just like BIP2, BIP3 suggests that proposals are discussed at least=20 once, preferably twice on the mailing list. Once as an idea, and then a=20 second time when a first draft has been written. It=E2=80=99s unclear to me= why=20 anyone but someone involved in writing the proposal would send an early=20 draft to the mailing list. Therefore, I don=E2=80=99t think it creates an u= ndue=20 burden to expect people to present their own work, but I=E2=80=99m also fin= e=20 with this change being reverted. I don=E2=80=99t think it=E2=80=99s all tha= t useful. > * The Rationale stated lowercase "bitcoin" is used to refer to units of= =20 > the currency, but no such reference is made, and instead it is only=20 > incorrectly used lowercase. All instances have been corrected to=20 > capitalized and the rationale entry removed. This came up in review with different reviewers either requesting=20 capitalization or lowercasing, hence the footnote in the Rationale. I am=20 not particularly invested either way. > Additionally, I identified the following issues which may need further=20 > discussion to address: >=20 > * It may make sense to replace "Authors" with "Champions"? I noticed that BIP2 used both terms interchangeably which I considered=20 suboptimal. I initially used Champions throughout BIP3, but after=20 several discussions with reviewers and numerous name suggestions=20 (Champions, Authors, Proponents, Advocates,=E2=80=A6), Authors was broadly= =20 preferred. See, e.g.,=20 https://github.com/murchandamus/bips/pull/2#discussion_r1671177693 > * "co-owned by the Bitcoin community" seems like a good idea abstractly,= =20 > but is under-defined and leaves too much to editors' interpretation I recall someone protesting that a BIP was proposed to get closed as=20 obsolete, because a node implementation still uses it which resulted in=20 the BIP remaining in Final instead. That=E2=80=99s the sort of consideratio= n=20 this section refers to. It also indicates that authors cannot=20 willy-nilly change Specifications of deployed BIPs. > * License-Code should probably be either retained or past BIPs folded=20 > into the single License header. See BIP Licensing > Specification: =E2=80=9CA few BIP2-era BIPs (98, 116, 117, 330, 340) have a no longer used= =20 "License-Code" header indicating the license terms applicable to=20 auxiliary source code files. For such cases, please refer to BIP2.=E2=80=9D > * Some BIPs have introduced number registries (eg, HD derivation paths);= =20 > it might be nice to provide some formal guidance in BIP 3 I don=E2=80=99t consider this a blocker for the activation of BIP3. This co= uld=20 either be a separate proposal, or be added to BIP3 later, if someone=20 wants to pick that up. I don=E2=80=99t plan on working on this. > * The set of acceptable licenses is too restrictive, and contradicts=20 > recommendation to use upstream license. (eg, AGPL) Not having been used= =20 > before is not a good reason in itself to prohibit usage. As discussed previously and explained in the Rationale, reference=20 implementations and/or test vectors being licensed solely under copyleft=20 licenses could introduce friction for BIP=E2=80=AFimplementers. As explaine= d in=20 the Specification, it is permitted to use more than one license, so BIP=20 Authors could license their Reference Implementation or Test Vectors=20 under an acceptable license with AGPL as an alternative. > * Not all BIPs' Created dates are the dates of assignment. Are we going= =20 > to dig through history to see when precisely existing BIPs were assigned? BIP2 was ambiguous in that it called the header Created and described it=20 once as =E2=80=9Cdate created on=E2=80=9D and another time as the =E2=80=9C= date that the BIP was=20 assigned a number=E2=80=9D. Foremost, this change clarifies which of the tw= o=20 dates is expected to be used in future BIPs, but if people insist that=20 past BIPs get corrected, it should be easy enough to crowdsource these=20 corrections or work through them. > * Why increase the Title length? It was suggested by a reviewer here and seemed reasonable. The title=20 limit is violated by numerous BIPs anyway. See: https://github.com/murchandamus/bips/pull/2#discussion_r1759508846 > * Rationale states the Layer is permitted for non-Specification BIPs,=20 > but the "Changed from BIP 2" section plans to eliminate this reason for= =20 > doing so. I think you misread that. It says =E2=80=9Cthe rule that [the layer header]= is=20 only available to _Standards Track_ BIPs is dropped=E2=80=9D (emphasis adde= d),=20 and the _Changes from BIP 2_ sections says =E2=80=9CThe "Layer" header is= =20 optional for Specification BIPs or Informational BIPs=E2=80=9D. I don=E2=80= =99t think=20 these two are contradictory, as either way, there currently exist a lot=20 of Informational BIPs that have Layer headers. > * "When is a BIP "accepted"?" writes off BIP 2's Comments feature, but=20 > ignores that BIP 2 also includes extensive explainations for determining= =20 > if a BIP has been accepted or not, which seem still largely applicable.= =20 It=E2=80=99s not clear to me what you think the problem here is, nor what y= ou=20 propose to change. The comment feature got hardly used and seemed more=20 detrimental than useful which is why BIP3 proposes to remove it. > "Why are Process BIPs living documents?" similarly reduces that feature= =20 > to "especially with fork proposals in mind" which is also untrue. These= =20 > should probably get improved, even if BIP 3 doesn't mirror this feature. It is the description of when BIPs change status and the multitude of=20 statuses in BIP2 that seemed particularly geared toward fork proposals.=20 I=E2=80=99m not sure why you think BIPs being living documents has anything= to=20 do with the comment feature. In conclusion, it seems to me that the following changes could be adopted: - Revert guidance regarding AI - Broaden how Reference Implementations may be provided - Clarify language to remove implication BIP Editors may not assign=20 numbers to their own BIPs - Make more explicit that BIP Editors don=E2=80=99t need to respond to ever= y BIP=20 idea or draft on the mailing list - Optional: Provide additional example how =E2=80=9CProgressed beyond Ideat= ion=E2=80=9D=20 may express 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/= af4c26b2-f802-4470-b31e-69c17511eb8c%40murch.one.