From: Murch <murch@murch.one>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Tue, 2 Dec 2025 14:46:52 -0800 [thread overview]
Message-ID: <af4c26b2-f802-4470-b31e-69c17511eb8c@murch.one> (raw)
In-Reply-To: <9456f7d3-1a45-489a-81b8-bb8fdabb7a9b@dashjr.org>
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
> #2037 to address these issues:
>
> * It misses that BIPs should be relevant to more than just one Bitcoin
> project.
No, it doesn’t. It states so in the _Workflow > Ideation_ subsection.
> * AI/LLM usage disclosure is too much. As long as no content is LLM-
> generated, we should be fine.
It looks to me like the prevailing opinion is that the change regarding
AI should be rolled back either way.
> * Authors/Deputies assumes the champion (Author) was involved in writing
> the document. This is a deviation from the current process where the
> champion can be reassigned by editors if the current one is MIA.
While I don’t think BIP3 says that, it is generally the case that the
Authors were involved in creating the document. Also, the line that you
propose to change in your pull request describes the Deputies, not the
Authors, which seems odd in the context of the commit message and your
assertion here.
Either way, BIP3 redefines Owner roles by introducing Deputies, so if an
Author is MIA, someone that takes over the BIP could be assigned either
as an Author or as a Deputy under BIP3. If the document is still in
draft and the new owners are expected to evolve the document
significantly, I don’t see an issue with them being referred to as
Authors, if they are just advocating for the proposal, they could be
Deputies. I’m not convinced this is a significant issue.
> * Required sections lacks an actual content section (typically
> Specification).
Informational BIPs don’t need a Specification section. The BIP Types
section clarifies that Specification BIPs need a Specification section,
while heavily implying that Process BIPs do as well per “Process BIPs
are like Specification BIPs, but [apply to Process]”.
> * Reference Implementation is probably too specific with aux file or PR
> requirement. One might conceive BIPs where the reference is an
> independent/new software repository, for example.
Sure, including dedicated repositories for providing Reference
Implementations seems reasonable.
> * Editors have always been able to assign numbers for their own BIPs -
> that isn't considered self-assignment, and recent confusion in the
> community suggests this should be clarified.
I don’t recall anyone claiming that you weren’t allowed to assign a
number, merely people pointing out that according to BIP2, no number has
been assigned to dathonohm-reduced-data, yet. Your suggested rephrasing
seems fine.
> * The requirement for public discussion/feedback/interest is new, and
> inappropriate. While typically this may be the case, it should be
> possible to put forward BIPs without relying on other contributors.
Your proposed change keeps the criteria exactly as are: correctly
formatted, on-topic, and materially progressed beyond ideation phase.
You only propose to remove the list of examples for how “progressed
beyond ideation phase” might present.
A list of examples is not generally considered to be exhaustive, and the
provided examples are in line with the modus operandi — at least since
we were appointed, no BIP numbers had been assigned before at least one
reviewer commented on the BIP and the BIP author had addressed some
comments. I don’t see how dropping the examples addresses above stated
issue. It would make more sense to me if you were to propose adding
another example or were to suggest rephrasing “materially progressed
beyond ideation”, but as it is, the proposed change is a disimprovement.
> * Test vectors may not be applicable to all specification BIPs.
In that case, stating that should suffice, similar to the Backward
Compatibility section being required even if just to say that there are
no issues to be addressed.
> * "Compliant" is often the wrong term, as BIPs are recommendations.
> "Compatible" seems more appropriate.
The terminology is correct. It must be possible to be compliant with a
Specification BIP, i.e., a Specification BIP must lay out requirements
in a way that implementers can conform with the requirements.
> * Avoid implying every BIP Editor must reply to every new idea sent to
> the ML
The respective sentence already uses “should”, not “must”, but I’m fine
with it being made more explicit that it is not necessary for BIP
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
> confusing and contradictory: it doesn't make sense to require the author
> to have initiated the discussion himself, and the person who did may not
> be interested in taking on the champion role (and may not be willing to
> cooperate with submitting it and subsequently trasferring it)
Just like BIP2, BIP3 suggests that proposals are discussed at least
once, preferably twice on the mailing list. Once as an idea, and then a
second time when a first draft has been written. It’s unclear to me why
anyone but someone involved in writing the proposal would send an early
draft to the mailing list. Therefore, I don’t think it creates an undue
burden to expect people to present their own work, but I’m also fine
with this change being reverted. I don’t think it’s all that useful.
> * The Rationale stated lowercase "bitcoin" is used to refer to units of
> the currency, but no such reference is made, and instead it is only
> incorrectly used lowercase. All instances have been corrected to
> capitalized and the rationale entry removed.
This came up in review with different reviewers either requesting
capitalization or lowercasing, hence the footnote in the Rationale. I am
not particularly invested either way.
> Additionally, I identified the following issues which may need further
> discussion to address:
>
> * It may make sense to replace "Authors" with "Champions"?
I noticed that BIP2 used both terms interchangeably which I considered
suboptimal. I initially used Champions throughout BIP3, but after
several discussions with reviewers and numerous name suggestions
(Champions, Authors, Proponents, Advocates,…), Authors was broadly
preferred.
See, e.g.,
https://github.com/murchandamus/bips/pull/2#discussion_r1671177693
> * "co-owned by the Bitcoin community" seems like a good idea abstractly,
> but is under-defined and leaves too much to editors' interpretation
I recall someone protesting that a BIP was proposed to get closed as
obsolete, because a node implementation still uses it which resulted in
the BIP remaining in Final instead. That’s the sort of consideration
this section refers to. It also indicates that authors cannot
willy-nilly change Specifications of deployed BIPs.
> * License-Code should probably be either retained or past BIPs folded
> into the single License header.
See BIP Licensing > Specification:
“A few BIP2-era BIPs (98, 116, 117, 330, 340) have a no longer used
"License-Code" header indicating the license terms applicable to
auxiliary source code files. For such cases, please refer to BIP2.”
> * Some BIPs have introduced number registries (eg, HD derivation paths);
> it might be nice to provide some formal guidance in BIP 3
I don’t consider this a blocker for the activation of BIP3. This could
either be a separate proposal, or be added to BIP3 later, if someone
wants to pick that up. I don’t plan on working on this.
> * The set of acceptable licenses is too restrictive, and contradicts
> recommendation to use upstream license. (eg, AGPL) Not having been used
> before is not a good reason in itself to prohibit usage.
As discussed previously and explained in the Rationale, reference
implementations and/or test vectors being licensed solely under copyleft
licenses could introduce friction for BIP implementers. As explained in
the Specification, it is permitted to use more than one license, so BIP
Authors could license their Reference Implementation or Test Vectors
under an acceptable license with AGPL as an alternative.
> * Not all BIPs' Created dates are the dates of assignment. Are we going
> 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
once as “date created on” and another time as the “date that the BIP was
assigned a number”. Foremost, this change clarifies which of the two
dates is expected to be used in future BIPs, but if people insist that
past BIPs get corrected, it should be easy enough to crowdsource these
corrections or work through them.
> * Why increase the Title length?
It was suggested by a reviewer here and seemed reasonable. The title
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,
> but the "Changed from BIP 2" section plans to eliminate this reason for
> doing so.
I think you misread that. It says “the rule that [the layer header] is
only available to _Standards Track_ BIPs is dropped” (emphasis added),
and the _Changes from BIP 2_ sections says “The "Layer" header is
optional for Specification BIPs or Informational BIPs”. I don’t think
these two are contradictory, as either way, there currently exist a lot
of Informational BIPs that have Layer headers.
> * "When is a BIP "accepted"?" writes off BIP 2's Comments feature, but
> ignores that BIP 2 also includes extensive explainations for determining
> if a BIP has been accepted or not, which seem still largely applicable.
It’s not clear to me what you think the problem here is, nor what you
propose to change. The comment feature got hardly used and seemed more
detrimental than useful which is why BIP3 proposes to remove it.
> "Why are Process BIPs living documents?" similarly reduces that feature
> to "especially with fork proposals in mind" which is also untrue. These
> 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
statuses in BIP2 that seemed particularly geared toward fork proposals.
I’m not sure why you think BIPs being living documents has anything to
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
numbers to their own BIPs
- Make more explicit that BIP Editors don’t need to respond to every BIP
idea or draft on the mailing list
- Optional: Provide additional example how “Progressed beyond Ideation”
may express
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/af4c26b2-f802-4470-b31e-69c17511eb8c%40murch.one.
next prev parent reply other threads:[~2025-12-02 22:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 1:10 Murch
2025-11-05 1:53 ` Ruben Somsen
2025-11-12 19:03 ` [bitcoindev] " Greg Sanders
2025-11-13 0:23 ` Murch
2025-11-13 18:54 ` Greg Sanders
[not found] ` <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com>
2025-11-13 19:35 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-11-13 21:43 ` Murch
2025-11-14 17:05 ` Melvin Carvalho
2025-11-22 23:46 ` Murch
2025-11-29 23:00 ` Melvin Carvalho
2025-12-02 0:29 ` Murch
2025-11-15 22:01 ` Luke Dashjr
2025-11-18 4:26 ` Greg Maxwell
2025-12-02 22:46 ` Murch [this message]
2025-11-18 15:47 ` David A. Harding
2025-11-19 1:12 ` Greg Maxwell
2025-11-19 1:20 ` Bryan Bishop
2025-11-19 21:21 ` Jon Atack
2025-11-19 6:25 ` David A. Harding
2025-11-19 6:58 ` Bitcoin Error Log
2025-11-20 1:22 ` Bitcoin Mechanic
2025-11-20 9:06 ` Oghenovo Usiwoma
2025-11-20 17:23 ` Greg Maxwell
2025-11-22 15:14 ` Jon Atack
2025-11-22 19:30 ` Sjors Provoost
2025-11-22 20:53 ` /dev /fd0
2025-11-28 15:35 ` Tim Ruffing
2025-11-28 16:34 ` Jon Atack
2025-11-28 19:21 ` Pieter Wuille
2025-11-22 21:06 ` Bill MacDonald
2025-11-20 20:14 ` Mat Balez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af4c26b2-f802-4470-b31e-69c17511eb8c@murch.one \
--to=murch@murch.one \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox