From: Bitcoin Error Log <bitcoinerrorlog@gmail.com>
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: "David A. Harding" <dave@dtrt.org>, Murch <murch@murch.one>,
bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Motion to Activate BIP 3
Date: Wed, 19 Nov 2025 06:58:00 +0000 [thread overview]
Message-ID: <CAE2fw6vMPsqwy_e+E8yRt2MbnwbkC76dcEM1YY2qQHi5j1ZY0g@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRV1aZ9xvAhBriZ=XdmYf5CvrvXWXsjVD07uynivW_qkg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9073 bytes --]
A few years ago, I had this idea that bitcoin divisibility needed to be
fixed as a misconception. I put it (proto-bip177) in our bitcoin wallet
app, promoted the idea where I could. It worked great, but only our users
knew.
And then AI became good enough to use for some things. AI has been a HUGE
unlock for me and my learning and creating style. Early this year, I told
my AI, filled with context about the upcoming BIP3 standard, and examples
of related BIPs, to make a BIP for me that properly expressed all of the
nuances of my idea on how to handle removal of decimals in a UX.
It looked pretty good, but AI wasn't as good as it is today, and the
formatting was total slop. Thankfully, most of the BIP reviewers are
actually amazing people, and I was able to contact them directly and ask
for help, because I'm not an actual developer (yet). After some private
help, it was good enough for the mailing list, and a real draft.
BIP 177 is a very simple BIP compared to most, and I'd probably make it
better if I started today, but ... it exists! It might be the first/only
(?) vibe-BIP, and, as of last week, due to Cashapp and Square support, it's
possible that BIP 177 is now in more people's hands than not.
Today, I now have several private drafts of BIPs I am working on with AI, I
am trying to impose less slop on my peers as I work in private. These newer
BIPs are increasingly technical, and I have also started vibe-coding
implementations to test them, and I continue growing into an engineer.
Now the BIP repo is my favorite part of Bitcoin and interacting with
Bitcoin Core. I feel sincere gratitude to three BIP reviewers specifically
for humoring my sincere, yet not matured, effort and desire to improve
Bitcoin without changing consensus code.
My vision for the BIP repo and reviewers, and AI, is much different than
yours. It is part of the story that brought me closer to Bitcoin
development, and deep respect to my superiors for tolerating me while I
was/am fledgling.
Please don't add more weird subjective, exclusive barriers just because AI
is warping reality. Deal with it, and please, please, continue making an
effort to not only guard the BIP repo, but ensure it remains a fertile
ground where Bitcoin Core maintains an attitude of being great stewards to
the people, not only the specs.
After all, we will need people to replace you some day, and those people
need role models too.
~John Carvalho
On Wed, Nov 19, 2025 at 1:18 AM Greg Maxwell <gmaxwell@gmail.com> wrote:
> No doubt *you* are able to make good documents with or without the aid of
> AI.
>
> With outright AI 'authorship' you immediately run into potential copyright
> issues-- which I think is the origin of the "generated by" prohibition,
> otherwise I think disclosure would be sufficient.
>
> Taking a step back: is Bitcoin's welfare maximized by permitting LLM
> glurge submissions in standards documents? In some cases it's benign, I
> readily agree, in others its harmful. But the number of good submissions
> that could be made would hardly be increased by LLMs (being limited by
> expert proposers with good ideas) but the number of potential poor
> submissions is increased astronomically. So I think it's pretty clearly a
> net harm to have text authored that way.
>
> I've never had an impression that drafting was at all a limiting step in
> writing BIPs, though even to the extent that it has been at times it's
> possible to use LLMs in a review capacity to make authorship much easier
> ("What's missing / unclear?") without resorting to using it to author.
>
> There is a particularly clear pattern at least with current LLM tools that
> users who lack the skills to have authored the work without an LLM are
> generally unable to recognize when the LLM is full of crap (and even
> sometimes when they should know better), so unfortunately they're only
> benign to use in the hands of those whose need is the least.
>
> And as a reviewer outside of Bitcoin I've found LLM powered proposers to
> be absolutely the worst to deal with. Because they're not submitting their
> own words and ideas, they're unable to change their thinking in response or
> explain sufficiently to change yours--- the interactions often degrade to
> them just copy and pasting their chatbot back to you. Because it's cheap
> to generate more text they also tend to flood you out with documents
> several times longer than any human author would have bothered with.
>
> I think LLMs have generally created something of an existential threat to
> most open collaborations: Now its so easy to get flooded out by subtly
> worthless material. Many projects, including, Bitcoin have long struggled
> with review capacity being limited and a far amount of time waste by
> thoughtless (or even crazy!) submissions, but now it's automated and even
> the most well meaning person may now make submissions that are as bad as
> the most deviously constructed malicious submissions could have been in the
> past, not even know they are doing it, and can make a dozen proposals
> before lunch without even breaking a sweat.
>
>
>
> On Wed, Nov 19, 2025 at 12:06 AM David A. Harding <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
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3DXdmYf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAE2fw6vMPsqwy_e%2BE8yRt2MbnwbkC76dcEM1YY2qQHi5j1ZY0g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 11019 bytes --]
next prev parent reply other threads:[~2025-11-19 22:41 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
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 [this message]
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=CAE2fw6vMPsqwy_e+E8yRt2MbnwbkC76dcEM1YY2qQHi5j1ZY0g@mail.gmail.com \
--to=bitcoinerrorlog@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt.org \
--cc=gmaxwell@gmail.com \
--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