From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 28 Nov 2025 13:10:58 -0800 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vP5k0-0008QH-6R for bitcoindev@gnusha.org; Fri, 28 Nov 2025 13:10:58 -0800 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-65742d1c7f9sf1938156eaf.3 for ; Fri, 28 Nov 2025 13:10:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764364250; cv=pass; d=google.com; s=arc-20240605; b=S8bfhMF/pYxfvthJxJkb3Xs3xOUrmm4HMdxkfuci+OaFyC1TiFCozApvGStD2PLUm7 7w2QE5WjfEhoh9kGo/z6oM0pApv2TsK+IGQ+fzGxU05Qd5ctbqQ1E/UOBoFw6cFKZRMh ktx37IzIP96dU+sdZ62KOtlbgSAprmMR27uOugEHqI+k3+rHLd/ScbAPT+ULtJpR6FW+ b3b4LoDr26VO5oa3tCSaUc8ijqULN2s7Ddb3BfAPGx/NzTpo9BYGmMwew2XL82g8btQ4 y9UABIk21NO0nEsMqaMOl3uyNCRZ6WKXKOjK6OMDj3Ayr8MHmD1iumnIYf+zZAB+WyvU JdEA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:sender :dkim-signature; bh=JOEPBsT+d1nY9wjKUyjusnVsSKeHm0xy6bNN+dgf2fI=; fh=01RzDdqqenyVFQ/QBU7r5jpg32mGunoXhhwDEZKCLf8=; b=Hr3HsPoAq/jcCtd4dvejbPgsmeS3v0o9tdxBcXygCr5w3s/Pq3XtK6fN7WxSKqfj4U o65qCv8EamciHEEpA7C4YkUOEYh9Sp8WTPqAvhWyDCxZjljoT2YjrxwsSfjz08kdLPf0 2Y0K53Ax3Fb0J3tnNE5nSPFUmpziLCuhwdZ6rG9yjSrB9k7pJ48D+xmUN2cH9ZTBuf+K /Xf1iVayoOw4524PYvYBsmuDtG0ysiiWdsYNOT+lcZrYvFJ8PwMjpT6FY1CHJdnx6v1T n0rSmE1PvZ4Hb4asnALIeBJEdSsFyS5ALVABP6u6AvuZy2y1LbP8seeXGJyavKIOir9s evhw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=FZKLM8rv; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764364250; x=1764969050; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=JOEPBsT+d1nY9wjKUyjusnVsSKeHm0xy6bNN+dgf2fI=; b=WaCuv355gb0GTZFdKxqWH1RaVUCQDQ1h4KWYatpOqXsmupTCoFicSW1R9tsNTsdQhT WseN1VOL5wzwJTNDgn0vBRiovphjfUfw2WAE9kwOOUAgPO22V97ioafvSsiTojqAZl0U j2opDWyvWwJ4GrqWRvbORrcjOIE9flzDQT2zzOFng4mW893S5ipaMvBhyKm0pyHzdAuG ApVVPHgaQszxRBKLymFaiC60+cf9h9T+hzf05px6wc9u6hFpv5GsUqL6dhhMr9UCgC5g ozJOuYwuLJeWhvmaxIWpNN2xETd9wa+2ytw8wYOU03UV03sDzKTOkm7ZBXHAImPmnVHR i1MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764364250; x=1764969050; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=JOEPBsT+d1nY9wjKUyjusnVsSKeHm0xy6bNN+dgf2fI=; b=ZiCV0eS1L+Oe+eQFZhxsZQe3Eyh0QNPIsn5RBY+ImCLFL1z27NgGaZJKFpuBXEcIHK nLdgk6EJXu+BaEz0Hs+DPfh++achRUVbh2dcLtqpZ0xtyMS0DGg+UbQ7FIfvT/CsWiK9 yLeCZMRq1RjgVwcyy0UXGl3865OgfjKWAKsHwlHiPvDKpmb1xSr1YHXDc4M8uVF0tz5Y UiWjfzOrWH1GMZAdbv4eoRvs/5OQo4KIktoyuxbWuPSkp/GXDJnbjVzkEytsOUP0Hi+5 V+1LjwspYrtmGO9rn24/QNLYL8ziQaFJ2lpNqHIviWQL42btAEZ0x22vDjMrrNrRjYF+ h26w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWXzJJz/p++ol6NOZZuBoMkyPxSiSrEEwYJrO5vHaNHuk4h6AW96bYe02s5Z6TxL1g4PHsiVfqAXgZw@gnusha.org X-Gm-Message-State: AOJu0Yy1pCQKjEzh24/Qtt8S/PzlqEuGe4DBkF9jFHF6ASrybDdGVvLS wxb969y1i5d/VBBV+fpXgPPX2uKO5sSz1udVQCuFdV02QXp1WwE03w1U X-Google-Smtp-Source: AGHT+IELl97hYPzb9zm8hFO6o6oIq8xH1weFAbrdBeC+8YbtXuAgLCCJH3IAUhLLnc9yaz9Q98zdOw== X-Received: by 2002:a05:6870:ac1f:b0:3ec:3e47:8251 with SMTP id 586e51a60fabf-3ed1fd5012emr8544433fac.10.1764364249555; Fri, 28 Nov 2025 13:10:49 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZGcO01dI2KmUSoi/g3oVUHqWymckInMgCnIFXrPwYJNQ==" Received: by 2002:a05:6871:81d9:10b0:331:5ba5:afd3 with SMTP id 586e51a60fabf-3f0d285af77ls1101859fac.1.-pod-prod-07-us; Fri, 28 Nov 2025 13:10:44 -0800 (PST) X-Received: by 2002:a05:6808:6b8e:b0:450:7f09:69a9 with SMTP id 5614622812f47-4514e7fcea1mr6826217b6e.49.1764364244796; Fri, 28 Nov 2025 13:10:44 -0800 (PST) Received: by 2002:a05:6504:6195:20b0:2d1:a602:e60f with SMTP id a1c4a302cd1d6-2d36a3d1a55msc7a; Fri, 28 Nov 2025 11:21:57 -0800 (PST) X-Received: by 2002:a05:651c:4382:20b0:37b:a6a9:bacb with SMTP id 38308e7fff4ca-37cd91b7b1amr64170181fa.14.1764357715349; Fri, 28 Nov 2025 11:21:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764357715; cv=none; d=google.com; s=arc-20240605; b=c5nbrwr1yImUMXy2jAyVxw5iMy10e/E6jYclgQJ1BRVy6efclTeb8F9fO1PU6ZvvMe vrFWLbcKV13bMjyUVWWWqa8qV8PDMDqudrrYMa0ArV3QJ28ruCtqwoIZS6AkrcJJRdGe r09MUM3A2IRSrhZvI8R0ZvZIUvGTdPTphs5FT6O9YDWSM3dTlBZ2+CMqaDC/pf14rKtZ CcWo+dhMLX7f596uNS6Be/Y22hXDinVfaOg5QgcBQzJ7zJ7xAC9RGx9NrXy4NC4N19A/ bcEztewl8wvo0ojtQsOyZEe66Qb4vgMlYBweAz+F1ng3BnnEOhSze0tUvdEIWZAVGBFS pzpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=vHfmGPDLiclBf2nME+GcQJHd/ta7GGcPRkHUjmBmyOI=; fh=XY3rNXMFTzLVyGCn5pysOVkgK2wyzTQHivvVyAfqIG4=; b=FCTy235/Aaj+uyWWP6pl1QfGO6Pbm/oLfFUm8BvumLa0hhGEe35uQo6bd6WgySJqZU ggSA2CP+W7dmCoAwRCsJnVDmv7sHImpVOMoZA3T3RXfNqRE0E9x4uxrImuF2pue4EiKs aIPiU1dxEstJ7Mw3A+A1M5+IFwMqoHJvbIFjzu3jezvZNOxki7daoIitmKE+RVB5vGGd FZThfTC3EX/pbMp2Kg33sCMAAs0qiP3JNVpk94Eh9Q1AvodaAFkw6Rl37bo27zxI23ja 1okUPHN1RfUAl4RIWTcehl20KJJ4SEncV+Yo/WCQZi3jFYC3F4T0alLgk6NTuoEzwH1j Y8Ng==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=FZKLM8rv; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-4320.protonmail.ch (mail-4320.protonmail.ch. [185.70.43.20]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-37d236ad495si595561fa.1.2025.11.28.11.21.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Nov 2025 11:21:55 -0800 (PST) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) client-ip=185.70.43.20; Date: Fri, 28 Nov 2025 19:21:47 +0000 To: Jon Atack From: Pieter Wuille Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Motion to Activate BIP 3 Message-ID: In-Reply-To: <9b8c8573-cafb-447e-9923-b9a3b9e10950n@googlegroups.com> References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> <012c719c-0f56-474d-8851-a2db3a0b422cn@googlegroups.com> <27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn@googlegroups.com> <0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42@sprovoost.nl> <9b8c8573-cafb-447e-9923-b9a3b9e10950n@googlegroups.com> Feedback-ID: 19463299:user:proton X-Pm-Message-ID: 9c662effedf4759a38dc00f2bd0e3ad040c0786b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_sibL6UNnzc2ls7lrDPDwlqFPbkhwafpM8f7GESuCkDw" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=FZKLM8rv; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net 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.2 (/) --b1=_sibL6UNnzc2ls7lrDPDwlqFPbkhwafpM8f7GESuCkDw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I largely agree with Tim: let's revert the AI rules for BIP 3 now, and get = it activated. I believe it's a significant improvement over the current sta= te of affairs, and I think the question of LLM material is relative minor p= oint compared to the other changes BIP 3 brings, of which our understanding= may evolve quickly. The precise formulation for dealing with this can be i= terated on later. I do understand the motivation to want means of avoiding the asymmetry of e= ditors to spend their time reading through AI slop. But I don't think outla= wing LLMs is the solution: if interpreted and enforced strictly, it will cu= t both ways. But more likely, it will turn out to be unenforceable and moot= . If anything, I'd rather go with specifying expectations rather than rules= : "Editors and other reviewers should not feel compelled to read through th= e full text of low-quality material, including clearly LLM-generated text." -- Pieter On Friday, November 28th, 2025 at 11:57 AM, Jon Atack wrote: > 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 commun= ity's time asking for review of LLM-generated BIP drafts, as they represent= the most problematic submissions in their ease of slick slop generation an= d 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 E= ditor 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 b= e a living document that can hopefully evolve. > > On Friday, November 28, 2025 at 9:48:44=E2=80=AFAM UTC-6 Tim Ruffing wrot= e: > >> 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=E2=80=AFAM Sjors Provoost >>> 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 >>> > > 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=E2=80=AFPM UTC-6 Greg Maxwe= ll >>> > > 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=E2=80=AFAM Oghenovo Usiwoma >>> > > 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=E2=80=AFAM Bitcoin Mechanic >>> > > 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=E2=80=AFPM 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=E2=80=AFAM Greg Maxwell >>> > > 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=E2=80=AFAM David A. Harding >>> > > 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 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/3a66dbbe9a9c46566c8a9a= 16ccb1cc91%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-885= 1-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-z= Uj-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-96b= 8-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/bitcoinde= v/9b8c8573-cafb-447e-9923-b9a3b9e10950n%40googlegroups.com. --=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/= K4ckYujc4cGTRKkpUpEH5z5qlczjySkq7GeCc_Q5A7fsTkHdme_oA8gmeC2HOaho_Z1MOAEw38d= TEvPepdm9emGF-l2-ct0AmK-cAEEoeMU%3D%40wuille.net. --b1=_sibL6UNnzc2ls7lrDPDwlqFPbkhwafpM8f7GESuCkDw Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I largely = agree with Tim: let's revert the AI rules for BIP 3 now, and get it activat= ed. I believe it's a significant improvement over the current state of affa= irs, and I think the question of LLM material is relative minor point compa= red to the other changes BIP 3 brings, of which our understanding may evolv= e quickly. The precise formulation for dealing with this can be iterated on= later.
I do understand the motivation to want means of avoiding the asymmetry of = editors to spend their time reading through AI slop. But I don't think outl= awing LLMs is the solution: if interpreted and enforced strictly, it will c= ut both ways. But more likely, it will turn out to be unenforceable and moo= t. If anything, I'd rather go with specifying expectations rather than rule= s: "Editors and other reviewers should not feel compelled to read through t= he full text of low-quality material, including clearly LLM-generated text.= "
=20
=20
=20

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">-- 
Pieter

On Friday, November 28th, 2025 at 11:57 A= M, Jon Atack <jonnyatack@gmail.com> wrote:
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" -&= gt; 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 gen= eration 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.<= /div>

Perhaps the rules are naive in the face of the tem= ptation to use LLMs as a shortcut to save time and proof of work, but... th= ey help editors handle these submissions.

> Unt= il that is done, the BIP editors will still have plenty of reasons to rejec= t 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 th= ey allow us to use Drahtbot-like automation as an aid?

=
I don't see a controversy so much as an asymmetry between those who wa= nt to use LLMs and those who don't particularly want to review LLMs.
<= div>
Probably the most interesting change that BIP3 brings is the abilit= y to be a living document that can hopefully evolve.


On Friday, November 28, 2025 at 9:48:44= =E2=80=AFAM 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."=20

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/pul= l/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=20
>
> On Sun, Nov 23, 2025 at 2:08=E2=80=AFAM 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 detec= t and
> > auto-close such content. They need to detect it anyway in ord= er 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 re= ad 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 unfairl= y
> > closed they can demonstrate their effort, e.g. link to a conf= erence
> > 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 curr= ent LLM
> > > tools that users who lack the skills to have authored th= e work
> > > without an LLM are generally unable to recognize when th= e LLM is
> > > full of crap (and even sometimes when they should know b= etter),
> > > so unfortunately they're only benign to use in the hands= of those
> > > whose need is the least.=20
> >
> > 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 b= e
> > 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 qua= lity,
> > but nobody cares.
> >
> > - Sjors
> >
> > > Op 22 nov 2025, om 16:14 heeft Jon Atack <jonn= y...@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 maintain= ers 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 w= ith 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 o= f work,
> > > and personal referrals/recommendations to review are the= refore
> > > 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 GitHu= b
> > > accounts with no history or proof of work and often appe= aring to
> > > be LLM-generated. It may be helpful to clarify for now i= n 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=E2=80=AFPM UTC-6= Greg Maxwell
> > > wrote:
> > > Because if you don't you'll eventually get figured out a= nd people
> > > will ignore all your further submissions--- in fact, tha= t will
> > > *already* happen, which is part of why the guidance is u= seful.=20
> > > No one is obligated to even read any of these submission= s 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 r= ead.
> > >
> > >
> > >
> > > On Thu, Nov 20, 2025 at 9:47=E2=80=AFAM 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 re= asonable to
> > > > expect fewer eyeballs on AI generated submissions a= s they're so
> > > > easily generated and their potential for wasting re= viewer time
> > > > is high.
> > >
> > > In my humble opinion, I believe that humans will continu= e to use
> > > the easiest method available to them to achieve their go= als. 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 dra= ft, why
> > > would I add this "AI-label" to my BIP when I know that i= t 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 shoul= d state
> > > if - and to what degree - AI has been used. It's reasona= ble to
> > > expect fewer eyeballs on AI generated submissions as the= y're so
> > > easily generated and their potential for wasting reviewe= r time is
> > > high.
> > >
> > > If people are submitting AI generated code and lying abo= ut it
> > > than that obviously undermines what it is they're propos= ing so
> > > they're naturally disincentivized to do so, thus the hon= our
> > > system should be relatively effective.
> > >
> > > I think most people have begun using it for making outli= nes and
> > > tweaking from there. The time saved is too significant f= or 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 gene= rally
> > > about AI code quality is not resolvable here, it's a mas= sive
> > > topic with deep philosophical implications that go way o= utside
> > > the scope of BIP 3 imo.
> > >
> > > Thanks
> > >
> > > On Wednesday, November 19, 2025 at 2:40:55=E2=80=AFPM UT= C-8 Bitcoin Error
> > > Log wrote:
> > > A few years ago, I had this idea that bitcoin divisibili= ty 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. A= I has
> > > been a HUGE unlock for me and my learning and creating s= tyle.
> > > 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 to= day, and
> > > the formatting was total slop. Thankfully, most of the B= IP
> > > reviewers are actually amazing people, and I was able to= contact
> > > them directly and ask for help, because I'm not an actua= l
> > > developer (yet). After some private help, it was good en= ough for
> > > the mailing list, and a real draft.
> > >
> > > BIP 177 is a very simple BIP compared to most, and I'd p= robably
> > > make it better if I started today, but ... it exists! It= might be
> > > the first/only (?) vibe-BIP, and, as of last week, due t= o 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 wo= rking on
> > > with AI, I am trying to impose less slop on my peers as = I work in
> > > private. These newer BIPs are increasingly technical, an= d I have
> > > also started vibe-coding implementations to test them, a= nd I
> > > continue growing into an engineer.
> > >
> > > Now the BIP repo is my favorite part of Bitcoin and inte= racting
> > > 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 co= nsensus
> > > code.
> > >
> > > My vision for the BIP repo and reviewers, and AI, is muc= h
> > > different than yours. It is part of the story that broug= ht me
> > > closer to Bitcoin development, and deep respect to my su= periors
> > > for tolerating me while I was/am fledgling.
> > >
> > > Please don't add more weird subjective, exclusive barrie= rs 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 ma= intains
> > > an attitude of being great stewards to the people, not o= nly 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=E2=80=AFAM Greg Maxwell <= ;gmax...@gmail.com>
> > > wrote:
> > > No doubt *you* are able to make good documents with or w= ithout
> > > the aid of AI.
> > >
> > > With outright AI 'authorship' you immediately run into p= otential
> > > copyright issues-- which I think is the origin of the "g= enerated
> > > by" prohibition, otherwise I think disclosure would be
> > > sufficient.
> > >
> > > Taking a step back: is Bitcoin's welfare maximized by pe= rmitting
> > > LLM glurge submissions in standards documents? In some c= ases it's
> > > benign, I readily agree, in others its harmful. But the= number
> > > of good submissions that could be made would hardly be i= ncreased
> > > by LLMs (being limited by expert proposers with good ide= as) but
> > > the number of potential poor submissions is increased
> > > astronomically. So I think it's pretty clearly a net ha= rm 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?") wit= hout
> > > resorting to using it to author.
> > >
> > > There is a particularly clear pattern at least with curr= ent LLM
> > > tools that users who lack the skills to have authored th= e work
> > > without an LLM are generally unable to recognize when th= e LLM is
> > > full of crap (and even sometimes when they should know b= etter),
> > > so unfortunately they're only 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 powe= red
> > > proposers to be absolutely the worst to deal with. Becau= se
> > > they're not submitting their own words and ideas, they'r= e unable
> > > to change their thinking in response or explain sufficie= ntly to
> > > change yours--- the interactions often degrade to them j= ust copy
> > > and pasting their chatbot back to you. Because it's che= ap to
> > > generate more text they also tend to flood you out with = documents
> > > several times longer than any human author would have bo= thered
> > > with.
> > >
> > > I think LLMs have generally created something of an exis= tential
> > > threat to most open collaborations: Now its so easy to g= et
> > > flooded out by subtly worthless material. Many projects= ,
> > > including, Bitcoin have long struggled with review capac= ity being
> > > limited and a far amount of time waste by thoughtless (o= r 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 cou= ld have
> > > been in the past, not even know they are doing it, and c= an make a
> > > dozen proposals before lunch without even breaking a swe= at.
> > >
> > >
> > >
> > > On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Hardin= g
> > > <da...@dtrt.org> 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 begi= n 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 t= o help me
> > > refine
> > > the document until I was satisfied.
> > >
> > > I would, of course, review every word of the draft BIP b= efore
> > > 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 valuabl= e for
> > > people who
> > > are less comfortable with writing technical English-lang= uage
> > > documents
> > > than I am. For example, non-native literates, people wi= th
> > > 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 it= s
> > > motivation,
> > > although it references a previous discussion[1] where a = low-
> > > quality BIP
> > > PR was opened using mostly AI-generated content. I'm gu= essing
> > > 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 BI= P 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 see= ms
> > > redundant and
> > > penalizes people who either need those tools or who can = use them
> > > effectively.
> > >
> > > I advocate for reverting the first hunk of BIPs reposito= ry PR
> > > 2006.
> > >
> > > -Dave
> > >
> > > [1] https://github.com= /bitcoin/bips/pull/2005
> > > [2] "After fleshing out the proposal further and ensurin= g that it
> > > is of
> > > **high quality** and properly formatted, the authors sho= uld 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<= /a>.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bitcoindev/3a66d= bbe9a9c46566c8a9a16ccb1cc91%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<= /a>.
> > > To view this discussion visit
> > > https://groups.google.c= om/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<= /a>.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bit= coindev/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<= /a>.
> > > To view this discussion visit
> > > https://groups.goog= le.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6T= Cg%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<= /a>.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bit= coindev/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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/9b8c8573-cafb-447e-9923-b9a3b9e10950n%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/K4ckY= ujc4cGTRKkpUpEH5z5qlczjySkq7GeCc_Q5A7fsTkHdme_oA8gmeC2HOaho_Z1MOAEw38dTEvPe= pdm9emGF-l2-ct0AmK-cAEEoeMU%3D%40wuille.net.
--b1=_sibL6UNnzc2ls7lrDPDwlqFPbkhwafpM8f7GESuCkDw--