From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 28 Nov 2025 08:57:33 -0800 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vP1mk-00053K-I5 for bitcoindev@gnusha.org; Fri, 28 Nov 2025 08:57:32 -0800 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6574f3b6ec1sf2956653eaf.3 for ; Fri, 28 Nov 2025 08:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764349044; x=1764953844; 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=AUfurTKKLimUdPXOseU9Nd6VZWPxN6dMzwlGQT9kajU=; b=tkif6m6XzKDrULscJFPGi/eCfnB6jqUk2RU/o77HjLMzP+T4upIo+/UKkVGqCg7Mej HY3lZ0SosQm7D3UiraiNkiYu37675sQ2txYgQfalpSSKLLw2leK62ZdANDZu6fc0jkJA i13KKMO34jIOE42y7rEUl17gnRwbofAFCwFQRaX5tDodosF5K7fxyUEUZeVySNJYGAVK OFNOwjMfTYcaXmiUzXNupUl+TAJ9eNAOxcJsOSTs8DBSyburJLE/+1KnF0UHgvaJbeA9 kVgv5Il4SvxEFJP0SZB7zOnG9jPHpd6LPJT+yRoL1SNwBrk6a2yJ5b1c/QXk/bJXJyBZ DATQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764349044; x=1764953844; 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=AUfurTKKLimUdPXOseU9Nd6VZWPxN6dMzwlGQT9kajU=; b=id6rvyroXDywxrj8InNn7kgKBPFyEd3wzjaAmz3SC2VXttlV2hxn0dlHZkiNGPox0B zcqgJOAPCxvcq5mYFauzEx7NvUcHZrtOQDb2BzHlpuXYO8rYtnQ/L0eAZAFniH+M/ykT SL4yzRMXxg0ZCbWM0gDCVt0LRHImXBQRkfs4rwN9L7EMTuaqaEPJ8uMxD6VV8wNEn8v3 FgVtKbw1OrFDemBeaAlAyBOSCGi+mw2Bj9udWoarIp366G+rlmRIn7V/QeikzGa812Ng sr2mj5DHybhX73yaXQSjYTW7SbNkDqn2aVVc5nHykYJH+gVlSgW6vglb+kC+t5QxKu0t 2WmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764349044; x=1764953844; 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=AUfurTKKLimUdPXOseU9Nd6VZWPxN6dMzwlGQT9kajU=; b=X1roE5dH1WjVT/mbemc6r6znx66vE6XYfg5cQ3LGkwhoqD2MpF2Gi8cxx53CmzRBGS 1fr3sTPWuSCay8/Sjxrb33PAk2D8K0lzm5/wfMrrNc/gKOiT+xEsdkOkue4xKRlCoo81 FRBkaZM3jOpF0eBeoG6NPhmnD/p26XI6SEP2NCooDCYxyL8E1r45LD4Qw+eKwiivT0tB lrMh7D4yyi854WmmWZlansHOVCCK2fT04BX7F9AZa1+H/cLsfYflOjp5fhYtLh7tjJ7M nSq1ZoJEjSUofuny0G6EzzQ6jV27TPeZpXtb4Q5EGqklPOj5p5LlPib+YPZE6Ah+q70u +J+g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWRCD3xZBerNUD6Sr3t7zDGoQxd6qjjCl4QNnOT46OdynrWTXfEbOrgtJVqIr4mOB3WlnV1lG+enj6l@gnusha.org X-Gm-Message-State: AOJu0Yztlp6aMfpq68BDc58CkXYF+UiaC141cnbLHuNZhdqGe6PsiT/q Nn06d/qhJdEpgw6E0BAujoxrJHi7wFQT4SQ0mIdzh7lxYUy5tbOWiO+G X-Google-Smtp-Source: AGHT+IFQdsYmc9weSHSMkbBaHLVR8c0I2TP+1xzZF8hwWYQkaVkrOxCgzsmkraT6gR9JexQg9hpt5w== X-Received: by 2002:a05:6808:2e49:b0:450:4628:e3ce with SMTP id 5614622812f47-4514e62d950mr6705901b6e.15.1764349044116; Fri, 28 Nov 2025 08:57:24 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a1V6qLRHYazDpRBQk0QS7/zk6CLUpTdBWAGfTT6VjXrQ==" Received: by 2002:a05:6870:2408:b0:3d5:54c4:3245 with SMTP id 586e51a60fabf-3f0d2734145ls1348935fac.2.-pod-prod-01-us; Fri, 28 Nov 2025 08:57:19 -0800 (PST) X-Received: by 2002:a05:6808:4491:b0:450:42c9:4cd0 with SMTP id 5614622812f47-45112d03a4emr12690156b6e.49.1764349039422; Fri, 28 Nov 2025 08:57:19 -0800 (PST) Received: by 2002:a81:fb03:0:b0:786:8d90:70d8 with SMTP id 00721157ae682-78ac3365063ms7b3; Fri, 28 Nov 2025 08:34:52 -0800 (PST) X-Received: by 2002:a05:690c:4a0e:b0:787:ec83:5ce6 with SMTP id 00721157ae682-78a8b56fa4emr197656937b3.61.1764347691062; Fri, 28 Nov 2025 08:34:51 -0800 (PST) Date: Fri, 28 Nov 2025 08:34:50 -0800 (PST) From: Jon Atack To: Bitcoin Development Mailing List Message-Id: <9b8c8573-cafb-447e-9923-b9a3b9e10950n@googlegroups.com> In-Reply-To: References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> <3a66dbbe9a9c46566c8a9a16ccb1cc91@dtrt.org> <012c719c-0f56-474d-8851-a2db3a0b422cn@googlegroups.com> <27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn@googlegroups.com> <0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42@sprovoost.nl> Subject: Re: [bitcoindev] Motion to Activate BIP 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_925582_297617780.1764347690740" 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_925582_297617780.1764347690740 Content-Type: multipart/alternative; boundary="----=_Part_925583_1224540679.1764347690740" ------=_Part_925583_1224540679.1764347690740 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 community's time asking for review of LLM-generated BIP drafts, as they=20 represent the most problematic submissions in their ease of slick slop=20 generation and possibility of hallucinations. "authors must proactively disclose up-front any use of AI/LLMs" -> please= =20 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= =20 shortcut to save time and proof of work, but... they help editors handle=20 these submissions. > Until that is done, the BIP editors will still have plenty of reasons to= =20 reject low-quality BIPs created by LLMs under the rules laid out in "BIP=20 Editor Responsibilities and Workflow".=20 Not sure those rules cover this, and would they allow us to use=20 Drahtbot-like automation as an aid? I don't see a controversy so much as an asymmetry between those who want to= =20 use LLMs and those who don't particularly want to review LLMs. Probably the most interesting change that BIP3 brings is the ability to be= =20 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=20 https://github.com/bitcoin/bips/pull/2006 ), and there was not a lot of=20 discussion in that PR. I feel what adds to the controversy is that the=20 rules are pretty strict: "No content may be generated by AI/LLMs and=20 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=20 entails. If no content may be generated by LLMs, why have a rule at=20 all that forces me to disclose any use of LLMs? What is "any"? As an=20 author, am I required to disclose that I used a LLM to summarize an=20 email that a co-author of the BIP sent me? If yes, also if the email=20 was about the question which restaurant to meet for lunch and discuss=20 the BIP? Probably the answer is "no", but where's the border? What if I=20 used an LLM to reject an idea that didn't even appear end up in the=20 BIP? Do I need to disclose this? The text doesn't give any guidance=20 here. What does it mean that the disclosure is "up-front"? Do I need to=20 disclose before I start writing the BIP? And how will the disclosure=20 look like? If AI was used when writing the reference implementation=20 for say, a proposed new opcode, will it be impossible to implement that=20 opcode in Bitcoin because it's not allowed to write a BIP about it?=20 Moreover, the same commit adds text that requires that a BIP must be=20 the "original work of its authors". This raises other questions, e.g.,=20 am I allowed to submit a BIP that proposes an idea originating from=20 someone else's blog post or research paper? If you ask me, this will be=20 forbidden under the rules of BIP3.=20 (I hear Jon, the author of the rule, yelling at me "no, that's not what=20 I meant!". But I claim it's a plausible interpretation of the text in=20 BIP3.)=20 My meta-point is that this commit was a rather large change that got=20 merged into the BIP3 pretty late in the process without getting a lot=20 of attention. Many (Concept) ACK mentioned in the activation PR=20 ( https://github.com/bitcoin/bips/pull/1820 ) predate that change.=20 In the interest of not letting the controversy around AI holding the=20 activation BIP3 up, I suggest reverting that commit for now. It will=20 still be possible to change BIP3 after it has been activated (or the AI=20 stuff could go the a separate BIP). Until that is done, the BIP editors=20 will still have plenty of reasons to reject low-quality BIPs created by=20 LLMs under the rules laid out in "BIP Editor Responsibilities and=20 Workflow".=20 Best,=20 Tim=20 On Sun, 2025-11-23 at 02:23 +0530, /dev /fd0 wrote:=20 > BIPs are just documents that can be maintained in any repository.=20 > Nobody cares whether the document was assigned a number by the=20 > gatekeepers or if AI was used to improve the grammar, content etc.=20 >=20 > /dev/fd0=20 > floppy disk guy =20 >=20 > On Sun, Nov 23, 2025 at 2:08=E2=80=AFAM Sjors Provoost =20 > wrote:=20 > > Why not have a simple rule which states that "low effort=20 > > contributions, such as fully LLM generated proposals, may be=20 > > ignored without a full reading".=20 > >=20 > > That should give BIP editors permission to use tools to detect and=20 > > auto-close such content. They need to detect it anyway in order to=20 > > enforce the proposed rule (of not allowing it).=20 > >=20 > > Judging effort is subjective, just like judging quality (an=20 > > existing criterion), but it avoids the need for editors to read the=20 > > whole thing.=20 > >=20 > > It's also not a big deal if the auto-close tools are slightly=20 > > overzealous. If an author believes their proposal was unfairly=20 > > closed they can demonstrate their effort, e.g. link to a conference=20 > > talk about the topic, have someone vouch that they had=20 > > conversations about the proposal, etc. All that takes is some=20 > > effort :-)=20 > >=20 > > I don't think copyright should be a concern. If someone sends a=20 > > takedown notice for a particular BIP, just take it down, and then=20 > > either start a legal fight or rewrite it in different words. We're=20 > > not talking about patents here.=20 > >=20 > > Greg Maxwell wrote:=20 > >=20 > > > There is a particularly clear pattern at least with current LLM=20 > > > tools that users who lack the skills to have authored the work=20 > > > without an LLM are generally unable to recognize when the LLM is=20 > > > full of crap (and even sometimes when they should know better),=20 > > > so unfortunately they're only benign to use in the hands of those=20 > > > whose need is the least. =20 > >=20 > > This is indeed an issue and also applies to high effort=20 > > contributions, where it's hopefully limited to a couple of=20 > > paragraphs. Reviewers should be alert to this. It can often be=20 > > fixed by asking the author why a paragraph is so verbose.=20 > > Implementing a BIP in code should also help get rid of any=20 > > superfluous or incorrect paragraphs. So I would expect that=20 > > actually important and widely used BIPs become well polished, even=20 > > if they didn't start out great. Unused BIPs will be lower quality,=20 > > but nobody cares.=20 > >=20 > > - Sjors=20 > >=20 > > > Op 22 nov 2025, om 16:14 heeft Jon Atack =20 > > > het volgende geschreven:=20 > > >=20 > > > The fundamental problem at this time is that prospective authors=20 > > > want to use LLMs to create content, but it puts maintainers who=20 > > > handle the submissions and the few experienced reviewers=20 > > > available to review the submissions at an asymmetric=20 > > > disadvantage... until or unless AI can analyze and auto-close=20 > > > those submissions relatively reliably and fairly. Even with AI=20 > > > tooling to help, who wants to spend their time reviewing LLM=20 > > > content or trying to detect confident AI hallucinations?=20 > > >=20 > > > Therefore, human heuristics like social capital, proof of work,=20 > > > and personal referrals/recommendations to review are therefore=20 > > > likely to become even more important. Maybe this should this be=20 > > > expressed in BIP 3 to set expectations.=20 > > >=20 > > > We have seen a wave of BIP draft PRs opened by new GitHub=20 > > > accounts with no history or proof of work and often appearing to=20 > > > be LLM-generated. It may be helpful to clarify for now in BIP 3=20 > > > that such submissions are likely to be closed outright. The=20 > > > alternative of letting the repository have many open-yet-ignored=20 > > > PRs probably isn't a desirable option.=20 > > >=20 > > > On Friday, November 21, 2025 at 5:25:48=E2=80=AFPM UTC-6 Greg Maxwell= =20 > > > wrote:=20 > > > Because if you don't you'll eventually get figured out and people=20 > > > will ignore all your further submissions--- in fact, that will=20 > > > *already* happen, which is part of why the guidance is useful. =20 > > > No one is obligated to even read any of these submissions and if=20 > > > indeed there are many low quality AI powered ones in the future=20 > > > (as we've been starting to see now) then many won't be read.=20 > > >=20 > > >=20 > > >=20 > > > On Thu, Nov 20, 2025 at 9:47=E2=80=AFAM Oghenovo Usiwoma=20 > > > wrote:=20 > > > > I think it makes sense to request that submissions should state=20 > > > > if - and to what degree - AI has been used. It's reasonable to=20 > > > > expect fewer eyeballs on AI generated submissions as they're so=20 > > > > easily generated and their potential for wasting reviewer time=20 > > > > is high.=20 > > >=20 > > > In my humble opinion, I believe that humans will continue to use=20 > > > the easiest method available to them to achieve their goals. If=20 > > > we agree that humans will do this, then there will be a lot of=20 > > > AI-assited content. If I did write an AI-assited BIP draft, why=20 > > > would I add this "AI-label" to my BIP when I know that it will=20 > > > cause reviewers to ignore it?=20 > > >=20 > > > On Thu, Nov 20, 2025 at 3:18=E2=80=AFAM Bitcoin Mechanic=20 > > > wrote:=20 > > > I think it makes sense to request that submissions should state=20 > > > if - and to what degree - AI has been used. It's reasonable to=20 > > > expect fewer eyeballs on AI generated submissions as they're so=20 > > > easily generated and their potential for wasting reviewer time is=20 > > > high.=20 > > >=20 > > > If people are submitting AI generated code and lying about it=20 > > > than that obviously undermines what it is they're proposing so=20 > > > they're naturally disincentivized to do so, thus the honour=20 > > > system should be relatively effective.=20 > > >=20 > > > I think most people have begun using it for making outlines and=20 > > > tweaking from there. The time saved is too significant for many=20 > > > to resist, and declaring that it was used for an initial outline=20 > > > shouldn't be too dissuasive for any reviewers.=20 > > >=20 > > > The deeper discussion around legal implications and generally=20 > > > about AI code quality is not resolvable here, it's a massive=20 > > > topic with deep philosophical implications that go way outside=20 > > > the scope of BIP 3 imo.=20 > > >=20 > > > Thanks=20 > > >=20 > > > On Wednesday, November 19, 2025 at 2:40:55=E2=80=AFPM UTC-8 Bitcoin E= rror=20 > > > Log wrote:=20 > > > A few years ago, I had this idea that bitcoin divisibility needed=20 > > > to be fixed as a misconception. I put it (proto-bip177) in our=20 > > > bitcoin wallet app, promoted the idea where I could. It worked=20 > > > great, but only our users knew.=20 > > >=20 > > > And then AI became good enough to use for some things. AI has=20 > > > been a HUGE unlock for me and my learning and creating style.=20 > > > Early this year, I told my AI, filled with context about the=20 > > > upcoming BIP3 standard, and examples of related BIPs, to make a=20 > > > BIP for me that properly expressed all of the nuances of my idea=20 > > > on how to handle removal of decimals in a UX.=20 > > >=20 > > > It looked pretty good, but AI wasn't as good as it is today, and=20 > > > the formatting was total slop. Thankfully, most of the BIP=20 > > > reviewers are actually amazing people, and I was able to contact=20 > > > them directly and ask for help, because I'm not an actual=20 > > > developer (yet). After some private help, it was good enough for=20 > > > the mailing list, and a real draft.=20 > > >=20 > > > BIP 177 is a very simple BIP compared to most, and I'd probably=20 > > > make it better if I started today, but ... it exists! It might be=20 > > > the first/only (?) vibe-BIP, and, as of last week, due to Cashapp=20 > > > and Square support, it's possible that BIP 177 is now in more=20 > > > people's hands than not.=20 > > >=20 > > > Today, I now have several private drafts of BIPs I am working on=20 > > > with AI, I am trying to impose less slop on my peers as I work in=20 > > > private. These newer BIPs are increasingly technical, and I have=20 > > > also started vibe-coding implementations to test them, and I=20 > > > continue growing into an engineer.=20 > > >=20 > > > Now the BIP repo is my favorite part of Bitcoin and interacting=20 > > > with Bitcoin Core. I feel sincere gratitude to three BIP=20 > > > reviewers specifically for humoring my sincere, yet not matured,=20 > > > effort and desire to improve Bitcoin without changing consensus=20 > > > code.=20 > > >=20 > > > My vision for the BIP repo and reviewers, and AI, is much=20 > > > different than yours. It is part of the story that brought me=20 > > > closer to Bitcoin development, and deep respect to my superiors=20 > > > for tolerating me while I was/am fledgling.=20 > > >=20 > > > Please don't add more weird subjective, exclusive barriers just=20 > > > because AI is warping reality. Deal with it, and please, please,=20 > > > continue making an effort to not only guard the BIP repo, but=20 > > > ensure it remains a fertile ground where Bitcoin Core maintains=20 > > > an attitude of being great stewards to the people, not only the=20 > > > specs.=20 > > >=20 > > > After all, we will need people to replace you some day, and those=20 > > > people need role models too.=20 > > >=20 > > > ~John Carvalho=20 > > >=20 > > >=20 > > > On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg Maxwell =20 > > > wrote:=20 > > > No doubt *you* are able to make good documents with or without=20 > > > the aid of AI.=20 > > >=20 > > > With outright AI 'authorship' you immediately run into potential=20 > > > copyright issues-- which I think is the origin of the "generated=20 > > > by" prohibition, otherwise I think disclosure would be=20 > > > sufficient.=20 > > >=20 > > > Taking a step back: is Bitcoin's welfare maximized by permitting=20 > > > LLM glurge submissions in standards documents? In some cases it's=20 > > > benign, I readily agree, in others its harmful. But the number=20 > > > of good submissions that could be made would hardly be increased=20 > > > by LLMs (being limited by expert proposers with good ideas) but=20 > > > the number of potential poor submissions is increased=20 > > > astronomically. So I think it's pretty clearly a net harm to=20 > > > have text authored that way.=20 > > >=20 > > > I've never had an impression that drafting was at all a limiting=20 > > > step in writing BIPs, though even to the extent that it has been=20 > > > at times it's possible to use LLMs in a review capacity to make=20 > > > authorship much easier ("What's missing / unclear?") without=20 > > > resorting to using it to author.=20 > > >=20 > > > There is a particularly clear pattern at least with current LLM=20 > > > tools that users who lack the skills to have authored the work=20 > > > without an LLM are generally unable to recognize when the LLM is=20 > > > full of crap (and even sometimes when they should know better),=20 > > > so unfortunately they're only benign to use in the hands of those=20 > > > whose need is the least. =20 > > >=20 > > > And as a reviewer outside of Bitcoin I've found LLM powered=20 > > > proposers to be absolutely the worst to deal with. Because=20 > > > they're not submitting their own words and ideas, they're unable=20 > > > to change their thinking in response or explain sufficiently to=20 > > > change yours--- the interactions often degrade to them just copy=20 > > > and pasting their chatbot back to you. Because it's cheap to=20 > > > generate more text they also tend to flood you out with documents=20 > > > several times longer than any human author would have bothered=20 > > > with.=20 > > >=20 > > > I think LLMs have generally created something of an existential=20 > > > threat to most open collaborations: Now its so easy to get=20 > > > flooded out by subtly worthless material. Many projects,=20 > > > including, Bitcoin have long struggled with review capacity being=20 > > > limited and a far amount of time waste by thoughtless (or even=20 > > > crazy!) submissions, but now it's automated and even the most=20 > > > well meaning person may now make submissions that are as bad as=20 > > > the most deviously constructed malicious submissions could have=20 > > > been in the past, not even know they are doing it, and can make a=20 > > > dozen proposals before lunch without even breaking a sweat.=20 > > >=20 > > >=20 > > >=20 > > > On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Harding=20 > > > wrote:=20 > > > On 2025-11-04 15:10, Murch wrote:=20 > > > > Summary of changes since BIP=E2=80=AF3 was advanced to Proposed:=20 > > > > [...]=20 > > > > - that BIPs submissions may not be generated by AI/LLM=E2=81=B5= =20 > > > > [...]=20 > > > > =E2=81=B5 https://github.com/bitcoin/bips/pull/2006=20 > > >=20 > > > I strongly disagree with this change. If I were to begin working=20 > > > on a=20 > > > new BIP today, I would use AI throughout the process. I'd ask it=20 > > > to=20 > > > help me create a todo list of what should go in the BIP; I'd ask=20 > > > it 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.=20 > > >=20 > > > 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=20 > > > of AI=20 > > > and human writing and editing.=20 > > >=20 > > > I think considerate use of AI would be even more valuable for=20 > > > people 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=20 > > > they're=20 > > > bad writers.=20 > > >=20 > > > The PR forbidding AI doesn't go into any detail about its=20 > > > motivation,=20 > > > although it references a previous discussion[1] where a low-=20 > > > quality BIP=20 > > > PR was opened using mostly AI-generated content. I'm guessing=20 > > > the=20 > > > motivation is that AI (by itself) generates low-quality technical=20 > > > content, BIPs should be high-quality technical content, and=20 > > > therefore we=20 > > > should ban the use of AI.=20 > > >=20 > > > However, as mentioned in the previous discussion, the BIP process=20 > > > already requires high-quality content.[2] AI-generated content=20 > > > can be=20 > > > high-quality, especially if its creation and editing was guided=20 > > > by a=20 > > > knowledgeable human. Banning specific tools like AI seems=20 > > > redundant and=20 > > > penalizes people who either need those tools or who can use them=20 > > > effectively.=20 > > >=20 > > > I advocate for reverting the first hunk of BIPs repository PR=20 > > > 2006.=20 > > >=20 > > > -Dave=20 > > >=20 > > > [1] https://github.com/bitcoin/bips/pull/2005=20 > > > [2] "After fleshing out the proposal further and ensuring that it=20 > > > is of=20 > > > **high quality** and properly formatted, the authors should open=20 > > > a pull=20 > > > request to the BIPs repository." --BIP3, emphasis added=20 > > >=20 > > > --=20 > > > You received this message because you are subscribed to the=20 > > > Google Groups "Bitcoin Development Mailing List" group.=20 > > > To unsubscribe from this group and stop receiving emails from it,=20 > > > send an email to bitcoindev+...@googlegroups.com.=20 > > > To view this discussion visit=20 > > >=20 https://groups.google.com/d/msgid/bitcoindev/3a66dbbe9a9c46566c8a9a16ccb1cc= 91%40dtrt.org=20 > > > .=20 > > >=20 > > > --=20 > > > You received this message because you are subscribed to the=20 > > > Google Groups "Bitcoin Development Mailing List" group.=20 > > > To unsubscribe from this group and stop receiving emails from it,=20 > > > send an email to bitcoindev+...@googlegroups.com.=20 > > > To view this discussion visit=20 > > >=20 https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5= CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com=20 > > > .=20 > > >=20 > > > --=20 > > > You received this message because you are subscribed to the=20 > > > Google Groups "Bitcoin Development Mailing List" group.=20 > > > To unsubscribe from this group and stop receiving emails from it,=20 > > > send an email to bitcoindev+...@googlegroups.com.=20 > > > To view this discussion visit=20 > > >=20 https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a= 0b422cn%40googlegroups.com=20 > > > .=20 > > >=20 > > > --=20 > > > You received this message because you are subscribed to the=20 > > > Google Groups "Bitcoin Development Mailing List" group.=20 > > > To unsubscribe from this group and stop receiving emails from it,=20 > > > send an email to bitcoindev+...@googlegroups.com.=20 > > > To view this discussion visit=20 > > >=20 https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DH= tFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com=20 > > > .=20 > > >=20 > > > --=20 > > > You received this message because you are subscribed to the=20 > > > Google Groups "Bitcoin Development Mailing List" group.=20 > > > To unsubscribe from this group and stop receiving emails from it,=20 > > > send an email to bitcoindev+...@googlegroups.com.=20 > > > To view this discussion visit=20 > > >=20 https://groups.google.com/d/msgid/bitcoindev/27b2b0ba-ba85-41f5-96b8-cf3fbb= e5fafdn%40googlegroups.com=20 > > > .=20 > >=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/= 9b8c8573-cafb-447e-9923-b9a3b9e10950n%40googlegroups.com. ------=_Part_925583_1224540679.1764347690740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list, hi Tim,

No worries, not yelling :)=

The idea was and is to save review time.
<= div>
"No content may be generated by AI/LLMs" -> pl= ease don't waste=20 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" -> plea= se say in the PR description if LLMs were used, and how, to help us save ti= me.

"Up-front" means without people needing to a= sk.

Perhaps the rules are naive in the face of t= he temptation to use LLMs as a shortcut to save time and proof of work, but= ... they help editors handle these submissions.

= > Until that is done, the BIP editors will still have plenty of reasons = to reject low-quality BIPs created by LLMs under the rules laid out in "BIP= Editor Responsibilities and Workflow".

Not sure those rules cover this, and woul= d 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.<= /div>

Probably the most interesting change that BIP3 brings is th= e ability to be a living document that can hopefully evolve.


On Friday, November 28, 202= 5 at 9:48:44=E2=80=AFAM UTC-6 Tim Ruffing wrote:
The change that added the AI rules was merged quite la= te=C2=A0on Oct 22 (see
https://github.com/bitcoin/bips/pull/2006 ), and th= ere was not a lot of
discussion in that PR. I feel what adds to the controversy is that th= e
rules are pretty strict: "No content may be generated by AI/LLMs and
authors must proactively disclose up-front any use of AI/LLMs."=C2=A0

I think this rule is low quality: It's not clear to me what it
entails.=C2=A0 If no content may be generated by LLMs, why have a rul= e 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.=C2=A0What 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 th= at
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?=C2=A0If you ask me, this = will be
forbidden under the rules of BIP3.=20

(I hear Jon, the author of the rule, yelling at me "no, that's not wh= at
I meant!". But I claim it's a plausible interpretation of the text in
BIP3.)=20

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
(=C2=A0https://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 edito= rs
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=20

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 et= c.
>=20
> /dev/fd0
> floppy disk guy=C2=A0
>=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 b= e
> > ignored without a full reading".
> >=20
> > That should give BIP editors permission to use tools to det= ect and
> > auto-close such content. They need to detect it anyway in o= rder to
> > enforce the proposed rule (of not allowing it).
> >=20
> > Judging effort is subjective, just like judging quality (an
> > existing criterion), but it avoids the need for editors to = read the
> > whole thing.
> >=20
> > It's also not a big deal if the auto-close tools are slight= ly
> > overzealous. If an author believes their proposal was unfai= rly
> > closed they can demonstrate their effort, e.g. link to a co= nference
> > talk about the topic, have someone vouch that they had
> > conversations about the proposal, etc. All that takes is so= me
> > effort :-)
> >=20
> > I don't think copyright should be a concern. If someone sen= ds a
> > takedown notice for a particular BIP, just take it down, an= d then
> > either start a legal fight or rewrite it in different words= . We're
> > not talking about patents here.
> >=20
> > Greg Maxwell wrote:
> >=20
> > > There is a particularly clear pattern at least with cu= rrent 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 han= ds of those
> > > whose need is the least.=C2=A0=20
> >=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= 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 polishe= d, even
> > if they didn't start out great. Unused BIPs will be lower q= uality,
> > but nobody cares.
> >=20
> > - Sjors
> >=20
> > > Op 22 nov 2025, om 16:14 heeft Jon Atack <jonny...@gmail.com>
> > > het volgende geschreven:
> > >=20
> > > The fundamental problem at this time is that prospecti= ve authors
> > > want to use LLMs to create content, but it puts mainta= iners who
> > > handle the submissions and the few experienced reviewe= rs
> > > available to review the submissions at an asymmetric
> > > disadvantage... until or unless AI can analyze and aut= o-close
> > > those submissions relatively reliably and fairly. Even= with AI
> > > tooling to help, who wants to spend their time reviewi= ng LLM
> > > content or trying to detect confident AI hallucination= s?
> > >=20
> > > Therefore, human heuristics like social capital, proof= of work,
> > > and personal referrals/recommendations to review are t= herefore
> > > likely to become even more important. Maybe this shoul= d this be
> > > expressed in BIP 3 to set expectations.
> > >=20
> > > We have seen a wave of BIP draft PRs opened by new Git= Hub
> > > accounts with no history or proof of work and often ap= pearing 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-y= et-ignored
> > > PRs probably isn't a desirable option.
> > >=20
> > > 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 ignore all your further submissions--- in fact, t= hat will
> > > *already* happen, which is part of why the guidance is= useful.=C2=A0
> > > No one is obligated to even read any of these submissi= ons and if
> > > indeed there are many low quality AI powered ones in t= he future
> > > (as we've been starting to see now) then many won't be= read.
> > >=20
> > >=20
> > >=20
> > > On Thu, Nov 20, 2025 at 9:47=E2=80=AFAM Oghenovo Usiwo= ma
> > > <eun...@gmail.com= > wrote:
> > > > I think it makes sense to request that submission= s 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.
> > >=20
> > > In my humble opinion, I believe that humans will conti= nue 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 d= raft, why
> > > would I add this "AI-label" to my BIP when I know that= it will
> > > cause reviewers to ignore it?
> > >=20
> > > On Thu, Nov 20, 2025 at 3:18=E2=80=AFAM Bitcoin Mechan= ic
> > > <bitcoin...@ocean.xyz= > wrote:
> > > I think it makes sense to request that submissions sho= uld state
> > > if - and to what degree - AI has been used. It's reaso= nable to
> > > expect fewer eyeballs on AI generated submissions as t= hey're so
> > > easily generated and their potential for wasting revie= wer time is
> > > high.
> > >=20
> > > If people are submitting AI generated code and lying a= bout it
> > > than that obviously undermines what it is they're prop= osing so
> > > they're naturally disincentivized to do so, thus the h= onour
> > > system should be relatively effective.
> > >=20
> > > I think most people have begun using it for making out= lines and
> > > tweaking from there. The time saved is too significant= for many
> > > to resist, and declaring that it was used for an initi= al outline
> > > shouldn't be too dissuasive for any reviewers.
> > >=20
> > > The deeper discussion around legal implications and ge= nerally
> > > about AI code quality is not resolvable here, it's a m= assive
> > > topic with deep philosophical implications that go way= outside
> > > the scope of BIP 3 imo.
> > >=20
> > > Thanks
> > >=20
> > > 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 divisibi= lity needed
> > > to be fixed as a misconception. I put it (proto-bip177= ) in our
> > > bitcoin wallet app, promoted the idea where I could. I= t worked
> > > great, but only our users knew.
> > >=20
> > > 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 abo= ut 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.
> > >=20
> > > 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 act= ual
> > > developer (yet). After some private help, it was good = enough for
> > > the mailing list, and a real draft.=20
> > >=20
> > > 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.=20
> > >=20
> > > 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 a= s 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.=20
> > >=20
> > > Now the BIP repo is my favorite part of Bitcoin and in= teracting
> > > with Bitcoin Core. I feel sincere gratitude to three B= IP
> > > reviewers specifically for humoring my sincere, yet no= t matured,
> > > effort and desire to improve Bitcoin without changing = consensus
> > > code.
> > >=20
> > > My vision for the BIP repo and reviewers, and AI, is m= uch
> > > different than yours. It is part of the story that bro= ught me
> > > closer to Bitcoin development, and deep respect to my = superiors
> > > for tolerating me while I was/am fledgling.=20
> > >=20
> > > Please don't add more weird subjective, exclusive barr= iers just
> > > because AI is warping reality. Deal with it, and pleas= e, please,
> > > continue making an effort to not only guard the BIP re= po, but
> > > ensure it remains a fertile ground where Bitcoin Core = maintains
> > > an attitude of being great stewards to the people, not= only the
> > > specs.=20
> > >=20
> > > After all, we will need people to replace you some day= , and those
> > > people need role models too.
> > >=20
> > > ~John Carvalho
> > >=20
> > >=20
> > > On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg Maxwell &= lt;gmax...@gmail.com>
> > > wrote:
> > > No doubt *you* are able to make good documents with or= without
> > > the aid of AI.
> > >=20
> > > 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.
> > >=20
> > > 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.=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 i= deas) but
> > > the number of potential poor submissions is increased
> > > astronomically.=C2=A0 So I think it's pretty clearly a= net harm to
> > > have text authored that way.
> > >=20
> > > I've never had an impression that drafting was at all = a limiting
> > > step in writing BIPs, though even to the extent that i= t has been
> > > at times it's possible to use LLMs in a review capacit= y to make
> > > authorship much easier ("What's missing / unclear?") w= ithout
> > > resorting to using it to author.
> > >=20
> > > There is a particularly clear pattern at least with cu= rrent 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 han= ds of those
> > > whose need is the least.=C2=A0=20
> > >=20
> > > And as a reviewer outside of Bitcoin I've found LLM po= wered
> > > proposers to be absolutely the worst to deal with. Bec= ause
> > > they're not submitting their own words and ideas, they= 're unable
> > > to change their thinking in response or explain suffic= iently to
> > > change yours--- the interactions often degrade to them= just copy
> > > and pasting their chatbot back to you.=C2=A0 Because i= t's cheap to
> > > generate more text they also tend to flood you out wit= h documents
> > > several times longer than any human author would have = bothered
> > > with.
> > >=20
> > > I think LLMs have generally created something of an ex= istential
> > > threat to most open collaborations: Now its so easy to= get
> > > flooded out by subtly worthless material.=C2=A0 Many p= rojects,
> > > including, Bitcoin have long struggled with review cap= acity being
> > > limited and a far amount of time waste by thoughtless = (or even
> > > crazy!) submissions, but now it's automated and even t= he most
> > > well meaning person may now make submissions that are = as bad as
> > > the most deviously constructed malicious submissions c= ould have
> > > been in the past, not even know they are doing it, and= can make a
> > > dozen proposals before lunch without even breaking a s= weat.
> > >=20
> > >=20
> > >=20
> > > On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Hard= ing
> > > <da...@dtrt.org&g= t; wrote:
> > > On 2025-11-04 15:10, Murch wrote:
> > > > Summary of changes since BIP=E2=80=AF3 was advanc= ed to Proposed:
> > > > [...]
> > > > =C2=A0 =C2=A0- that BIPs submissions may not be g= enerated by AI/LLM=E2=81=B5
> > > > [...]
> > > > =E2=81=B5 https://github.com/bitcoi= n/bips/pull/2006
> > >=20
> > > I strongly disagree with this change.=C2=A0 If I were = to begin working
> > > on a=20
> > > new BIP today, I would use AI throughout the process.= =C2=A0 I'd ask it
> > > to=20
> > > help me create a todo list of what should go in the BI= P; I'd ask
> > > it to=20
> > > create a draft based on existing BIPs, my todo list, a= nd whatever
> > > other=20
> > > work products I had (e.g. prototypes); I'd then ask it= to help me
> > > refine=20
> > > the document until I was satisfied.
> > >=20
> > > I would, of course, review every word of the draft BIP= before
> > > submitting=20
> > > it for consideration and ensure that it represented th= e highest
> > > quality=20
> > > work I was able to produce---but the ultimate work wou= ld be a mix
> > > of AI=20
> > > and human writing and editing.
> > >=20
> > > I think considerate use of AI would be even more valua= ble for
> > > people who=20
> > > are less comfortable with writing technical English-la= nguage
> > > documents=20
> > > than I am.=C2=A0 For example, non-native literates, pe= ople with
> > > disabilities=20
> > > that make text input difficulty, and those who recogni= ze that
> > > they're=20
> > > bad writers.
> > >=20
> > > 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 BIP=20
> > > PR was opened using mostly AI-generated content.=C2=A0= I'm guessing
> > > the=20
> > > motivation is that AI (by itself) generates low-qualit= y technical
> > > content, BIPs should be high-quality technical content= , and
> > > therefore we=20
> > > should ban the use of AI.
> > >=20
> > > However, as mentioned in the previous discussion, the = BIP process
> > > already requires high-quality content.[2]=C2=A0 AI-gen= erated content
> > > can be=20
> > > high-quality, especially if its creation and editing w= as guided
> > > by a=20
> > > knowledgeable human.=C2=A0 Banning specific tools like= AI seems
> > > redundant and=20
> > > penalizes people who either need those tools or who ca= n use them=20
> > > effectively.
> > >=20
> > > I advocate for reverting the first hunk of BIPs reposi= tory PR
> > > 2006.
> > >=20
> > > -Dave
> > >=20
> > > [1] https://github.com/bitcoin/bips/pull= /2005
> > > [2] "After fleshing out the proposal further and ensur= ing that it
> > > is of=20
> > > **high quality** and properly formatted, the authors s= hould open
> > > a pull=20
> > > request to the BIPs repository." --BIP3, emphasis adde= d
> > >=20
> > > --=20
> > > You received this message because you are subscribed t= o the
> > > Google Groups "Bitcoin Development Mailing List" group= .
> > > To unsubscribe from this group and stop receiving emai= ls from it,
> > > send an email to bitcoin= dev+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bitcoindev/3a66dbbe9a9c46566c8a9a1= 6ccb1cc91%40dtrt.org
> > > .
> > >=20
> > > --=20
> > > You received this message because you are subscribed t= o the
> > > Google Groups "Bitcoin Development Mailing List" group= .
> > > To unsubscribe from this group and stop receiving emai= ls from it,
> > > send an email to bitcoin= dev+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bitcoin= dev/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com<= /a>
> > > .
> > >=20
> > > --=20
> > > You received this message because you are subscribed t= o the
> > > Google Groups "Bitcoin Development Mailing List" group= .
> > > To unsubscribe from this group and stop receiving emai= ls from it,
> > > send an email to bitcoin= dev+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bitcoindev/012c719c-0= f56-474d-8851-a2db3a0b422cn%40googlegroups.com
> > > .
> > >=20
> > > --=20
> > > You received this message because you are subscribed t= o the
> > > Google Groups "Bitcoin Development Mailing List" group= .
> > > To unsubscribe from this group and stop receiving emai= ls from it,
> > > send an email to bitcoin= dev+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bit= coindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gm= ail.com
> > > .
> > >=20
> > > --=20
> > > You received this message because you are subscribed t= o the
> > > Google Groups "Bitcoin Development Mailing List" group= .
> > > To unsubscribe from this group and stop receiving emai= ls from it,
> > > send an email to bitcoin= dev+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bitcoindev/27b2b0ba-b= a85-41f5-96b8-cf3fbbe5fafdn%40googlegroups.com
> > > .
> >=20

--
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/9b8c8573-cafb-447e-9923-b9a3b9e10950n%40googlegroups.com.
------=_Part_925583_1224540679.1764347690740-- ------=_Part_925582_297617780.1764347690740--