From: Greg Maxwell <gmaxwell@gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Cc: Murch <murch@murch.one>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Wed, 19 Nov 2025 01:12:27 +0000 [thread overview]
Message-ID: <CAAS2fgRV1aZ9xvAhBriZ=XdmYf5CvrvXWXsjVD07uynivW_qkg@mail.gmail.com> (raw)
In-Reply-To: <3a66dbbe9a9c46566c8a9a16ccb1cc91@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 5791 bytes --]
No doubt *you* are able to make good documents with or without the aid of
AI.
With outright AI 'authorship' you immediately run into potential copyright
issues-- which I think is the origin of the "generated by" prohibition,
otherwise I think disclosure would be sufficient.
Taking a step back: is Bitcoin's welfare maximized by permitting LLM glurge
submissions in standards documents? In some cases it's benign, I readily
agree, in others its harmful. But the number of good submissions that
could be made would hardly be increased by LLMs (being limited by expert
proposers with good ideas) but the number of potential poor submissions is
increased astronomically. So I think it's pretty clearly a net harm to
have text authored that way.
I've never had an impression that drafting was at all a limiting step in
writing BIPs, though even to the extent that it has been at times it's
possible to use LLMs in a review capacity to make authorship much easier
("What's missing / unclear?") without resorting to using it to author.
There is a particularly clear pattern at least with current LLM tools that
users who lack the skills to have authored the work without an LLM are
generally unable to recognize when the LLM is full of crap (and even
sometimes when they should know better), so unfortunately they're only
benign to use in the hands of those whose need is the least.
And as a reviewer outside of Bitcoin I've found LLM powered proposers to be
absolutely the worst to deal with. Because they're not submitting their own
words and ideas, they're unable to change their thinking in response or
explain sufficiently to change yours--- the interactions often degrade to
them just copy and pasting their chatbot back to you. Because it's cheap
to generate more text they also tend to flood you out with documents
several times longer than any human author would have bothered with.
I think LLMs have generally created something of an existential threat to
most open collaborations: Now its so easy to get flooded out by subtly
worthless material. Many projects, including, Bitcoin have long struggled
with review capacity being limited and a far amount of time waste by
thoughtless (or even crazy!) submissions, but now it's automated and even
the most well meaning person may now make submissions that are as bad as
the most deviously constructed malicious submissions could have been in the
past, not even know they are doing it, and can make a dozen proposals
before lunch without even breaking a sweat.
On Wed, Nov 19, 2025 at 12:06 AM David A. Harding <dave@dtrt.org> wrote:
> On 2025-11-04 15:10, Murch wrote:
> > Summary of changes since BIP 3 was advanced to Proposed:
> > [...]
> > - that BIPs submissions may not be generated by AI/LLM⁵
> > [...]
> > ⁵ https://github.com/bitcoin/bips/pull/2006
>
> I strongly disagree with this change. If I were to begin working on a
> new BIP today, I would use AI throughout the process. I'd ask it to
> help me create a todo list of what should go in the BIP; I'd ask it to
> create a draft based on existing BIPs, my todo list, and whatever other
> work products I had (e.g. prototypes); I'd then ask it to help me refine
> the document until I was satisfied.
>
> I would, of course, review every word of the draft BIP before submitting
> it for consideration and ensure that it represented the highest quality
> work I was able to produce---but the ultimate work would be a mix of AI
> and human writing and editing.
>
> I think considerate use of AI would be even more valuable for people who
> are less comfortable with writing technical English-language documents
> than I am. For example, non-native literates, people with disabilities
> that make text input difficulty, and those who recognize that they're
> bad writers.
>
> The PR forbidding AI doesn't go into any detail about its motivation,
> although it references a previous discussion[1] where a low-quality BIP
> PR was opened using mostly AI-generated content. I'm guessing the
> motivation is that AI (by itself) generates low-quality technical
> content, BIPs should be high-quality technical content, and therefore we
> should ban the use of AI.
>
> However, as mentioned in the previous discussion, the BIP process
> already requires high-quality content.[2] AI-generated content can be
> high-quality, especially if its creation and editing was guided by a
> knowledgeable human. Banning specific tools like AI seems redundant and
> penalizes people who either need those tools or who can use them
> effectively.
>
> I advocate for reverting the first hunk of BIPs repository PR 2006.
>
> -Dave
>
> [1] https://github.com/bitcoin/bips/pull/2005
> [2] "After fleshing out the proposal further and ensuring that it is of
> **high quality** and properly formatted, the authors should open a pull
> request to the BIPs repository." --BIP3, emphasis added
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/3a66dbbe9a9c46566c8a9a16ccb1cc91%40dtrt.org
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7152 bytes --]
next prev parent reply other threads:[~2025-11-19 1:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 1:10 Murch
2025-11-05 1:53 ` Ruben Somsen
2025-11-12 19:03 ` [bitcoindev] " Greg Sanders
2025-11-13 0:23 ` Murch
2025-11-13 18:54 ` Greg Sanders
[not found] ` <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com>
2025-11-13 19:35 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-11-13 21:43 ` Murch
2025-11-14 17:05 ` Melvin Carvalho
2025-11-22 23:46 ` Murch
2025-11-29 23:00 ` Melvin Carvalho
2025-12-02 0:29 ` Murch
2025-11-15 22:01 ` Luke Dashjr
2025-11-18 4:26 ` Greg Maxwell
2025-12-02 22:46 ` Murch
2025-11-18 15:47 ` David A. Harding
2025-11-19 1:12 ` Greg Maxwell [this message]
2025-11-19 1:20 ` Bryan Bishop
2025-11-19 21:21 ` Jon Atack
2025-11-19 6:25 ` David A. Harding
2025-11-19 6:58 ` Bitcoin Error Log
2025-11-20 1:22 ` Bitcoin Mechanic
2025-11-20 9:06 ` Oghenovo Usiwoma
2025-11-20 17:23 ` Greg Maxwell
2025-11-22 15:14 ` Jon Atack
2025-11-22 19:30 ` Sjors Provoost
2025-11-22 20:53 ` /dev /fd0
2025-11-28 15:35 ` Tim Ruffing
2025-11-28 16:34 ` Jon Atack
2025-11-28 19:21 ` Pieter Wuille
2025-11-22 21:06 ` Bill MacDonald
2025-11-20 20:14 ` Mat Balez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgRV1aZ9xvAhBriZ=XdmYf5CvrvXWXsjVD07uynivW_qkg@mail.gmail.com' \
--to=gmaxwell@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt.org \
--cc=murch@murch.one \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox