Hi list, hi Tim,
No worries, not yelling :)
The idea was and is to save review time.
"No content may be generated by AI/LLMs" -> please don't waste
the community's time asking for review of LLM-generated BIP drafts, as they represent the most problematic submissions in their ease of slick slop generation and possibility of hallucinations.
"authors must proactively disclose up-front any use of AI/LLMs" -> please say in the PR description if LLMs were used, and how, to help us save time.
"Up-front" means without people needing to ask.
Perhaps the rules are naive in the face of the temptation to use LLMs as a shortcut to save time and proof of work, but... they help editors handle these submissions.
> Until that is done, the BIP editors will still have plenty of reasons to reject low-quality BIPs created by LLMs under the rules laid out in "BIP Editor Responsibilities and Workflow".
Not sure those rules cover this, and would they allow us to use Drahtbot-like automation as an aid?
I don't see a controversy so much as an asymmetry between those who want to use LLMs and those who don't particularly want to review LLMs.
Probably the most interesting change that BIP3 brings is the ability to be a living document that can hopefully evolve.
On Friday, November 28, 2025 at 9:48:44 AM UTC-6 Tim Ruffing wrote:
The change that added the AI rules was merged quite late on Oct 22 (see
https://github.com/bitcoin/bips/pull/2006 ), and there was not a lot of
discussion in that PR. I feel what adds to the controversy is that the
rules are pretty strict: "No content may be generated by AI/LLMs and
authors must proactively disclose up-front any use of AI/LLMs."
I think this rule is low quality: It's not clear to me what it
entails. If no content may be generated by LLMs, why have a rule at
all that forces me to disclose any use of LLMs? What is "any"? As an
author, am I required to disclose that I used a LLM to summarize an
email that a co-author of the BIP sent me? If yes, also if the email
was about the question which restaurant to meet for lunch and discuss
the BIP? Probably the answer is "no", but where's the border? What if I
used an LLM to reject an idea that didn't even appear end up in the
BIP? Do I need to disclose this? The text doesn't give any guidance
here. What does it mean that the disclosure is "up-front"? Do I need to
disclose before I start writing the BIP? And how will the disclosure
look like? If AI was used when writing the reference implementation
for say, a proposed new opcode, will it be impossible to implement that
opcode in Bitcoin because it's not allowed to write a BIP about it?
Moreover, the same commit adds text that requires that a BIP must be
the "original work of its authors". This raises other questions, e.g.,
am I allowed to submit a BIP that proposes an idea originating from
someone else's blog post or research paper? If you ask me, this will be
forbidden under the rules of BIP3.
(I hear Jon, the author of the rule, yelling at me "no, that's not what
I meant!". But I claim it's a plausible interpretation of the text in
BIP3.)
My meta-point is that this commit was a rather large change that got
merged into the BIP3 pretty late in the process without getting a lot
of attention. Many (Concept) ACK mentioned in the activation PR
( https://github.com/bitcoin/bips/pull/1820 ) predate that change.
In the interest of not letting the controversy around AI holding the
activation BIP3 up, I suggest reverting that commit for now. It will
still be possible to change BIP3 after it has been activated (or the AI
stuff could go the a separate BIP). Until that is done, the BIP editors
will still have plenty of reasons to reject low-quality BIPs created by
LLMs under the rules laid out in "BIP Editor Responsibilities and
Workflow".
Best,
Tim
On Sun, 2025-11-23 at 02:23 +0530, /dev /fd0 wrote:
> BIPs are just documents that can be maintained in any repository.
> Nobody cares whether the document was assigned a number by the
> gatekeepers or if AI was used to improve the grammar, content etc.
>
> /dev/fd0
> floppy disk guy
>
> On Sun, Nov 23, 2025 at 2:08 AM Sjors Provoost <sj...@sprovoost.nl>
> wrote:
> > Why not have a simple rule which states that "low effort
> > contributions, such as fully LLM generated proposals, may be
> > ignored without a full reading".
> >
> > That should give BIP editors permission to use tools to detect and
> > auto-close such content. They need to detect it anyway in order to
> > enforce the proposed rule (of not allowing it).
> >
> > Judging effort is subjective, just like judging quality (an
> > existing criterion), but it avoids the need for editors to read the
> > whole thing.
> >
> > It's also not a big deal if the auto-close tools are slightly
> > overzealous. If an author believes their proposal was unfairly
> > closed they can demonstrate their effort, e.g. link to a conference
> > talk about the topic, have someone vouch that they had
> > conversations about the proposal, etc. All that takes is some
> > effort :-)
> >
> > I don't think copyright should be a concern. If someone sends a
> > takedown notice for a particular BIP, just take it down, and then
> > either start a legal fight or rewrite it in different words. We're
> > not talking about patents here.
> >
> > Greg Maxwell wrote:
> >
> > > 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.
> >
> > This is indeed an issue and also applies to high effort
> > contributions, where it's hopefully limited to a couple of
> > paragraphs. Reviewers should be alert to this. It can often be
> > fixed by asking the author why a paragraph is so verbose.
> > Implementing a BIP in code should also help get rid of any
> > superfluous or incorrect paragraphs. So I would expect that
> > actually important and widely used BIPs become well polished, even
> > if they didn't start out great. Unused BIPs will be lower quality,
> > but nobody cares.
> >
> > - Sjors
> >
> > > Op 22 nov 2025, om 16:14 heeft Jon Atack <jonny...@gmail.com>
> > > het volgende geschreven:
> > >
> > > The fundamental problem at this time is that prospective authors
> > > want to use LLMs to create content, but it puts maintainers who
> > > handle the submissions and the few experienced reviewers
> > > available to review the submissions at an asymmetric
> > > disadvantage... until or unless AI can analyze and auto-close
> > > those submissions relatively reliably and fairly. Even with AI
> > > tooling to help, who wants to spend their time reviewing LLM
> > > content or trying to detect confident AI hallucinations?
> > >
> > > Therefore, human heuristics like social capital, proof of work,
> > > and personal referrals/recommendations to review are therefore
> > > likely to become even more important. Maybe this should this be
> > > expressed in BIP 3 to set expectations.
> > >
> > > We have seen a wave of BIP draft PRs opened by new GitHub
> > > accounts with no history or proof of work and often appearing to
> > > be LLM-generated. It may be helpful to clarify for now in BIP 3
> > > that such submissions are likely to be closed outright. The
> > > alternative of letting the repository have many open-yet-ignored
> > > PRs probably isn't a desirable option.
> > >
> > > On Friday, November 21, 2025 at 5:25:48 PM UTC-6 Greg Maxwell
> > > wrote:
> > > 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.
> > >
> > >
> > >
> > > On Thu, Nov 20, 2025 at 9:47 AM Oghenovo Usiwoma
> > > <eun...@gmail.com> wrote:
> > > > 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?
> > >
> > > On Thu, Nov 20, 2025 at 3:18 AM Bitcoin Mechanic
> > > <bitcoin...@ocean.xyz> wrote:
> > > 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
> > >
> > > On Wednesday, November 19, 2025 at 2:40:55 PM UTC-8 Bitcoin Error
> > > Log wrote:
> > > 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
> > >
> > >
> > > On Wed, Nov 19, 2025 at 1:18 AM Greg Maxwell <gmax...@gmail.com>
> > > wrote:
> > > 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.
> > >
> > >
> > >
> > > On Wed, Nov 19, 2025 at 12:06 AM David A. Harding
> > > <da...@dtrt.org> wrote:
> > > 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
> > >
> > > --
> > > 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
> > > .
> > >
> > > --
> > > 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/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com
> > > .
> > >
> > > --
> > > 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/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com
> > > .
> > >
> > > --
> > > 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/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com
> > > .
> > >
> > > --
> > > 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/27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn%40googlegroups.com
> > > .
> >
--
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/9b8c8573-cafb-447e-9923-b9a3b9e10950n%40googlegroups.com.