From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 22 Nov 2025 07:17:42 -0800 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vMpMq-0007jA-GM for bitcoindev@gnusha.org; Sat, 22 Nov 2025 07:17:42 -0800 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-65742f8c565sf4908076eaf.1 for ; Sat, 22 Nov 2025 07:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763824654; x=1764429454; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=p2TTDHXTEVglkZmnEVeMK9s5j+CYFtNOfCelto5tZow=; b=XZF+Gzp3bggNswzQPrwNpd3mHiq6SQ5LFf0dJ82MSgVlvzzDXWp8gAaEAkvxiiLzzK pkjNLpUogplKF3d19xS/NEDxc+Pm0QYLlUlUse6sWtM02g4dyg++tWJRNTbEO0gUNZES 48PDP3+a2d0FDb+Gu0fcoo6afoo06XwJmT8yRk6dYfFhJbmGwnI+A6ry2jg6nRB23lHq c6qBiSOJGZzd+od607g+4Zoj8+adETXmI+Mb7DBG8IDRSEULi8QUErzvi7u1iJrNdXw/ Jbon5Jgv9Xxsm3mSoviGmktGrn3T94WKp6gTBcyUopMVHmTg66lIaat+x+fYW8lNaM0L Ud+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763824654; x=1764429454; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=p2TTDHXTEVglkZmnEVeMK9s5j+CYFtNOfCelto5tZow=; b=XvknLnx3+tuMXO2FbGQtItMlaircnsbVLwR86fRaMLyVLkIkBJlINrsv1iDTQEPxp0 9HU07R3/8a5sM5y1bceY3fcZI82PtHhZsZE2gB3C03y5N+Q1RZkCfGewCDmjXaroA2cQ f4WuXKKAcGqPdZ5rBe63Nw+LQTbt0wkr92XI6h6y/RjHlW+nKIMyN4SkKj2dUuhDtKgS Gau6PZ2rZUaKAs9CqwdqMo5tpjYtrtnNZ5BIzR22Swz6+rKkBvY7i9sICg+Q3uWoJssJ R1agBdhLMMRnS6wo4oYzco1KUAp0jXZGiDNsXQpi+FMqCLKifgt7xFV1GxXIChG/7aYw jXkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763824654; x=1764429454; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=p2TTDHXTEVglkZmnEVeMK9s5j+CYFtNOfCelto5tZow=; b=MokSkIcZAoxZ9QlWeNsq2mfzQurq189WjN3/PQuofqkHQyQqp4C7rYyqTyGossFW4p gZWK09lKbmDeQPU5Dxm1e1fPVFoR9ZDCd/onJUsEkWvGBPCXDMDJgiQODHHydNWYF3kI TeMsWfsyIXZ3BkWmc2yZHc3UQyz1FwS3Gf8IBs1JyXrk1rzbvqLr8cWPo5CZfk+wij2w nZHjKF5xkRn50njc7z10NNv1gzUmkjI2bLOqfj96Q1RXQ5RmCRIYkcCSNr5DhEDw0b3B LMzdyi+HhGLjIOIZNo3Xv9LoOBoVMhdEp5SoTydZ/mKoMvSQLPpbb0RKzmQCXB6JpUf0 DM3Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVmt1l7NdtIiLvQc1Aa0Fk3cS9e+ajBpqPkXGr1RWAWIcFohfcqZ9Vy55b/aNWH0yIwIKJsH9rmT7lt@gnusha.org X-Gm-Message-State: AOJu0Yz51wz2PVOEcc7+pPSFLNv0PYYaVDdwpPXe7Efx10IxiY/mu04V dh3AwwQn76pefHYjV8kBWWEMlmZr8yQisMD8g9aWEExibwn0EkKDPNdw X-Google-Smtp-Source: AGHT+IFG7QKlgiJAUxeDz+2PPqDAhU4+SIKcCEkS27N2L7hckIct1kBCzgg2gGDjgEGZM7SnI25gNA== X-Received: by 2002:a05:6870:6109:b0:3ec:4435:7c2c with SMTP id 586e51a60fabf-3ecbe52a465mr2738705fac.27.1763824653831; Sat, 22 Nov 2025 07:17:33 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZFn31+z8bbwepOSHvDhGEPF/HEF60VwAu+Az0fmoa8ng==" Received: by 2002:a05:6870:414f:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3ec9b05b09els1976542fac.0.-pod-prod-09-us; Sat, 22 Nov 2025 07:17:29 -0800 (PST) X-Received: by 2002:a05:6808:6788:b0:450:275c:87d8 with SMTP id 5614622812f47-45112ce82dfmr2528550b6e.32.1763824649484; Sat, 22 Nov 2025 07:17:29 -0800 (PST) Received: by 2002:a05:690c:831:b0:78a:986f:9439 with SMTP id 00721157ae682-78a986f974dms7b3; Sat, 22 Nov 2025 07:14:57 -0800 (PST) X-Received: by 2002:a05:690e:1403:b0:641:f5bc:68ca with SMTP id 956f58d0204a3-64302ac9faemr4027707d50.71.1763824496453; Sat, 22 Nov 2025 07:14:56 -0800 (PST) Date: Sat, 22 Nov 2025 07:14:56 -0800 (PST) From: Jon Atack To: Bitcoin Development Mailing List Message-Id: <27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn@googlegroups.com> In-Reply-To: References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> <3a66dbbe9a9c46566c8a9a16ccb1cc91@dtrt.org> <012c719c-0f56-474d-8851-a2db3a0b422cn@googlegroups.com> Subject: Re: [bitcoindev] Motion to Activate BIP 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_160152_1951909057.1763824496083" X-Original-Sender: jonnyatack@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_160152_1951909057.1763824496083 Content-Type: multipart/alternative; boundary="----=_Part_160153_1722833861.1763824496083" ------=_Part_160153_1722833861.1763824496083 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The fundamental problem at this time is that prospective authors want to=20 use LLMs to create content, but it puts maintainers who handle the=20 submissions and the few experienced reviewers available to review the=20 submissions at an asymmetric disadvantage... until or unless AI can analyze= =20 and auto-close those submissions relatively reliably and fairly. Even with= =20 AI tooling to help, who wants to spend their time reviewing LLM content or= =20 trying to detect confident AI hallucinations? Therefore, human heuristics like social capital, proof of work, and=20 personal referrals/recommendations to review are therefore likely to become= =20 even more important. Maybe this should this be expressed in BIP 3 to set=20 expectations. We have seen a wave of BIP draft PRs opened by new GitHub accounts with no= =20 history or proof of work and often appearing to be LLM-generated. It may be= =20 helpful to clarify for now in BIP 3 that such submissions are likely to be= =20 closed outright. The alternative of letting the repository have many=20 open-yet-ignored PRs probably isn't a desirable option. On Friday, November 21, 2025 at 5:25:48=E2=80=AFPM UTC-6 Greg Maxwell wrote= : > Because if you don't you'll eventually get figured out and people will=20 > ignore all your further submissions--- in fact, that will *already* happe= n,=20 > which is part of why the guidance is useful. No one is obligated to even= =20 > read any of these submissions and if indeed there are many low quality AI= =20 > powered ones in the future (as we've been starting to see now) then many= =20 > won't be read. > > > > On Thu, Nov 20, 2025 at 9:47=E2=80=AFAM Oghenovo Usiwoma wrote: > >> > I think it makes sense to request that submissions should state if -= =20 >> and to what degree - AI has been used. It's reasonable to expect fewer= =20 >> eyeballs on AI generated submissions as they're so easily generated and= =20 >> their potential for wasting reviewer time is high. >> >> In my humble opinion, I believe that humans will continue to use the=20 >> easiest method available to them to achieve their goals. If we agree tha= t=20 >> humans will do this, then there will be a lot of AI-assited content. If = I=20 >> did write an AI-assited BIP draft, why would I add this "AI-label" to my= =20 >> BIP when I know that it will cause reviewers to ignore it? >> >> On Thu, Nov 20, 2025 at 3:18=E2=80=AFAM Bitcoin Mechanic =20 >> wrote: >> >>> I think it makes sense to request that submissions should state if - an= d=20 >>> to what degree - AI has been used. It's reasonable to expect fewer eyeb= alls=20 >>> on AI generated submissions as they're so easily generated and their=20 >>> potential for wasting reviewer time is high. >>> >>> If people are submitting AI generated code and lying about it than that= =20 >>> obviously undermines what it is they're proposing so they're naturally= =20 >>> disincentivized to do so, thus the honour system should be relatively= =20 >>> effective. >>> >>> I think most people have begun using it for making outlines and tweakin= g=20 >>> from there. The time saved is too significant for many to resist, and= =20 >>> declaring that it was used for an initial outline shouldn't be too=20 >>> dissuasive for any reviewers. >>> >>> The deeper discussion around legal implications and generally about AI= =20 >>> code quality is not resolvable here, it's a massive topic with deep=20 >>> philosophical implications that go way outside the scope of BIP 3 imo. >>> >>> Thanks >>> >>> On Wednesday, November 19, 2025 at 2:40:55=E2=80=AFPM UTC-8 Bitcoin Err= or Log=20 >>> wrote: >>> >>>> A few years ago, I had this idea that bitcoin divisibility needed to b= e=20 >>>> fixed as a misconception. I put it (proto-bip177) in our bitcoin walle= t=20 >>>> app, promoted the idea where I could. It worked great, but only our us= ers=20 >>>> knew. >>>> >>>> And then AI became good enough to use for some things. AI has been a= =20 >>>> HUGE unlock for me and my learning and creating style. Early this year= , I=20 >>>> told my AI, filled with context about the upcoming BIP3 standard, and= =20 >>>> examples of related BIPs, to make a BIP for me that properly expressed= all=20 >>>> 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= =20 >>>> formatting was total slop. Thankfully, most of the BIP reviewers are= =20 >>>> actually amazing people, and I was able to contact them directly and a= sk=20 >>>> for help, because I'm not an actual developer (yet). After some privat= e=20 >>>> help, it was good enough for the mailing list, and a real draft.=20 >>>> >>>> BIP 177 is a very simple BIP compared to most, and I'd probably make i= t=20 >>>> better if I started today, but ... it exists! It might be the first/on= ly=20 >>>> (?) vibe-BIP, and, as of last week, due to Cashapp and Square support,= it's=20 >>>> possible that BIP 177 is now in more people's hands than not.=20 >>>> >>>> Today, I now have several private drafts of BIPs I am working on with= =20 >>>> AI, I am trying to impose less slop on my peers as I work in private. = These=20 >>>> newer BIPs are increasingly technical, and I have also started vibe-co= ding=20 >>>> implementations to test them, and I continue growing into an engineer.= =20 >>>> >>>> Now the BIP repo is my favorite part of Bitcoin and interacting with= =20 >>>> Bitcoin Core. I feel sincere gratitude to three BIP reviewers specific= ally=20 >>>> for humoring my sincere, yet not matured, effort and desire to improve= =20 >>>> Bitcoin without changing consensus code. >>>> >>>> My vision for the BIP repo and reviewers, and AI, is much different=20 >>>> than yours. It is part of the story that brought me closer to Bitcoin= =20 >>>> development, and deep respect to my superiors for tolerating me while = I=20 >>>> was/am fledgling.=20 >>>> >>>> Please don't add more weird subjective, exclusive barriers just becaus= e=20 >>>> AI is warping reality. Deal with it, and please, please, continue maki= ng an=20 >>>> effort to not only guard the BIP repo, but ensure it remains a fertile= =20 >>>> ground where Bitcoin Core maintains an attitude of being great steward= s to=20 >>>> the people, not only the specs.=20 >>>> >>>> After all, we will need people to replace you some day, and those=20 >>>> people need role models too. >>>> >>>> ~John Carvalho >>>> >>>> >>>> On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg Maxwell wrote: >>>> >>>>> No doubt *you* are able to make good documents with or without the ai= d=20 >>>>> of AI. >>>>> >>>>> With outright AI 'authorship' you immediately run into potential=20 >>>>> copyright issues-- which I think is the origin of the "generated by"= =20 >>>>> prohibition, otherwise I think disclosure would be sufficient. >>>>> >>>>> Taking a step back: is Bitcoin's welfare maximized by permitting LLM= =20 >>>>> glurge submissions in standards documents? In some cases it's benign,= I=20 >>>>> readily agree, in others its harmful. But the number of good submiss= ions=20 >>>>> that could be made would hardly be increased by LLMs (being limited b= y=20 >>>>> expert proposers with good ideas) but the number of potential poor=20 >>>>> submissions is increased astronomically. So I think it's pretty clea= rly a=20 >>>>> net harm to have text authored that way. >>>>> >>>>> I've never had an impression that drafting was at all a limiting step= =20 >>>>> in writing BIPs, though even to the extent that it has been at times = it's=20 >>>>> possible to use LLMs in a review capacity to make authorship much eas= ier=20 >>>>> ("What's missing / unclear?") without resorting to using it to author= . >>>>> >>>>> There is a particularly clear pattern at least with current LLM tools= =20 >>>>> that users who lack the skills to have authored the work without an L= LM are=20 >>>>> generally unable to recognize when the LLM is full of crap (and even= =20 >>>>> sometimes when they should know better), so unfortunately they're onl= y=20 >>>>> benign to use in the hands of those whose need is the least. =20 >>>>> >>>>> And as a reviewer outside of Bitcoin I've found LLM powered proposers= =20 >>>>> to be absolutely the worst to deal with. Because they're not submitti= ng=20 >>>>> their own words and ideas, they're unable to change their thinking in= =20 >>>>> response or explain sufficiently to change yours--- the interactions = often=20 >>>>> degrade to them just copy and pasting their chatbot back to you. Bec= ause=20 >>>>> it's cheap to generate more text they also tend to flood you out with= =20 >>>>> documents several times longer than any human author would have bothe= red=20 >>>>> with. >>>>> >>>>> I think LLMs have generally created something of an existential threa= t=20 >>>>> to most open collaborations: Now its so easy to get flooded out by su= btly=20 >>>>> worthless material. Many projects, including, Bitcoin have long stru= ggled=20 >>>>> with review capacity being limited and a far amount of time waste by= =20 >>>>> thoughtless (or even crazy!) submissions, but now it's automated and = even=20 >>>>> the most well meaning person may now make submissions that are as bad= as=20 >>>>> the most deviously constructed malicious submissions could have been = in the=20 >>>>> past, not even know they are doing it, and can make a dozen proposals= =20 >>>>> before lunch without even breaking a sweat. >>>>> >>>>> >>>>> >>>>> On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Harding =20 >>>>> wrote: >>>>> >>>>>> On 2025-11-04 15:10, Murch wrote: >>>>>> > Summary of changes since BIP=E2=80=AF3 was advanced to Proposed: >>>>>> > [...] >>>>>> > - that BIPs submissions may not be generated by AI/LLM=E2=81=B5 >>>>>> > [...] >>>>>> > =E2=81=B5 https://github.com/bitcoin/bips/pull/2006 >>>>>> >>>>>> I strongly disagree with this change. If I were to begin working on= =20 >>>>>> a=20 >>>>>> new BIP today, I would use AI throughout the process. I'd ask it to= =20 >>>>>> help me create a todo list of what should go in the BIP; I'd ask it= =20 >>>>>> to=20 >>>>>> create a draft based on existing BIPs, my todo list, and whatever=20 >>>>>> other=20 >>>>>> work products I had (e.g. prototypes); I'd then ask it to help me=20 >>>>>> refine=20 >>>>>> the document until I was satisfied. >>>>>> >>>>>> I would, of course, review every word of the draft BIP before=20 >>>>>> submitting=20 >>>>>> it for consideration and ensure that it represented the highest=20 >>>>>> quality=20 >>>>>> work I was able to produce---but the ultimate work would be a mix of= =20 >>>>>> AI=20 >>>>>> and human writing and editing. >>>>>> >>>>>> I think considerate use of AI would be even more valuable for people= =20 >>>>>> who=20 >>>>>> are less comfortable with writing technical English-language=20 >>>>>> documents=20 >>>>>> than I am. For example, non-native literates, people with=20 >>>>>> disabilities=20 >>>>>> that make text input difficulty, and those who recognize that they'r= e=20 >>>>>> bad writers. >>>>>> >>>>>> The PR forbidding AI doesn't go into any detail about its motivation= ,=20 >>>>>> although it references a previous discussion[1] where a low-quality= =20 >>>>>> BIP=20 >>>>>> PR was opened using mostly AI-generated content. I'm guessing the= =20 >>>>>> motivation is that AI (by itself) generates low-quality technical=20 >>>>>> content, BIPs should be high-quality technical content, and therefor= e=20 >>>>>> we=20 >>>>>> should ban the use of AI. >>>>>> >>>>>> However, as mentioned in the previous discussion, the BIP process=20 >>>>>> already requires high-quality content.[2] AI-generated content can= =20 >>>>>> be=20 >>>>>> high-quality, especially if its creation and editing was guided by a= =20 >>>>>> knowledgeable human. Banning specific tools like AI seems redundant= =20 >>>>>> and=20 >>>>>> penalizes people who either need those tools or who can use them=20 >>>>>> 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= =20 >>>>>> of=20 >>>>>> **high quality** and properly formatted, the authors should open a= =20 >>>>>> pull=20 >>>>>> request to the BIPs repository." --BIP3, emphasis added >>>>>> >>>>>> --=20 >>>>>> You received this message because you are subscribed to the Google= =20 >>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it,=20 >>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>> To view this discussion visit=20 >>>>>> https://groups.google.com/d/msgid/bitcoindev/3a66dbbe9a9c46566c8a9a1= 6ccb1cc91%40dtrt.org >>>>>> . >>>>>> >>>>> --=20 >>>>> You received this message because you are subscribed to the Google=20 >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3D= XdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com=20 >>>>> >>>>> . >>>>> >>>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2= db3a0b422cn%40googlegroups.com=20 >>> >>> . >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%= 3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com=20 >> >> . >> > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn%40googlegroups.com. ------=_Part_160153_1722833861.1763824496083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The fundamental problem at this time is that prospective authors want = to use LLMs to create content, but it puts=20 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 relia= bly 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, pr= oof of work, and personal=20 referrals/recommendations to review are therefore likely to become even mor= e=20 important. Maybe this should this be expressed in BIP 3 to set=20 expectations.

We have seen a wave of BIP draft P= Rs opened by new GitHub=20 accounts with no history or proof of work and often appearing to be=20 LLM-generated. It may be helpful to clarify for now in BIP 3 that such subm= issions are=20 likely to be closed outright. The alternative of letting the repository hav= e many open-yet-ignored PRs probably isn't a desirable option.

On Friday, November 21, 2025 at 5:25:48=E2=80=AFPM UTC-6 Greg M= axwell wrote:
Because if you don't you'll eventually get f= igured out and people will ignore all your further submissions--- in fact, = that will *already* happen, which is part of why the guidance is useful.=C2= =A0 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 bee= n starting to see now) then many won't be read.



On Thu, Nov 20, 2025 at 9:47= =E2=80=AFAM Oghenovo Usiwoma <eun...@gmail.com> wrote:
=
> I t= hink it makes sense to request that submissions should state if - and to wh= at degree - AI has been used. It's reasonable to expect fewer eyeballs = on AI generated submissions as they're so easily generated and their po= tential for wasting reviewer time is high.

In my humble opinion, I b= elieve that humans will continue to use the easiest method available=C2=A0t= o them to achieve their goals. If we agree that humans will do this, then t= here will be a lot of AI-assited content. If I did write an AI-assited=C2= =A0BIP draft, why would I add this "AI-label" to my BIP when I kn= ow that it will cause reviewers to ignore it?

On Thu, Nov 20, 2025 at 3:= 18=E2=80=AFAM Bitcoin Mechanic <bitcoin...@ocean.xyz> wrote:
I think it makes sense to request that submissions s= hould 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 eas= ily 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 re= latively effective.

I think most people have begun= using it for making outlines and tweaking from there. The time saved is to= o significant for many to resist, and declaring that it was used for an ini= tial outline shouldn't be too dissuasive for any reviewers.
<= br>
The deeper discussion around legal implications and generally= about AI code quality is not resolvable here, it's a massive topic wit= h deep philosophical implications that go way outside the scope of BIP 3 im= o.

Thanks

=
On Wednesday, November 19, 2025 at 2= :40:55=E2=80=AFPM UTC-8 Bitcoin Error Log wrote:
A few years ago, I h= ad this idea that bitcoin divisibility needed to be fixed as a misconceptio= n. I put it (proto-bip177) in our bitcoin wallet app, promoted the idea whe= re I could. It worked great, but only our users knew.

<= div>And then AI became good enough to use for some things. AI has been a HU= GE unlock for me and my learning and creating style. Early this year, I tol= d 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 n= uances of my idea on how to handle removal of decimals in a UX.
<= br>
It looked pretty good, but AI wasn't as good as it is tod= ay, and the formatting was total slop. Thankfully, most of the BIP reviewer= s 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 pri= vate help, it was good enough for the mailing list, and a real draft.=C2=A0=

BIP 177 is a very simple BIP compared to most, an= d 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&#= 39;s hands than not.=C2=A0

Today, I now have sever= al private drafts of BIPs I am working on with AI, I am trying to impose le= ss 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 the= m, and I continue growing into an engineer.=C2=A0

= Now the BIP repo is my favorite part of Bitcoin and interacting with Bitcoi= n Core. I feel sincere gratitude to three BIP reviewers specifically for hu= moring my sincere, yet not matured, effort and desire to improve Bitcoin wi= thout changing consensus code.

My vision for the B= IP 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 t= o my superiors for tolerating me while I was/am fledgling.=C2=A0
=
Please don't add more weird subjective, exclusive barrie= rs just because AI is warping reality. Deal with it, and please, please, co= ntinue making an effort to not only guard the BIP repo, but ensure it remai= ns a fertile ground where Bitcoin Core maintains an attitude of being great= stewards to the people, not only the specs.=C2=A0

After all, we will need people to replace you some day, and those people n= eed role models too.
<= div dir=3D"ltr">

~John Carvalho

On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg Maxwe= ll <gmax...@gmail.com> wrote:
=
No doubt *you* are able to make good documents with= or without the aid of AI.

With outright AI 'a= uthorship' you immediately run into potential=20 copyright issues-- which I think is the origin of the "generated by&qu= ot;=20 prohibition, otherwise I think disclosure would be sufficient.
Taking a step back: is Bitcoin's welfare=C2=A0maximized by= permitting LLM glurge submissions in standards documents? In some cases it= 's benign, I readily agree, in others its harmful.=C2=A0 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 potent= ial poor submissions is increased astronomically.=C2=A0 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 limiti= ng step in writing BIPs, though even to the extent that it has been at time= s it's possible to use LLMs in a review capacity to make authorship muc= h easier ("What's missing / unclear?") without resorting to u= sing it to author.

There is a particularly clear pattern at l= east 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 unfortun= ately they're only benign to use in the hands of those whose need is th= e least.=C2=A0=C2=A0

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, th= ey're unable to change their thinking in response or explain sufficient= ly to change yours--- the interactions often degrade to them just copy and = pasting their chatbot back to you.=C2=A0 Because it's cheap to generate= more text they also tend to flood you out with documents several times lon= ger 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=C2=A0so easy to get flooded out by subtl= y worthless material.=C2=A0 Many projects, including, Bitcoin have long str= uggled with review capacity being limited and a far amount of time waste by= thoughtless (or even crazy!) submissions, but now it's automated and e= ven the most well meaning person may now make submissions that are as bad a= s the most deviously constructed malicious submissions could have been in t= he past, not even know they are doing it, and can make a dozen proposals be= fore lunch without even breaking a sweat.



On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Harding <da...@dtrt.org> wrote:
On 2025-11-04 15:10, Murch wrote:
> Summary of changes since BIP=E2=80=AF3 was advanced to Proposed:
> [...]
> =C2=A0 - that BIPs submissions may not be generated by AI/LLM=E2=81=B5=
> [...]
> =E2=81=B5 https://github.com/bitcoin/bips/pull/2006

I strongly disagree with this change.=C2=A0 If I were to begin working on a=
new BIP today, I would use AI throughout the process.=C2=A0 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 refin= e
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.=C2=A0 For example, non-native literates, people with disabilitie= s
that make text input difficulty, and those who recognize that they're <= br> bad writers.

The PR forbidding AI doesn't go into any detail about its motivation, <= br> although it references a previous discussion[1] where a low-quality BIP PR was opened using mostly AI-generated content.=C2=A0 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]=C2=A0 AI-generated content can be=
high-quality, especially if its creation and editing was guided by a
knowledgeable human.=C2=A0 Banning specific tools like AI seems redundant a= nd
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 o= f
**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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/3a66dbbe9a9c46566c8a9a16ccb1cc91%40dtrt.org.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422= cn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn%40googlegroups.com.
------=_Part_160153_1722833861.1763824496083-- ------=_Part_160152_1951909057.1763824496083--