Motion to Activate BIP 3

[Murch]

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

[Ruben Somsen]

Murch, you did an excellent job writing this and taking everyone's feedback into account. I think it's a crystal clear step up and should be adopted.

Thanks for all the hard work.

Cheers,

Ruben

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one.

[Greg Sanders]

Hello Murch,

I really like the BIP, just have a question about the editor portion.

The list of current editors are currently in the BIP text, which seems to imply that the list can be changed by the author himself only and would become "static" over time.

Clearly support for changing has to continue as it goes to Deployed and beyond. Perhaps the text should be moved elsewhere?

Best,

Greg

[Murch]

Hey Greg,

Two sections from BIP 3 stand out as relevant here, “BIP Ownership“ and
“Deployed Process BIPs”.

From “Fundamentals > BIP Ownership”:
> “[…] As a BIP progresses through the workflow, it becomes
increasingly co-owned by the Bitcoin community.”

While Deployed BIPs are considered final and changes should be avoided,
the section has a subsection that specifically addresses Process BIPs.

From “Workflow > Progression through BIP Statuses > Deployed > Process
BIPs”:
> “A Process BIP may change status from Complete to Deployed when it
achieves rough consensus on the Bitcoin Development Mailing List. A
proposal is said to have rough consensus if its advancement has been
open to discussion on the mailing list for at least one month, the
discussion achieved meaningful engagement, and no person maintains any
unaddressed substantiated objections to it. Addressed or obstructive
objections may be ignored/overruled by general agreement that they have
been sufficiently addressed, but clear reasoning must be given in such
circumstances. Deployed Process BIPs may be modified indefinitely as
long as a proposed modification has rough consensus per the same criteria.”

More specific rules supersede general rules, so this subsection on
Process BIPs should hopefully clearly override the general description
in “Deployed”. It follows from these two sections that the BIP Authors’
right to decide about changes to their BIP is moderated by the community
interests. I would consider especially Process BIPs to be dominantly
owned by the community rather than the Authors once they are Deployed.
The quoted section states how they are modified — by proposing and
discussing a modification on the mailing list, which is also a
fitting summary of how we decided last year to add more BIP Editors.

Additionally, the “Workflow > Transferring BIP Ownership” section makes
it clear that other Owners could step up to replace Authors that have
become unreachable.

Pragmatically speaking, it seems obvious that the list of BIP Editors
would be amended in the currently active BIP Process Specification
whenever the active BIP Editors change. Historically, this worked fine
when Editors changed while BIP 1 and BIP 2 were active which both also
specified the current BIP Editors in the same manner.

Thank you for your review. Please let me know, if you think we should
amend BIP 3 to more clearly state any of the above discussed thoughts.

Best,
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+...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/bitcoindev/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Greg Sanders]

Makes sense to me, and this e-mail can be a reference point if there's future discussion.

With what little review I've done, I think this makes sense to activate!

Greg

[Murch]

Dear list,

I would like to correct a small lapse I made in my email from November
4th. I mistakenly thought that the activation process for Process BIPs
was newly introduced with BIP 3, but reading BIP 2 again today, I
realized that it had been adapted from BIP 2.

BIP 2 says:
> A process BIP may change status from Draft to Active when it achieves
rough consensus on the mailing list. Such a proposal is said to have
rough consensus if it has been open to discussion on the development
mailing list for at least one month, and no person maintains any

unaddressed substantiated objections to it. Addressed or obstructive
objections may be ignored/overruled by general agreement that they have
been sufficiently addressed, but clear reasoning must be given in such
circumstances.

Meaning, that I was incorrect when I stated that “BIP 2 doesn’t specify
a procedure for activating Process BIPs”. My apologies.
Either way, the previously proposed motion to activate complies with
BIP 2, so I don’t think there is a need to revise the approach.

Cheers,
Murch

[Antoine Poinsot]

Forwarding my reply to Murch on November 4th, which for some reason i did not also send to the list at the time.


------- Forwarded Message -------
From: Antoine Poinsot <daro...@protonmail.com>
Date: On Tuesday, November 4th, 2025 at 9:58 PM
Subject: Re: [bitcoindev] Motion to Activate BIP 3
To: Murch <mu...@murch.one>


>
>
> Murch,
>
> I am in favour of activating BIP 3. Your proposed timeline seems appropriate to me.
>
> Thanks for your sustained efforts in leading this forward.
>
> Best,
> Antoine Poinsot
>
> -------- Original Message --------

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one.

[Melvin Carvalho]

st 5. 11. 2025 v 2:11 odesílatel Murch <mu...@murch.one> napsal:

Hi all,

I'm writing in response to Murch's motion to activate BIP 3. I appreciate both the extensive work that's gone into this proposal and the invitation to raise concerns during this evaluation period.

Since BIP 3 cites RFC 7282 as its rough consensus framework, I reviewed it with that standard in mind. BIP 3 modernizes many aspects of the process, particularly the streamlined status flow and clearer role definitions, and I appreciate these improvements. I've spent some time in IETF and W3C processes over the years, including recommending RFC 7282 to this list during the Taproot discussions, so some of the thoughts below reflect lessons learned from those environments. That said, Bitcoin's governance context is unique, and I may be missing important considerations.

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 section noting “Objection raised by X regarding Y; addressed by Z”, would address this and provide helpful context for future readers.

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.

3. Subjectivity in number assignment

Declining numbers due to "lack of interest" or "insufficient progress" is reasonable in intent but subjective in effect. A brief explanation, even a single sentence in the PR, would help newcomers understand expectations and provide editors with a neutral reference point if a decision is later questioned.

4. Status compression and historical clarity

Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies the 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.

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 context

These small additions strengthen neutrality and transparency. They 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 intended 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 needs.

Looking forward to the discussion.

Best,
Melvin

[Luke Dashjr]

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

[Greg Maxwell]

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.

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9456f7d3-1a45-489a-81b8-bb8fdabb7a9b%40dashjr.org.

[David A. Harding]

On 2025-11-04 15:10, Murch wrote:
> Summary of changes since BIP 3 was advanced to Proposed:

> [...]

>   - that BIPs submissions may not be generated by AI/LLM⁵

> [...]
> ⁵ https://github.com/bitcoin/bips/pull/2006

I strongly disagree with this change. If I were to begin working on a
new BIP today, I would use AI throughout the process. I'd ask it to
help me create a todo list of what should go in the BIP; I'd ask it to
create a draft based on existing BIPs, my todo list, and whatever other
work products I had (e.g. prototypes); I'd then ask it to help me refine
the document until I was satisfied.

I would, of course, review every word of the draft BIP before submitting
it for consideration and ensure that it represented the highest quality
work I was able to produce---but the ultimate work would be a mix of AI
and human writing and editing.

I think considerate use of AI would be even more valuable for people who
are less comfortable with writing technical English-language documents
than I am. For example, non-native literates, people with disabilities
that make text input difficulty, and those who recognize that they're
bad writers.

The PR forbidding AI doesn't go into any detail about its motivation,
although it references a previous discussion[1] where a low-quality BIP
PR was opened using mostly AI-generated content. I'm guessing the
motivation is that AI (by itself) generates low-quality technical
content, BIPs should be high-quality technical content, and therefore we
should ban the use of AI.

However, as mentioned in the previous discussion, the BIP process
already requires high-quality content.[2] AI-generated content can be
high-quality, especially if its creation and editing was guided by a
knowledgeable human. Banning specific tools like AI seems redundant and
penalizes people who either need those tools or who can use them
effectively.

I advocate for reverting the first hunk of BIPs repository PR 2006.

-Dave

[1] https://github.com/bitcoin/bips/pull/2005
[2] "After fleshing out the proposal further and ensuring that it is of
**high quality** and properly formatted, the authors should open a pull
request to the BIPs repository." --BIP3, emphasis added

[Greg Maxwell]

No doubt *you* are able to make good documents with or without the aid of AI.

With outright AI 'authorship' you immediately run into potential copyright issues-- which I think is the origin of the "generated by" prohibition, otherwise I think disclosure would be sufficient.

Taking a step back: is Bitcoin's welfare maximized by permitting LLM glurge submissions in standards documents? In some cases it's benign, I readily agree, in others its harmful.  But the number of good submissions that could be made would hardly be increased by LLMs (being limited by expert proposers with good ideas) but the number of potential poor submissions is increased astronomically.  So I think it's pretty clearly a net harm to have text authored that way.

I've never had an impression that drafting was at all a limiting step in writing BIPs, though even to the extent that it has been at times it's possible to use LLMs in a review capacity to make authorship much easier ("What's missing / unclear?") without resorting to using it to author.

There is a particularly clear pattern at least with current LLM tools that users who lack the skills to have authored the work without an LLM are generally unable to recognize when the LLM is full of crap (and even sometimes when they should know better), so unfortunately they're only benign to use in the hands of those whose need is the least.  

And as a reviewer outside of Bitcoin I've found LLM powered proposers to be absolutely the worst to deal with. Because they're not submitting their own words and ideas, they're unable to change their thinking in response or explain sufficiently to change yours--- the interactions often degrade to them just copy and pasting their chatbot back to you.  Because it's cheap to generate more text they also tend to flood you out with documents several times longer than any human author would have bothered with.

I think LLMs have generally created something of an existential threat to most open collaborations: Now its so easy to get flooded out by subtly worthless material.  Many projects, including, Bitcoin have long struggled with review capacity being limited and a far amount of time waste by thoughtless (or even crazy!) submissions, but now it's automated and even the most well meaning person may now make submissions that are as bad as the most deviously constructed malicious submissions could have been in the past, not even know they are doing it, and can make a dozen proposals before lunch without even breaking a sweat.

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3a66dbbe9a9c46566c8a9a16ccb1cc91%40dtrt.org.

[Bryan Bishop]

The social norm should be specifically against wasting the time of project volunteers or contributors. It doesn't matter whether the waste was generated by LLMs or biological neurons. If someone wants to donate LLM outputs to an open source project, then I think they should instead donate LLM token credits to any active existing contributors they wish, rather than LLM outputs.

- Bryan
https://x.com/kanzure

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com.

[David A. Harding]

> With outright AI 'authorship' you immediately run into potential
> copyright issues-- which I think is the origin of the "generated by"
> prohibition, otherwise I think disclosure would be sufficient.

What potential issues? I'm not familiar (and did not find in a quick
search) any authors or publishers who were sued for using content
generated by AI; all the lawsuits I found were against companies that
produced AI tools.

> the number of good submissions that could be made would hardly be

> increased by LLMs [...] but the number of potential poor submissions is

> increased astronomically. So I think it's pretty clearly a net harm to
> have text authored that way.

What evidence do you have that the number of good submissions could
hardly be increased by the use of LLMs? (Perhaps see my next point
before replying to this one.)

> I've never had an impression that drafting was at all a limiting step
> in writing BIPs

Ten years ago, I wrote the draft text for what became BIP125 because
several developers in a public Bitcoin Core IRC meeting said they
thought there should be a BIP. I think they were all hoping that
someone else would do it, and I have no way to tell if it would've been
written had I not volunteered.

I wonder if there's a hidden survivorship bias in your impression of the
situation. It's easy to think of all the great BIPs we have today---but
how many great BIPs could we have had if creating them was faster and
easier? I think many Bitcoin developers feel "better with code than
words" and only undertake documentation tasks reluctantly; if AI can
help write documentation, even just a rough draft, is that not a boon?

> I think LLMs have generally created something of an existential threat
> to most open collaborations: Now its so easy to get flooded out by
> subtly worthless material.

Is it not equally something of an existential threat to open
collaboration to deny to open collaborators the powerful tools that
closed collaborators may use? I like AI-assisted writing; my response
to BIP3 being deployed in its current form will not be to write
manually; it will be to use AI but publish elsewhere---likely a place
with fewer openly collaborating peer reviewers than the current BIPs
repo. (This is hypothetical; I have no current plans to write any
specification documents.)

-Dave

[Jon Atack]

Hi list,

I agree with Greg Maxwell's thoughts on AI use.

We have been seeing quite a bit of AI-generated PRs being thrown over the fence at us in the BIPs repository.

In a few cases, the proposed fixes are useful.

In many others, they seem to be a waste of review/maintenance/moderation bandwidth and time, and are demotivating to deal with.

I am also aware of BIPs that turned out to have been largely generated or rewritten to final form by LLMs. I am not a lawyer, but the copyright situation WRT such BIPs seems unclear and evolving. This was not the principal motivation of the BIP 3 addition about AI/LLM use -- not wasting our time is -- but is a context that may need keeping tabs on.

Personally, I don't wish to spend time manually reviewing AI slop or hallucinations.

Due to what we're seeing and to what Greg rightly describes above, I think we'll need to set up auto-review by LLMs in the CI pipeline for (a) a degree of confidence grade of AI being used, and (b) perhaps an initial technical review. Similar to Drahtbot in Bitcoin Core and to what I see in use in other organizations that I review for.

For now, these tools will vitally need to be followed by human review and subjective judgment calls on our part.

The BIP 3 section about reducing judgment calls is probably unrealistic at this time and in need of an update before activation.

Best.

[Bitcoin Error Log]

A few years ago, I had this idea that bitcoin divisibility needed to be fixed as a misconception. I put it (proto-bip177) in our bitcoin wallet app, promoted the idea where I could. It worked great, but only our users knew.

And then AI became good enough to use for some things. AI has been a HUGE unlock for me and my learning and creating style. Early this year, I told my AI, filled with context about the upcoming BIP3 standard, and examples of related BIPs, to make a BIP for me that properly expressed all of the nuances of my idea on how to handle removal of decimals in a UX.

It looked pretty good, but AI wasn't as good as it is today, and the formatting was total slop. Thankfully, most of the BIP reviewers are actually amazing people, and I was able to contact them directly and ask for help, because I'm not an actual developer (yet). After some private help, it was good enough for the mailing list, and a real draft. 

BIP 177 is a very simple BIP compared to most, and I'd probably make it better if I started today, but ... it exists! It might be the first/only (?) vibe-BIP, and, as of last week, due to Cashapp and Square support, it's possible that BIP 177 is now in more people's hands than not. 

Today, I now have several private drafts of BIPs I am working on with AI, I am trying to impose less slop on my peers as I work in private. These newer BIPs are increasingly technical, and I have also started vibe-coding implementations to test them, and I continue growing into an engineer. 

Now the BIP repo is my favorite part of Bitcoin and interacting with Bitcoin Core. I feel sincere gratitude to three BIP reviewers specifically for humoring my sincere, yet not matured, effort and desire to improve Bitcoin without changing consensus code.

My vision for the BIP repo and reviewers, and AI, is much different than yours. It is part of the story that brought me closer to Bitcoin development, and deep respect to my superiors for tolerating me while I was/am fledgling. 

Please don't add more weird subjective, exclusive barriers just because AI is warping reality. Deal with it, and please, please, continue making an effort to not only guard the BIP repo, but ensure it remains a fertile ground where Bitcoin Core maintains an attitude of being great stewards to the people, not only the specs. 

After all, we will need people to replace you some day, and those people need role models too.

~John Carvalho

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com.

[Bitcoin Mechanic]

I think it makes sense to request that submissions should state if - and to what degree - AI has been used. It's reasonable to expect fewer eyeballs on AI generated submissions as they're so easily generated and their potential for wasting reviewer time is high.

If people are submitting AI generated code and lying about it than that obviously undermines what it is they're proposing so they're naturally disincentivized to do so, thus the honour system should be relatively effective.

I think most people have begun using it for making outlines and tweaking from there. The time saved is too significant for many to resist, and declaring that it was used for an initial outline shouldn't be too dissuasive for any reviewers.

The deeper discussion around legal implications and generally about AI code quality is not resolvable here, it's a massive topic with deep philosophical implications that go way outside the scope of BIP 3 imo.

Thanks

[Oghenovo Usiwoma]

> I think it makes sense to request that submissions should state if - and to what degree - AI has been used. It's reasonable to expect fewer eyeballs on AI generated submissions as they're so easily generated and their potential for wasting reviewer time is high.

In my humble opinion, I believe that humans will continue to use the easiest method available to them to achieve their goals. If we agree that humans will do this, then there will be a lot of AI-assited content. If I did write an AI-assited BIP draft, why would I add this "AI-label" to my BIP when I know that it will cause reviewers to ignore it?

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com.

[Mat Balez]

More and more of writing by all humans, including BIP proposers, will inevitably involve AI in some more or less significant way. I don't expect people to reliably express the degree to which AI was used to inform the thinking behind the BIP, or the writing itself. I'm not aware of any common standard we would use to express those things. Adversarially, we have to assume people won't do it if it's not in their interests. 

Rather, I think the expectation should be that BIP proposers are entirely responsible for submitting high quality BIPs and they take ownership for what they are submitting (submitting garbage burns your rep, always has and always will). BIP reviewers should simply assume for all BIPs that AI was likely used significantly to create them, and judge BIPs only on the merit of the ideas and content. 

Because of the advent of LLMs (and their inevitable continued improvement) this will almost certainly result in an increased number of BIPs being advanced, many of low (slop-filled) quality but also, hopefully, more high quality ones as well—proposals that might not otherwise have seen the light of day and/or proposals themselves being strengthened with better arguments, ideas and language. 

The solution to such a rise in volume IMO is that BIP reviewers should also equip themselves with LLMs and other AI-powered tools to help filter/triage/assess BIPs to get a handle on the rise in noise level. Yet, just like BIP proposers, the onus should be on BIP reviewers to take ownership for the quality of the decision-making around BIP quality and that it not ever be entirely automated but retain "human in the loop" judgment—at least for the foreseeable future—just made more efficient and effective through the use of AI. 

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com.

[Greg Maxwell]

Because if you don't you'll eventually get figured out and people will ignore all your further submissions--- in fact, that will *already* happen, which is part of why the guidance is useful.  No one is obligated to even read any of these submissions and if indeed there are many low quality AI powered ones in the future (as we've been starting to see now) then many won't be read.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com.