From: Luke Dashjr <luke@dashjr.org>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Sat, 15 Nov 2025 17:01:40 -0500 [thread overview]
Message-ID: <9456f7d3-1a45-489a-81b8-bb8fdabb7a9b@dashjr.org> (raw)
In-Reply-To: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one>
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.
* AI/LLM usage disclosure is too much. As long as no content is
LLM-generated, we should be fine.
* 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.
* Required sections lacks an actual content section (typically
Specification).
* 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.
* 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.
* 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.
* Test vectors may not be applicable to all specification BIPs.
* "Compliant" is often the wrong term, as BIPs are recommendations.
"Compatible" seems more appropriate.
* Avoid implying every BIP Editor must reply to every new idea sent to
the ML
* 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)
* 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.
Additionally, I identified the following issues which may need further
discussion to address:
* It may make sense to replace "Authors" with "Champions"?
* "co-owned by the Bitcoin community" seems like a good idea abstractly,
but is under-defined and leaves too much to editors' interpretation
* License-Code should probably be either retained or past BIPs folded
into the single License header.
* Some BIPs have introduced number registries (eg, HD derivation paths);
it might be nice to provide some formal guidance in BIP 3
* 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.
* 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?
* Why increase the Title length?
* 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.
* "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.
"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.
Luke
On 11/4/25 20:10, Murch wrote:
> Dear list,
>
> After planned work on BIP 3⁰ finished in February, BIP 3 was advanced
> to Proposed in March 2025¹. A few minor adjustments were made to BIP 3
> since then (see below). I have since April maintained a pull request
> that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820.
>
> At this point, BIP 3 has received over 600 comments on GitHub 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 3 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 3 to replace BIP 2 as our
> BIPs Process.
>
> Since BIP 2 doesn’t specify a procedure for activating Process 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 3 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 3 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 3 was advanced to Proposed:
>
> - The License header now uses SPDX License Expressions²
> - 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²
> - The “Created” header has been renamed to “Assigned”³
> - The BIP text has been improved to clarify:
> - the purpose of the BIPs repository⁴
> - that authors should establish viability of their proposal on the
> mailing list⁴
> - the distinction between publication, acceptance, and adoption of
> proposals⁴
> - when Draft BIPs can be closed due to not making progress⁴
> - that BIPs submissions may not be generated by AI/LLM⁵
>
> ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md
> ¹ https://github.com/bitcoin/bips/pull/1794
> ² https://github.com/bitcoin/bips/pull/1892
> ³ https://github.com/bitcoin/bips/pull/1970
> ⁴ https://github.com/bitcoin/bips/pull/1819
> ⁵ https://github.com/bitcoin/bips/pull/2006
>
--
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/9456f7d3-1a45-489a-81b8-bb8fdabb7a9b%40dashjr.org.
next prev parent reply other threads:[~2025-11-17 23:21 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 [this message]
2025-11-18 4:26 ` Greg Maxwell
2025-12-02 22:46 ` Murch
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=9456f7d3-1a45-489a-81b8-bb8fdabb7a9b@dashjr.org \
--to=luke@dashjr.org \
--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