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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]. > 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 [email protected]. > 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 [email protected]. > 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 [email protected]. > 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 [email protected]. > 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42%40sprovoost.nl.
