if anything I think the AI disclosure is arguably too weak, particularly with the well documented instances of LLM psychosis and other weird influence and judgement compromising effects. The current text seems adequate to me and shouldn't be weakened further. On Mon, Nov 17, 2025 at 11:21 PM 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. > * 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 > . > -- 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/CAAS2fgRSCqdjde%2B%3DZJcDkPmkfmSvEHdxcrM7fC1h8T7J6kzSFg%40mail.gmail.com.