* [bitcoindev] Motion to Activate BIP 3
@ 2025-11-05 1:10 Murch
2025-11-05 1:53 ` Ruben Somsen
` (6 more replies)
0 siblings, 7 replies; 31+ messages in thread
From: Murch @ 2025-11-05 1:10 UTC (permalink / raw)
To: bitcoindev
Dear list,
After planned work on BIP 3⁰ finished in February, BIP 3 was advanced to
Proposed in March 2025¹. A few minor adjustments were made to BIP 3
since then (see below). I have since April maintained a pull request
that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820.
At this point, BIP 3 has received over 600 comments on GitHub and has
been discussed in multiple threads on this list. The proposal has been
Proposed for over seven months, and while several minor improvements
were proposed and processed, the proposal has no unaddressed objections
stated here or on the activation pull request. A growing list of people
has expressed explicit support for activating BIP 3 by leaving an ACK on
the pull request after reviewing the BIP:
https://github.com/bitcoin/bips/pull/1820#issue-2990155954
I formally propose a motion to adopt BIP 3 to replace BIP 2 as our BIPs
Process.
Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I
suggest that people who wish to state their support leave an ACK on
#1820 or reply in this thread. Similarly, I would like to invite anyone
to state concerns or raise objections here or on #1820.
While BIP 3 has long been proposed and the activation PR has been open
for over half a year, I suggest that we give all would-be reviewers
another four weeks, until 2025-12-02, before evaluating whether there is
rough consensus for merging the activation pull request. This should be
ample time to review and discuss BIP 3 as well as the activation PR,
even for people that have so far not engaged with the material.
Best,
Murch
----
Summary of changes since BIP 3 was advanced to Proposed:
- The License header now uses SPDX License Expressions²
- The License-Code header was dropped in favor of requiring that the
license terms of the auxiliary files be specified in the respective
directory or folder per a license header or LICENSE file²
- The “Created” header has been renamed to “Assigned”³
- The BIP text has been improved to clarify:
- the purpose of the BIPs repository⁴
- that authors should establish viability of their proposal on the
mailing list⁴
- the distinction between publication, acceptance, and adoption of
proposals⁴
- when Draft BIPs can be closed due to not making progress⁴
- that BIPs submissions may not be generated by AI/LLM⁵
⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md
¹ https://github.com/bitcoin/bips/pull/1794
² https://github.com/bitcoin/bips/pull/1892
³ https://github.com/bitcoin/bips/pull/1970
⁴ https://github.com/bitcoin/bips/pull/1819
⁵ https://github.com/bitcoin/bips/pull/2006
--
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/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one.
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 Murch @ 2025-11-05 1:53 ` Ruben Somsen 2025-11-12 19:03 ` [bitcoindev] " Greg Sanders ` (5 subsequent siblings) 6 siblings, 0 replies; 31+ messages in thread From: Ruben Somsen @ 2025-11-05 1:53 UTC (permalink / raw) To: Murch; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 3919 bytes --] Murch, you did an excellent job writing this and taking everyone's feedback into account. I think it's a crystal clear step up and should be adopted. Thanks for all the hard work. Cheers, Ruben On Wed, Nov 5, 2025 at 2:11 AM Murch <murch@murch.one> wrote: > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced to > Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed objections > stated here or on the activation pull request. A growing list of people > has expressed explicit support for activating BIP 3 by leaving an ACK on > the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our BIPs > Process. > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite anyone > to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether there is > rough consensus for merging the activation pull request. This should be > ample time to review and discuss BIP 3 as well as the activation PR, > even for people that have so far not engaged with the material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 > > -- > 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/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one > . > -- 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/CAPv7TjYrLQ7__WBFMb5PB7mWCqbh-b8j6NedNL1e%3DjsG%3Da%2Bugg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 5635 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [bitcoindev] Re: Motion to Activate BIP 3 2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 Murch 2025-11-05 1:53 ` Ruben Somsen @ 2025-11-12 19:03 ` Greg Sanders 2025-11-13 0:23 ` Murch [not found] ` <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com> ` (4 subsequent siblings) 6 siblings, 1 reply; 31+ messages in thread From: Greg Sanders @ 2025-11-12 19:03 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3734 bytes --] Hello Murch, I really like the BIP, just have a question about the editor portion. The list of current editors are currently in the BIP text, which seems to imply that the list can be changed by the author himself only and would become "static" over time. Clearly support for changing has to continue as it goes to Deployed and beyond. Perhaps the text should be moved elsewhere? Best, Greg On Tuesday, November 4, 2025 at 8:11:39 PM UTC-5 Murch wrote: > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced to > Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed objections > stated here or on the activation pull request. A growing list of people > has expressed explicit support for activating BIP 3 by leaving an ACK on > the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our BIPs > Process. > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite anyone > to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether there is > rough consensus for merging the activation pull request. This should be > ample time to review and discuss BIP 3 as well as the activation PR, > even for people that have so far not engaged with the material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 > > -- 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/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 6671 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Re: Motion to Activate BIP 3 2025-11-12 19:03 ` [bitcoindev] " Greg Sanders @ 2025-11-13 0:23 ` Murch 2025-11-13 18:54 ` Greg Sanders 0 siblings, 1 reply; 31+ messages in thread From: Murch @ 2025-11-13 0:23 UTC (permalink / raw) To: bitcoindev Hey Greg, Two sections from BIP 3 stand out as relevant here, “BIP Ownership“ and “Deployed Process BIPs”. From “Fundamentals > BIP Ownership”: > “[…] As a BIP progresses through the workflow, it becomes increasingly co-owned by the Bitcoin community.” While Deployed BIPs are considered final and changes should be avoided, the section has a subsection that specifically addresses Process BIPs. From “Workflow > Progression through BIP Statuses > Deployed > Process BIPs”: > “A Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. A proposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least one month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. Deployed Process BIPs may be modified indefinitely as long as a proposed modification has rough consensus per the same criteria.” More specific rules supersede general rules, so this subsection on Process BIPs should hopefully clearly override the general description in “Deployed”. It follows from these two sections that the BIP Authors’ right to decide about changes to their BIP is moderated by the community interests. I would consider especially Process BIPs to be dominantly owned by the community rather than the Authors once they are Deployed. The quoted section states how they are modified — by proposing and discussing a modification on the mailing list, which is also a fitting summary of how we decided last year to add more BIP Editors. Additionally, the “Workflow > Transferring BIP Ownership” section makes it clear that other Owners could step up to replace Authors that have become unreachable. Pragmatically speaking, it seems obvious that the list of BIP Editors would be amended in the currently active BIP Process Specification whenever the active BIP Editors change. Historically, this worked fine when Editors changed while BIP 1 and BIP 2 were active which both also specified the current BIP Editors in the same manner. Thank you for your review. Please let me know, if you think we should amend BIP 3 to more clearly state any of the above discussed thoughts. Best, Murch On 2025-11-12 11:03, Greg Sanders wrote: > Hello Murch, > > I really like the BIP, just have a question about the editor portion. > > The list of current editors are currently in the BIP text, which seems > to imply that the list can be changed by the author himself only and > would become "static" over time. > > Clearly support for changing has to continue as it goes to Deployed > and beyond. Perhaps the text should be moved elsewhere? > > Best, > Greg > > On Tuesday, November 4, 2025 at 8:11:39 PM UTC-5 Murch wrote: > > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was > advanced to > Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has > been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed > objections > stated here or on the activation pull request. A growing list of > people > has expressed explicit support for activating BIP 3 by leaving an > ACK on > the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our > BIPs > Process. > > Since BIP 2 doesn’t specify a procedure for activating Process > BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite > anyone > to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been > open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether > there is > rough consensus for merging the activation pull request. This > should be > ample time to review and discuss BIP 3 as well as the activation PR, > even for people that have so far not engaged with the material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 > > -- > 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/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.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/0ed80dd1-35ba-4f10-8aac-1069c6050380%40murch.one. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Re: Motion to Activate BIP 3 2025-11-13 0:23 ` Murch @ 2025-11-13 18:54 ` Greg Sanders 0 siblings, 0 replies; 31+ messages in thread From: Greg Sanders @ 2025-11-13 18:54 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 7475 bytes --] Makes sense to me, and this e-mail can be a reference point if there's future discussion. With what little review I've done, I think this makes sense to activate! Greg On Wednesday, November 12, 2025 at 7:30:59 PM UTC-5 Murch wrote: > Hey Greg, > > Two sections from BIP 3 stand out as relevant here, “BIP Ownership“ and > “Deployed Process BIPs”. > > From “Fundamentals > BIP Ownership”: > > “[…] As a BIP progresses through the workflow, it becomes > increasingly co-owned by the Bitcoin community.” > > While Deployed BIPs are considered final and changes should be avoided, > the section has a subsection that specifically addresses Process BIPs. > > From “Workflow > Progression through BIP Statuses > Deployed > Process > BIPs”: > > “A Process BIP may change status from Complete to Deployed when it > achieves rough consensus on the Bitcoin Development Mailing List. A > proposal is said to have rough consensus if its advancement has been > open to discussion on the mailing list for at least one month, the > discussion achieved meaningful engagement, and no person maintains any > unaddressed substantiated objections to it. Addressed or obstructive > objections may be ignored/overruled by general agreement that they have > been sufficiently addressed, but clear reasoning must be given in such > circumstances. Deployed Process BIPs may be modified indefinitely as > long as a proposed modification has rough consensus per the same criteria.” > > More specific rules supersede general rules, so this subsection on > Process BIPs should hopefully clearly override the general description > in “Deployed”. It follows from these two sections that the BIP Authors’ > right to decide about changes to their BIP is moderated by the community > interests. I would consider especially Process BIPs to be dominantly > owned by the community rather than the Authors once they are Deployed. > The quoted section states how they are modified — by proposing and > discussing a modification on the mailing list, which is also a > fitting summary of how we decided last year to add more BIP Editors. > > Additionally, the “Workflow > Transferring BIP Ownership” section makes > it clear that other Owners could step up to replace Authors that have > become unreachable. > > Pragmatically speaking, it seems obvious that the list of BIP Editors > would be amended in the currently active BIP Process Specification > whenever the active BIP Editors change. Historically, this worked fine > when Editors changed while BIP 1 and BIP 2 were active which both also > specified the current BIP Editors in the same manner. > > Thank you for your review. Please let me know, if you think we should > amend BIP 3 to more clearly state any of the above discussed thoughts. > > Best, > Murch > > On 2025-11-12 11:03, Greg Sanders wrote: > > Hello Murch, > > > > I really like the BIP, just have a question about the editor portion. > > > > The list of current editors are currently in the BIP text, which seems > > to imply that the list can be changed by the author himself only and > > would become "static" over time. > > > > Clearly support for changing has to continue as it goes to Deployed > > and beyond. Perhaps the text should be moved elsewhere? > > > > Best, > > Greg > > > > On Tuesday, November 4, 2025 at 8:11:39 PM UTC-5 Murch wrote: > > > > Dear list, > > > > After planned work on BIP 3⁰ finished in February, BIP 3 was > > advanced to > > Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > > since then (see below). I have since April maintained a pull request > > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > > > At this point, BIP 3 has received over 600 comments on GitHub and has > > been discussed in multiple threads on this list. The proposal has > > been > > Proposed for over seven months, and while several minor improvements > > were proposed and processed, the proposal has no unaddressed > > objections > > stated here or on the activation pull request. A growing list of > > people > > has expressed explicit support for activating BIP 3 by leaving an > > ACK on > > the pull request after reviewing the BIP: > > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our > > BIPs > > Process. > > > > Since BIP 2 doesn’t specify a procedure for activating Process > > BIPs, I > > suggest that people who wish to state their support leave an ACK on > > #1820 or reply in this thread. Similarly, I would like to invite > > anyone > > to state concerns or raise objections here or on #1820. > > While BIP 3 has long been proposed and the activation PR has been > > open > > for over half a year, I suggest that we give all would-be reviewers > > another four weeks, until 2025-12-02, before evaluating whether > > there is > > rough consensus for merging the activation pull request. This > > should be > > ample time to review and discuss BIP 3 as well as the activation PR, > > even for people that have so far not engaged with the material. > > > > Best, > > Murch > > > > ---- > > > > Summary of changes since BIP 3 was advanced to Proposed: > > > > - The License header now uses SPDX License Expressions² > > - The License-Code header was dropped in favor of requiring that the > > license terms of the auxiliary files be specified in the respective > > directory or folder per a license header or LICENSE file² > > - The “Created” header has been renamed to “Assigned”³ > > - The BIP text has been improved to clarify: > > - the purpose of the BIPs repository⁴ > > - that authors should establish viability of their proposal on the > > mailing list⁴ > > - the distinction between publication, acceptance, and adoption of > > proposals⁴ > > - when Draft BIPs can be closed due to not making progress⁴ > > - that BIPs submissions may not be generated by AI/LLM⁵ > > > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > > ¹ https://github.com/bitcoin/bips/pull/1794 > > ² https://github.com/bitcoin/bips/pull/1892 > > ³ https://github.com/bitcoin/bips/pull/1970 > > ⁴ https://github.com/bitcoin/bips/pull/1819 > > ⁵ https://github.com/bitcoin/bips/pull/2006 > > > > -- > > 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/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.com > > < > https://groups.google.com/d/msgid/bitcoindev/b1771bde-7fbc-4fa3-8151-9259c49f7c97n%40googlegroups.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/899eb548-3e3b-4b85-8ae0-1e64d15f1b86n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 11991 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com>]
* Re: [bitcoindev] Motion to Activate BIP 3 [not found] ` <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com> @ 2025-11-13 19:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List 0 siblings, 0 replies; 31+ messages in thread From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-11-13 19:35 UTC (permalink / raw) To: Bitcoin Development Mailing List Forwarding my reply to Murch on November 4th, which for some reason i did not also send to the list at the time. ------- Forwarded Message ------- From: Antoine Poinsot <darosior@protonmail.com> Date: On Tuesday, November 4th, 2025 at 9:58 PM Subject: Re: [bitcoindev] Motion to Activate BIP 3 To: Murch <murch@murch.one> > > > Murch, > > I am in favour of activating BIP 3. Your proposed timeline seems appropriate to me. > > Thanks for your sustained efforts in leading this forward. > > Best, > Antoine Poinsot > > -------- Original Message -------- > On Tuesday, 11/04/25 at 20:11 Murch murch@murch.one wrote: > > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced to > Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed objections > stated here or on the activation pull request. A growing list of people > has expressed explicit support for activating BIP 3 by leaving an ACK on > the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our BIPs > Process. > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite anyone > to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether there is > rough consensus for merging the activation pull request. This should be > ample time to review and discuss BIP 3 as well as the activation PR, > even for people that have so far not engaged with the material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 > > -- > 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/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one. -- 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/DMVHnNhEbYjvd5J1XrUdVaal10POhNpOqGl1ZR3a3Eis1qnQblrYFdH1QhNTJ95dKFs9tcK-yOvbaMj12vwik5WYH0_W_1d9gdz77H-PFi8%3D%40protonmail.com. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 Murch ` (2 preceding siblings ...) [not found] ` <Qe_CRlsuwalN-0a0oo1KcZ265rXevTeHaTdk6IifH-j7NbLMew7-ucLLMiwECQLZEPoU2pm-PAuwb_lZAeCU9vChaVYTZzl60N9jyPTnUbo=@protonmail.com> @ 2025-11-13 21:43 ` Murch 2025-11-14 17:05 ` Melvin Carvalho ` (2 subsequent siblings) 6 siblings, 0 replies; 31+ messages in thread From: Murch @ 2025-11-13 21:43 UTC (permalink / raw) To: bitcoindev Dear list, I would like to correct a small lapse I made in my email from November 4th. I mistakenly thought that the activation process for Process BIPs was newly introduced with BIP 3, but reading BIP 2 again today, I realized that it had been adapted from BIP 2. BIP 2 says: > A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. Meaning, that I was incorrect when I stated that “BIP 2 doesn’t specify a procedure for activating Process BIPs”. My apologies. Either way, the previously proposed motion to activate complies with BIP 2, so I don’t think there is a need to revise the approach. Cheers, Murch On 2025-11-04 17:10, Murch wrote: > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced > to Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed > objections stated here or on the activation pull request. A growing > list of people has expressed explicit support for activating BIP 3 by > leaving an ACK on the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our > BIPs Process. > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite > anyone to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether there > is rough consensus for merging the activation pull request. This > should be ample time to review and discuss BIP 3 as well as the > activation PR, even for people that have so far not engaged with the > material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 > -- 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/8aadd6bd-1cf4-4ba3-a1ab-f30ab06c89b9%40murch.one. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 Murch ` (3 preceding siblings ...) 2025-11-13 21:43 ` Murch @ 2025-11-14 17:05 ` Melvin Carvalho 2025-11-22 23:46 ` Murch 2025-11-15 22:01 ` Luke Dashjr 2025-11-18 15:47 ` David A. Harding 6 siblings, 1 reply; 31+ messages in thread From: Melvin Carvalho @ 2025-11-14 17:05 UTC (permalink / raw) To: Murch; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 7669 bytes --] st 5. 11. 2025 v 2:11 odesílatel Murch <murch@murch.one> napsal: > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced to > Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed objections > stated here or on the activation pull request. A growing list of people > has expressed explicit support for activating BIP 3 by leaving an ACK on > the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our BIPs > Process. > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite anyone > to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether there is > rough consensus for merging the activation pull request. This should be > ample time to review and discuss BIP 3 as well as the activation PR, > even for people that have so far not engaged with the material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 Hi all, I'm writing in response to Murch's motion to activate BIP 3. I appreciate both the extensive work that's gone into this proposal and the invitation to raise concerns during this evaluation period. Since BIP 3 cites RFC 7282 as its rough consensus framework, I reviewed it with that standard in mind. BIP 3 modernizes many aspects of the process, particularly the streamlined status flow and clearer role definitions, and I appreciate these improvements. I've spent some time in IETF and W3C processes over the years, including recommending RFC 7282 to this list during the Taproot discussions, so some of the thoughts below reflect lessons learned from those environments. That said, Bitcoin's governance context is unique, and I may be missing important considerations. *1. RFC 7282: visible objection handling* RFC 7282 emphasizes that rough consensus is demonstrated by documenting objections and how they were addressed. Process BIPs under BIP 3 can self-modify without requiring such a log, which leaves ambiguity around how consensus is determined. A short objections/resolution record, even as simple as a changelog section noting “Objection raised by X regarding Y; addressed by Z”, would address this and provide helpful context for future readers. *2. RFC 7282: neutral consensus evaluation* RFC 7282 discourages authors from judging consensus on their own work. Under BIP 3, a small editor group collectively evaluates numbering, closure, "material progress," "lack of interest," and rough consensus itself. This concentration of authority may create perceived conflicts of interest, even with the best intentions. A minimal safeguard would be requiring two non-author editors, ideally from different implementation communities such as Core and Knots, to confirm rough consensus for Process BIPs. This shares responsibility and provides independent verification. For example, if a Process BIP proposes changing the Draft-to-Complete threshold, this would ensure independent assessment. *3. Subjectivity in number assignment* Declining numbers due to "lack of interest" or "insufficient progress" is reasonable in intent but subjective in effect. A brief explanation, even a single sentence in the PR, would help newcomers understand expectations and provide editors with a neutral reference point if a decision is later questioned. *4. Status compression and historical clarity* Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies the system but loses useful distinctions that help readers understand why a proposal didn't advance. Optional status annotations (e.g., "Closed (Withdrawn by author)" or "Closed (Superseded by BIP X)") could preserve this context without complicating the core status model. *Lightweight adjustments for RFC alignment and neutrality* - Short objections/resolution log for Process BIPs (can be minimal changelog format) - Neutral consensus verification by two non-author editors, preferably cross-ecosystem - Brief explanations for number denials and "stalled" Draft BIPs - Optional annotations for Closed statuses to preserve historical context These small additions strengthen neutrality and transparency. They also help editors by distributing responsibility and making decisions easier to defend through a clear paper trail. I recognize editors are volunteering substantial time, and these mechanisms are intended to make the role more sustainable, not more burdensome. I may have overlooked important practical constraints or misunderstood parts of the current process. I'd be interested to hear whether others see value in these additions, have alternative approaches to strengthening neutrality around Process BIPs, or believe the current design better serves Bitcoin's governance needs. Looking forward to the discussion. Best, Melvin > > > -- > 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/205b3532-ccc1-4b2f-964f-264fc6e0e70b%40murch.one > . > -- 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/CAKaEYh%2BFHr8wQd41Hh0CW76F25Vuo0b7uQ1JE1TdEkisFGM9wg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 9789 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-14 17:05 ` Melvin Carvalho @ 2025-11-22 23:46 ` Murch 2025-11-29 23:00 ` Melvin Carvalho 0 siblings, 1 reply; 31+ messages in thread From: Murch @ 2025-11-22 23:46 UTC (permalink / raw) To: bitcoindev Hi Melvin, Thank you for your sharing your thoughts. On 2025-11-14 09:05, Melvin Carvalho wrote: > Since BIP 3 cites RFC 7282 as its rough consensus framework I am not sure how you got this impression. RFC 7282 is only mentioned once, in the related work section. BIP 3’s section mentioning rough consensus also defines the term in the context of BIP 3. Specifically, the _Process BIPs_ section¹ states: “A proposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least one month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.” ¹ https://github.com/bitcoin/bips/blob/master/bip-0003.md#process-bips On 2025-11-14 09:05, Melvin Carvalho wrote: > *1. RFC 7282: visible objection handling* > > RFC 7282 emphasizes that rough consensus is demonstrated by > documenting objections and how they were addressed. Process BIPs > under BIP 3 can self-modify without requiring such a log, which > leaves ambiguity around how consensus is determined. A short > objections/resolution record, even as simple as a changelog section > noting “Objection raised by X regarding Y; addressed by Z”, would > address this and provide helpful context for future readers. The section mentioned above continues to clarify the mechanism for modifying Process BIPs: > “Deployed Process BIPs may be modified indefinitely as long as a > proposed modification has rough consensus per the same criteria.” Further, BIP 3 introduces a Changelog section which requires recording changes to a BIP after it has reached the Complete status (which also applies for the Deployed status). Therefore, I disagree with your interpretations: - RFC 7282 is not used by BIP 3, it is cited as an inspiration. - Deployed Process BIPs cannot be modified without a public record, as modifications have to be discussed on the mailing list, and the changes need to be recorded in the Changelog section. - Objections have been addressed per the footnotes in the Rationale section, as required by the description of the Rationale section. Even while they don’t take your proposed format exactly. While technically it is not required, because BIP 3 is not active yet, I posit that it would be good to add a Changelog section to BIP 3 that reiterates the noteworthy changes I described in my prior emails. On 2025-11-14 09:05, Melvin Carvalho wrote: > *2. RFC 7282: neutral consensus evaluation* > > RFC 7282 discourages authors from judging consensus on their own > work. Under BIP 3, a small editor group collectively evaluates > numbering, closure, "material progress," "lack of interest," and > rough consensus itself. This concentration of authority may create > perceived conflicts of interest, even with the best intentions. > > A minimal safeguard would be requiring two non-author editors, > ideally from different implementation communities such as Core and > Knots, to confirm rough consensus for Process BIPs. This shares > responsibility and provides independent verification. For example, > if a Process BIP proposes changing the Draft-to-Complete threshold, > this would ensure independent assessment. It seems reasonable to me that authors recuse themselves from judging whether consensus has been reached for their own BIP. Luckily, there are currently six BIP Editors and I’m the sole author of BIP 3. I am skeptical of introducing rules for hypothetical issues that have not been problems in the past, especially when those rules would cause the BIP Process to grind to a halt should the Editor count should fall back to the levels that were normal for its entire history except the recent past. If you would like to propose a concrete change to the BIP text, I’d be happy to comment on that concretely. On 2025-11-14 09:05, Melvin Carvalho wrote: > *3. Subjectivity in number assignment* > > Declining numbers due to "lack of interest" or "insufficient > progress" is reasonable in intent but subjective in effect. A brief > explanation, even a single sentence in the PR, would help newcomers > understand expectations and provide editors with a neutral reference > point if a decision is later questioned. While an express goal for BIP 3 was to reduce judgement calls by the BIP Editors in the BIP Process, the BIP Process does inherently require some judgement calls to fulfill its function of surfacing relevant documents. It is my understanding that the BIP Editors are entrusted by the community to make these judgement calls for the benefit of the entire audience of the BIPs Repository while adhering to the spirit of the active BIPs Process. Concretely, the _BIP Editor Responsibilities and Workflow_ section² states: > “If the BIP needs more work, an editor should ensure that > constructive, actionable feedback is provided to the authors for > revision.” and the README states: > “We are fairly liberal with approving BIPs, and try not to be too > involved in decision making on behalf of the community. The > exception is in very rare cases of dispute resolution when a > decision is contentious and cannot be agreed upon. In those cases, > the conservative option will always be preferred.” Further, the entire work is happening in public via the mailing list and pull requests to the BIPs repository. If any announced decisions are unclear, controversial, or taking longer than expected, nothing prevents participants from seeking clarification. I would also like to reiterate that a BIP being published does not guarantee or imply adoption ² https://github.com/bitcoin/bips/blob/master/bip-0003.md#bip-editor- responsibilities-and-workflow On 2025-11-14 09:05, Melvin Carvalho wrote: > *4. Status compression and historical clarity* > > Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies the > system but loses useful distinctions that help readers understand > why a proposal didn't advance. Optional status annotations (e.g., > "Closed (Withdrawn by author)" or "Closed (Superseded by BIP X)") > could preserve this context without complicating the core status > model. The Closed status indicates that “a BIP that is of historical interest only, and is not being actively worked on, promoted or in active use”.³ The simplification of reducing the count of statuses is an explicit design decision of BIP 3 that is explained in detail in the Backward Compatibility and Rationale sections. My stance is that the Closed status provides sufficient information at the table overview level, and BIP 3 requires that the detailed reason for a BIP being set to Closed is recorded in the Changelog, where it is easily accessible to anyone that is interested in a specific BIP’s trajectory. Some of the sunset Statuses have in the past elicited pushback by Authors (especially Rejected and Deferred). Closed constitutes a more neutral term, and the Changelog allows a more nuanced description of the reasoning than single word Statuses. ³ https://github.com/bitcoin/bips/blob/master/bip-0003.md#closed11 On 2025-11-14 09:05, Melvin Carvalho wrote: > *Lightweight adjustments for RFC alignment and neutrality* > > * Short objections/resolution log for Process BIPs (can be minimal > changelog format) > > * Neutral consensus verification by two non-author editors, > preferably cross-ecosystem > > * Brief explanations for number denials and "stalled" Draft BIPs > > * Optional annotations for Closed statuses to preserve historical > context As covered above, it seems to me that all of these points are already sufficiently covered by the proposed BIP. - The Rationale⁴ already collects objections: > ”The rationale should record relevant objections or important > concerns that were raised and addressed as this proposal was developed.“- Changes to Process BIPs must be discussed in public, I’m not sure that additional regulation would translate to a further improvement rather than just more friction. - The process already requires Editors to provide “constructive, actionable feedback […] if a BIP needs more work”. - When a BIP is moved to Closed, it is required to record the reason in the Changelog. ⁴ https://github.com/bitcoin/bips/blob/master/bip-0003.md#specification On 2025-11-14 09:05, Melvin Carvalho wrote: > These small additions strengthen neutrality and transparency. They > also help editors by distributing responsibility and making decisions> easier to defend through a clear paper trail. I recognize editors > are volunteering substantial time, and these mechanisms are intended > to make the role more sustainable, not more burdensome. > > I may have overlooked important practical constraints or > misunderstood parts of the current process. I'd be interested to > hear whether others see value in these additions, have alternative > approaches to strengthening neutrality around Process BIPs, or > believe the current design better serves Bitcoin's governance needs. Between the BIPs Repository being an append-only record, all of the work happening in public in pull requests and on the mailing list, as well as per the requirements for the Rationale and Changelog sections, it seems to me that the proposed Process already provides plenty of paper trail. I would hope that if you gave BIP 3 and especially the Rationale section another read sans the notion that it relies on RFC 7282, you would find that your concerns are already addressed satisfactorily. Please let us know if this is not the case. Best, Murch -- 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/fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-22 23:46 ` Murch @ 2025-11-29 23:00 ` Melvin Carvalho 2025-12-02 0:29 ` Murch 0 siblings, 1 reply; 31+ messages in thread From: Melvin Carvalho @ 2025-11-29 23:00 UTC (permalink / raw) To: Murch; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 12392 bytes --] ne 23. 11. 2025 v 0:53 odesílatel Murch <murch@murch.one> napsal: > Hi Melvin, > > Thank you for your sharing your thoughts. > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > Since BIP 3 cites RFC 7282 as its rough consensus framework > > I am not sure how you got this impression. RFC 7282 is only mentioned > once, in the related work section. BIP 3’s section mentioning rough > consensus also defines the term in the context of BIP 3. Specifically, > the _Process BIPs_ section¹ states: > > “A proposal is said to have rough consensus if its advancement has been > open to discussion on the mailing list for at least one month, the > discussion achieved meaningful engagement, and no person maintains any > unaddressed substantiated objections to it. Addressed or obstructive > objections may be ignored/overruled by general agreement that they have > been sufficiently addressed, but clear reasoning must be given in such > circumstances.” > > ¹ https://github.com/bitcoin/bips/blob/master/bip-0003.md#process-bips > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *1. RFC 7282: visible objection handling* > > > > RFC 7282 emphasizes that rough consensus is demonstrated by > > documenting objections and how they were addressed. Process BIPs > > under BIP 3 can self-modify without requiring such a log, which > > leaves ambiguity around how consensus is determined. A short > > objections/resolution record, even as simple as a changelog section > > noting “Objection raised by X regarding Y; addressed by Z”, would > > address this and provide helpful context for future readers. > > The section mentioned above continues to clarify the mechanism for > modifying Process BIPs: > > “Deployed Process BIPs may be modified indefinitely as long as a > > proposed modification has rough consensus per the same criteria.” > > Further, BIP 3 introduces a Changelog section which requires recording > changes to a BIP after it has reached the Complete status (which also > applies for the Deployed status). > > Therefore, I disagree with your interpretations: > - RFC 7282 is not used by BIP 3, it is cited as an inspiration. > - Deployed Process BIPs cannot be modified without a public record, as > modifications have to be discussed on the mailing list, and the changes > need to be recorded in the Changelog section. > - Objections have been addressed per the footnotes in the Rationale > section, as required by the description of the Rationale section. Even > while they don’t take your proposed format exactly. > > While technically it is not required, because BIP 3 is not active yet, > I posit that it would be good to add a Changelog section to BIP 3 that > reiterates the noteworthy changes I described in my prior emails. > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *2. RFC 7282: neutral consensus evaluation* > > > > RFC 7282 discourages authors from judging consensus on their own > > work. Under BIP 3, a small editor group collectively evaluates > > numbering, closure, "material progress," "lack of interest," and > > rough consensus itself. This concentration of authority may create > > perceived conflicts of interest, even with the best intentions. > > > > A minimal safeguard would be requiring two non-author editors, > > ideally from different implementation communities such as Core and > > Knots, to confirm rough consensus for Process BIPs. This shares > > responsibility and provides independent verification. For example, > > if a Process BIP proposes changing the Draft-to-Complete threshold, > > this would ensure independent assessment. > > It seems reasonable to me that authors recuse themselves from judging > whether consensus has been reached for their own BIP. Luckily, there are > currently six BIP Editors and I’m the sole author of BIP 3. I am > skeptical of introducing rules for hypothetical issues that have not > been problems in the past, especially when those rules would cause the > BIP Process to grind to a halt should the Editor count should fall back > to the levels that were normal for its entire history except the recent > past. If you would like to propose a concrete change to the BIP text, > I’d be happy to comment on that concretely. > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *3. Subjectivity in number assignment* > > > > Declining numbers due to "lack of interest" or "insufficient > > progress" is reasonable in intent but subjective in effect. A brief > > explanation, even a single sentence in the PR, would help newcomers > > understand expectations and provide editors with a neutral reference > > point if a decision is later questioned. > > While an express goal for BIP 3 was to reduce judgement calls by the BIP > Editors in the BIP Process, the BIP Process does inherently require some > judgement calls to fulfill its function of surfacing relevant documents. > It is my understanding that the BIP Editors are entrusted by the > community to make these judgement calls for the benefit of the entire > audience of the BIPs Repository while adhering to the spirit of the > active BIPs Process. Concretely, the _BIP Editor Responsibilities and > Workflow_ section² states: > > > “If the BIP needs more work, an editor should ensure that > > constructive, actionable feedback is provided to the authors for > > revision.” > > and the README states: > > > “We are fairly liberal with approving BIPs, and try not to be too > > involved in decision making on behalf of the community. The > > exception is in very rare cases of dispute resolution when a > > decision is contentious and cannot be agreed upon. In those cases, > > the conservative option will always be preferred.” > > Further, the entire work is happening in public via the mailing list and > pull requests to the BIPs repository. If any announced decisions are > unclear, controversial, or taking longer than expected, nothing prevents > participants from seeking clarification. I would also like to reiterate > that a BIP being published does not guarantee or imply adoption > > ² https://github.com/bitcoin/bips/blob/master/bip-0003.md#bip-editor- > responsibilities-and-workflow > <https://github.com/bitcoin/bips/blob/master/bip-0003.md#bip-editor-responsibilities-and-workflow> > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *4. Status compression and historical clarity* > > > > Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies the > > system but loses useful distinctions that help readers understand > > why a proposal didn't advance. Optional status annotations (e.g., > > "Closed (Withdrawn by author)" or "Closed (Superseded by BIP X)") > > could preserve this context without complicating the core status > > model. > > The Closed status indicates that “a BIP that is of historical interest > only, and is not being actively worked on, promoted or in active use”.³ > The simplification of reducing the count of statuses is an explicit > design decision of BIP 3 that is explained in detail in the Backward > Compatibility and Rationale sections. My stance is that the Closed > status provides sufficient information at the table overview level, and > BIP 3 requires that the detailed reason for a BIP being set to Closed is > recorded in the Changelog, where it is easily accessible to anyone that > is interested in a specific BIP’s trajectory. > Some of the sunset Statuses have in the past elicited pushback by > Authors (especially Rejected and Deferred). Closed constitutes a more > neutral term, and the Changelog allows a more nuanced description of the > reasoning than single word Statuses. > > ³ https://github.com/bitcoin/bips/blob/master/bip-0003.md#closed11 > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *Lightweight adjustments for RFC alignment and neutrality* > > > > * Short objections/resolution log for Process BIPs (can be minimal > > changelog format) > > > > * Neutral consensus verification by two non-author editors, > > preferably cross-ecosystem > > > > * Brief explanations for number denials and "stalled" Draft BIPs > > > > * Optional annotations for Closed statuses to preserve historical > > context > > As covered above, it seems to me that all of these points are already > sufficiently covered by the proposed BIP. > - The Rationale⁴ already collects objections: > > ”The rationale should record relevant objections or important > > concerns that were raised and addressed as this proposal was > developed.“- Changes to Process BIPs must be discussed in public, I’m not > sure that > additional regulation would translate to a further improvement rather > than just more friction. > - The process already requires Editors to provide “constructive, > actionable feedback […] if a BIP needs more work”. > - When a BIP is moved to Closed, it is required to record the reason in > the Changelog. > > ⁴ https://github.com/bitcoin/bips/blob/master/bip-0003.md#specification > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > These small additions strengthen neutrality and transparency. They > > also help editors by distributing responsibility and making > decisions> easier to defend through a clear paper trail. I recognize > editors > > are volunteering substantial time, and these mechanisms are intended > > to make the role more sustainable, not more burdensome. > > > > I may have overlooked important practical constraints or > > misunderstood parts of the current process. I'd be interested to > > hear whether others see value in these additions, have alternative > > approaches to strengthening neutrality around Process BIPs, or > > believe the current design better serves Bitcoin's governance needs. > Between the BIPs Repository being an append-only record, all of the work > happening in public in pull requests and on the mailing list, as well as > per the requirements for the Rationale and Changelog sections, it seems > to me that the proposed Process already provides plenty of paper trail. > I would hope that if you gave BIP 3 and especially the Rationale section > another read sans the notion that it relies on RFC 7282, you would > find that your concerns are already addressed satisfactorily. Please let > us know if this is not the case. > Hi Murch, Thank you for the reply. I've followed the subsequent discussion with interest, Tim and Pieter's points on the AI provisions seem well-taken. I want to briefly restate my concern for the record. BIP 3 defines how Process BIPs achieve rough consensus, and the author of BIP 3 is evaluating whether that consensus exists. RFC 7282, the seminal IETF document on rough consensus that BIP 3 cites as related work, specifically cautions against this kind of overlap. Whether adopted formally or not, the reasoning applies. My suggestion: require that rough consensus for Process BIPs be confirmed by at least two non-author editors, ideally from different implementation ecosystems. This is a small structural safeguard that strengthens legitimacy and, importantly, distributes responsibility, protecting editors from being placed in an awkward position when evaluating contentious proposals. I also note that PR #2037 proposes several significant edits to BIP 3's scope and mechanics, which suggests there is still active disagreement on some important details. Best, Melvin > > Best, > Murch > > -- > 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/fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one > . > -- 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/CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 14531 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-29 23:00 ` Melvin Carvalho @ 2025-12-02 0:29 ` Murch 0 siblings, 0 replies; 31+ messages in thread From: Murch @ 2025-12-02 0:29 UTC (permalink / raw) To: bitcoindev Hello Melvin, Thanks for restating your previous suggestion. It’s not clear to me why you think that I would be making the call by myself whether there is rough consensus. In my original email, I wrote: “we give all would-be reviewers another four weeks, … before evaluating whether there is rough consensus”. The pertinent subject of the sentence being “we”. As I pointed out in my prior email, we never had more than two BIP Editors until last April. Requiring the existence of two non-author BIP Editors to make changes to Process BIPs would mean that we would not even have been able to add more BIP Editors under historically normal Editor counts. I was not planning on making the call whether there is rough consensus to activate BIP 3 anyway, but I’m still not convinced it’s a good idea to generally adopt the criteria you propose. Murch On 2025-11-29 15:00, Melvin Carvalho wrote: > > > ne 23. 11. 2025 v 0:53 odesílatel Murch <murch@murch.one> napsal: > > Hi Melvin, > > Thank you for your sharing your thoughts. > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > Since BIP 3 cites RFC 7282 as its rough consensus framework > > I am not sure how you got this impression. RFC 7282 is only mentioned > once, in the related work section. BIP 3’s section mentioning rough > consensus also defines the term in the context of BIP 3. Specifically, > the _Process BIPs_ section¹ states: > > “A proposal is said to have rough consensus if its advancement has been > open to discussion on the mailing list for at least one month, the > discussion achieved meaningful engagement, and no person maintains any > unaddressed substantiated objections to it. Addressed or obstructive > objections may be ignored/overruled by general agreement that they have > been sufficiently addressed, but clear reasoning must be given in such > circumstances.” > > ¹ https://github.com/bitcoin/bips/blob/master/bip-0003.md#process- > bips <https://github.com/bitcoin/bips/blob/master/ > bip-0003.md#process-bips> > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *1. RFC 7282: visible objection handling* > > > > RFC 7282 emphasizes that rough consensus is demonstrated by > > documenting objections and how they were addressed. Process BIPs > > under BIP 3 can self-modify without requiring such a log, which > > leaves ambiguity around how consensus is determined. A short > > objections/resolution record, even as simple as a changelog section > > noting “Objection raised by X regarding Y; addressed by Z”, would > > address this and provide helpful context for future readers. > > The section mentioned above continues to clarify the mechanism for > modifying Process BIPs: > > “Deployed Process BIPs may be modified indefinitely as long as a > > proposed modification has rough consensus per the same criteria.” > > Further, BIP 3 introduces a Changelog section which requires recording > changes to a BIP after it has reached the Complete status (which also > applies for the Deployed status). > > Therefore, I disagree with your interpretations: > - RFC 7282 is not used by BIP 3, it is cited as an inspiration. > - Deployed Process BIPs cannot be modified without a public record, as > modifications have to be discussed on the mailing list, and the changes > need to be recorded in the Changelog section. > - Objections have been addressed per the footnotes in the Rationale > section, as required by the description of the Rationale section. Even > while they don’t take your proposed format exactly. > > While technically it is not required, because BIP 3 is not active yet, > I posit that it would be good to add a Changelog section to BIP 3 that > reiterates the noteworthy changes I described in my prior emails. > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *2. RFC 7282: neutral consensus evaluation* > > > > RFC 7282 discourages authors from judging consensus on their own > > work. Under BIP 3, a small editor group collectively evaluates > > numbering, closure, "material progress," "lack of interest," and > > rough consensus itself. This concentration of authority may create > > perceived conflicts of interest, even with the best intentions. > > > > A minimal safeguard would be requiring two non-author editors, > > ideally from different implementation communities such as Core and > > Knots, to confirm rough consensus for Process BIPs. This shares > > responsibility and provides independent verification. For example, > > if a Process BIP proposes changing the Draft-to-Complete threshold, > > this would ensure independent assessment. > > It seems reasonable to me that authors recuse themselves from judging > whether consensus has been reached for their own BIP. Luckily, there are > currently six BIP Editors and I’m the sole author of BIP 3. I am > skeptical of introducing rules for hypothetical issues that have not > been problems in the past, especially when those rules would cause the > BIP Process to grind to a halt should the Editor count should fall back > to the levels that were normal for its entire history except the recent > past. If you would like to propose a concrete change to the BIP text, > I’d be happy to comment on that concretely. > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *3. Subjectivity in number assignment* > > > > Declining numbers due to "lack of interest" or "insufficient > > progress" is reasonable in intent but subjective in effect. A brief > > explanation, even a single sentence in the PR, would help newcomers > > understand expectations and provide editors with a neutral reference > > point if a decision is later questioned. > > While an express goal for BIP 3 was to reduce judgement calls by the BIP > Editors in the BIP Process, the BIP Process does inherently require some > judgement calls to fulfill its function of surfacing relevant > documents. > It is my understanding that the BIP Editors are entrusted by the > community to make these judgement calls for the benefit of the entire > audience of the BIPs Repository while adhering to the spirit of the > active BIPs Process. Concretely, the _BIP Editor Responsibilities and > Workflow_ section² states: > > > “If the BIP needs more work, an editor should ensure that > > constructive, actionable feedback is provided to the authors for > > revision.” > > and the README states: > > > “We are fairly liberal with approving BIPs, and try not to be too > > involved in decision making on behalf of the community. The > > exception is in very rare cases of dispute resolution when a > > decision is contentious and cannot be agreed upon. In those cases, > > the conservative option will always be preferred.” > > Further, the entire work is happening in public via the mailing list and > pull requests to the BIPs repository. If any announced decisions are > unclear, controversial, or taking longer than expected, nothing prevents > participants from seeking clarification. I would also like to reiterate > that a BIP being published does not guarantee or imply adoption > > ² https://github.com/bitcoin/bips/blob/master/bip-0003.md#bip-editor- > responsibilities-and-workflow <https://github.com/bitcoin/bips/blob/ > master/bip-0003.md#bip-editor-responsibilities-and-workflow> > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *4. Status compression and historical clarity* > > > > Collapsing Rejected/Withdrawn/Obsolete into "Closed" simplifies the > > system but loses useful distinctions that help readers understand > > why a proposal didn't advance. Optional status annotations (e.g., > > "Closed (Withdrawn by author)" or "Closed (Superseded by BIP X)") > > could preserve this context without complicating the core status > > model. > > The Closed status indicates that “a BIP that is of historical interest > only, and is not being actively worked on, promoted or in active use”.³ > The simplification of reducing the count of statuses is an explicit > design decision of BIP 3 that is explained in detail in the Backward > Compatibility and Rationale sections. My stance is that the Closed > status provides sufficient information at the table overview level, and > BIP 3 requires that the detailed reason for a BIP being set to Closed is > recorded in the Changelog, where it is easily accessible to anyone that > is interested in a specific BIP’s trajectory. > Some of the sunset Statuses have in the past elicited pushback by > Authors (especially Rejected and Deferred). Closed constitutes a more > neutral term, and the Changelog allows a more nuanced description of the > reasoning than single word Statuses. > > ³ https://github.com/bitcoin/bips/blob/master/bip-0003.md#closed11 > <https://github.com/bitcoin/bips/blob/master/bip-0003.md#closed11> > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > *Lightweight adjustments for RFC alignment and neutrality* > > > > * Short objections/resolution log for Process BIPs (can be minimal > > changelog format) > > > > * Neutral consensus verification by two non-author editors, > > preferably cross-ecosystem > > > > * Brief explanations for number denials and "stalled" Draft BIPs > > > > * Optional annotations for Closed statuses to preserve historical > > context > > As covered above, it seems to me that all of these points are already > sufficiently covered by the proposed BIP. > - The Rationale⁴ already collects objections: > > ”The rationale should record relevant objections or important > > concerns that were raised and addressed as this proposal was > developed.“- Changes to Process BIPs must be discussed in public, > I’m not sure that > additional regulation would translate to a further improvement rather > than just more friction. > - The process already requires Editors to provide “constructive, > actionable feedback […] if a BIP needs more work”. > - When a BIP is moved to Closed, it is required to record the reason in > the Changelog. > > ⁴ https://github.com/bitcoin/bips/blob/master/ > bip-0003.md#specification <https://github.com/bitcoin/bips/blob/ > master/bip-0003.md#specification> > > On 2025-11-14 09:05, Melvin Carvalho wrote: > > These small additions strengthen neutrality and transparency. They > > also help editors by distributing responsibility and making > decisions> easier to defend through a clear paper trail. I recognize > editors > > are volunteering substantial time, and these mechanisms are intended > > to make the role more sustainable, not more burdensome. > > > > I may have overlooked important practical constraints or > > misunderstood parts of the current process. I'd be interested to > > hear whether others see value in these additions, have alternative > > approaches to strengthening neutrality around Process BIPs, or > > believe the current design better serves Bitcoin's governance needs. > Between the BIPs Repository being an append-only record, all of the work > happening in public in pull requests and on the mailing list, as well as > per the requirements for the Rationale and Changelog sections, it seems > to me that the proposed Process already provides plenty of paper trail. > I would hope that if you gave BIP 3 and especially the Rationale section > another read sans the notion that it relies on RFC 7282, you would > find that your concerns are already addressed satisfactorily. Please let > us know if this is not the case. > > > Hi Murch, > > Thank you for the reply. I've followed the subsequent discussion with > interest, Tim and Pieter's points on the AI provisions seem well-taken. > > I want to briefly restate my concern for the record. > > BIP 3 defines how Process BIPs achieve rough consensus, and the author > of BIP 3 is evaluating whether that consensus exists. RFC 7282, the > seminal IETF document on rough consensus that BIP 3 cites as related > work, specifically cautions against this kind of overlap. Whether > adopted formally or not, the reasoning applies. > > My suggestion: require that rough consensus for Process BIPs be > confirmed by at least two non-author editors, ideally from different > implementation ecosystems. This is a small structural safeguard that > strengthens legitimacy and, importantly, distributes responsibility, > protecting editors from being placed in an awkward position when > evaluating contentious proposals. > > I also note that PR #2037 proposes several significant edits to BIP 3's > scope and mechanics, which suggests there is still active disagreement > on some important details. > > Best, > Melvin > > > Best, > Murch > > -- > 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 > <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>. > To view this discussion visit https://groups.google.com/d/msgid/ > bitcoindev/fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one > <https://groups.google.com/d/msgid/bitcoindev/ > fc4472a0-5d39-402e-84c8-07328b4dd893%40murch.one>. > > -- > 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 > <mailto:bitcoindev+unsubscribe@googlegroups.com>. > To view this discussion visit https://groups.google.com/d/msgid/ > bitcoindev/ > CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/ > CAKaEYh%2BL0NU8UYs32oai7NoCcqgbfmBSQjqS%3DdZG77e1kOB4Zw%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/ad6ccb6d-9845-4a04-82d4-c052306a2218%40murch.one. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 Murch ` (4 preceding siblings ...) 2025-11-14 17:05 ` Melvin Carvalho @ 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 6 siblings, 2 replies; 31+ messages in thread From: Luke Dashjr @ 2025-11-15 22:01 UTC (permalink / raw) To: bitcoindev I have completed my review of the current BIP 3 proposal, and opened PR #2037 to address these issues: * It misses that BIPs should be relevant to more than just one Bitcoin project. * AI/LLM usage disclosure is too much. As long as no content is LLM-generated, we should be fine. * Authors/Deputies assumes the champion (Author) was involved in writing the document. This is a deviation from the current process where the champion can be reassigned by editors if the current one is MIA. * Required sections lacks an actual content section (typically Specification). * Reference Implementation is probably too specific with aux file or PR requirement. One might conceive BIPs where the reference is an independent/new software repository, for example. * Editors have always been able to assign numbers for their own BIPs - that isn't considered self-assignment, and recent confusion in the community suggests this should be clarified. * The requirement for public discussion/feedback/interest is new, and inappropriate. While typically this may be the case, it should be possible to put forward BIPs without relying on other contributors. * Test vectors may not be applicable to all specification BIPs. * "Compliant" is often the wrong term, as BIPs are recommendations. "Compatible" seems more appropriate. * Avoid implying every BIP Editor must reply to every new idea sent to the ML * The recent addition of "proposed by one of the authors [to the ML]" is confusing and contradictory: it doesn't make sense to require the author to have initiated the discussion himself, and the person who did may not be interested in taking on the champion role (and may not be willing to cooperate with submitting it and subsequently trasferring it) * The Rationale stated lowercase "bitcoin" is used to refer to units of the currency, but no such reference is made, and instead it is only incorrectly used lowercase. All instances have been corrected to capitalized and the rationale entry removed. Additionally, I identified the following issues which may need further discussion to address: * It may make sense to replace "Authors" with "Champions"? * "co-owned by the Bitcoin community" seems like a good idea abstractly, but is under-defined and leaves too much to editors' interpretation * License-Code should probably be either retained or past BIPs folded into the single License header. * Some BIPs have introduced number registries (eg, HD derivation paths); it might be nice to provide some formal guidance in BIP 3 * The set of acceptable licenses is too restrictive, and contradicts recommendation to use upstream license. (eg, AGPL) Not having been used before is not a good reason in itself to prohibit usage. * Not all BIPs' Created dates are the dates of assignment. Are we going to dig through history to see when precisely existing BIPs were assigned? * Why increase the Title length? * Rationale states the Layer is permitted for non-Specification BIPs, but the "Changed from BIP 2" section plans to eliminate this reason for doing so. * "When is a BIP "accepted"?" writes off BIP 2's Comments feature, but ignores that BIP 2 also includes extensive explainations for determining if a BIP has been accepted or not, which seem still largely applicable. "Why are Process BIPs living documents?" similarly reduces that feature to "especially with fork proposals in mind" which is also untrue. These should probably get improved, even if BIP 3 doesn't mirror this feature. Luke On 11/4/25 20:10, Murch wrote: > Dear list, > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced > to Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > since then (see below). I have since April maintained a pull request > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > At this point, BIP 3 has received over 600 comments on GitHub and has > been discussed in multiple threads on this list. The proposal has been > Proposed for over seven months, and while several minor improvements > were proposed and processed, the proposal has no unaddressed > objections stated here or on the activation pull request. A growing > list of people has expressed explicit support for activating BIP 3 by > leaving an ACK on the pull request after reviewing the BIP: > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our > BIPs Process. > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > suggest that people who wish to state their support leave an ACK on > #1820 or reply in this thread. Similarly, I would like to invite > anyone to state concerns or raise objections here or on #1820. > While BIP 3 has long been proposed and the activation PR has been open > for over half a year, I suggest that we give all would-be reviewers > another four weeks, until 2025-12-02, before evaluating whether there > is rough consensus for merging the activation pull request. This > should be ample time to review and discuss BIP 3 as well as the > activation PR, even for people that have so far not engaged with the > material. > > Best, > Murch > > ---- > > Summary of changes since BIP 3 was advanced to Proposed: > > - The License header now uses SPDX License Expressions² > - The License-Code header was dropped in favor of requiring that the > license terms of the auxiliary files be specified in the respective > directory or folder per a license header or LICENSE file² > - The “Created” header has been renamed to “Assigned”³ > - The BIP text has been improved to clarify: > - the purpose of the BIPs repository⁴ > - that authors should establish viability of their proposal on the > mailing list⁴ > - the distinction between publication, acceptance, and adoption of > proposals⁴ > - when Draft BIPs can be closed due to not making progress⁴ > - that BIPs submissions may not be generated by AI/LLM⁵ > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > ¹ https://github.com/bitcoin/bips/pull/1794 > ² https://github.com/bitcoin/bips/pull/1892 > ³ https://github.com/bitcoin/bips/pull/1970 > ⁴ https://github.com/bitcoin/bips/pull/1819 > ⁵ https://github.com/bitcoin/bips/pull/2006 > -- 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/9456f7d3-1a45-489a-81b8-bb8fdabb7a9b%40dashjr.org. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-15 22:01 ` Luke Dashjr @ 2025-11-18 4:26 ` Greg Maxwell 2025-12-02 22:46 ` Murch 1 sibling, 0 replies; 31+ messages in thread From: Greg Maxwell @ 2025-11-18 4:26 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 7818 bytes --] if anything I think the AI disclosure is arguably too weak, particularly with the well documented instances of LLM psychosis and other weird influence and judgement compromising effects. The current text seems adequate to me and shouldn't be weakened further. On Mon, Nov 17, 2025 at 11:21 PM Luke Dashjr <luke@dashjr.org> wrote: > I have completed my review of the current BIP 3 proposal, and opened PR > #2037 to address these issues: > > * It misses that BIPs should be relevant to more than just one Bitcoin > project. > * AI/LLM usage disclosure is too much. As long as no content is > LLM-generated, we should be fine. > * Authors/Deputies assumes the champion (Author) was involved in writing > the document. This is a deviation from the current process where the > champion can be reassigned by editors if the current one is MIA. > * Required sections lacks an actual content section (typically > Specification). > * Reference Implementation is probably too specific with aux file or PR > requirement. One might conceive BIPs where the reference is an > independent/new software repository, for example. > * Editors have always been able to assign numbers for their own BIPs - > that isn't considered self-assignment, and recent confusion in the > community suggests this should be clarified. > * The requirement for public discussion/feedback/interest is new, and > inappropriate. While typically this may be the case, it should be > possible to put forward BIPs without relying on other contributors. > * Test vectors may not be applicable to all specification BIPs. > * "Compliant" is often the wrong term, as BIPs are recommendations. > "Compatible" seems more appropriate. > * Avoid implying every BIP Editor must reply to every new idea sent to > the ML > * The recent addition of "proposed by one of the authors [to the ML]" is > confusing and contradictory: it doesn't make sense to require the author > to have initiated the discussion himself, and the person who did may not > be interested in taking on the champion role (and may not be willing to > cooperate with submitting it and subsequently trasferring it) > * The Rationale stated lowercase "bitcoin" is used to refer to units of > the currency, but no such reference is made, and instead it is only > incorrectly used lowercase. All instances have been corrected to > capitalized and the rationale entry removed. > > Additionally, I identified the following issues which may need further > discussion to address: > > * It may make sense to replace "Authors" with "Champions"? > * "co-owned by the Bitcoin community" seems like a good idea abstractly, > but is under-defined and leaves too much to editors' interpretation > * License-Code should probably be either retained or past BIPs folded > into the single License header. > * Some BIPs have introduced number registries (eg, HD derivation paths); > it might be nice to provide some formal guidance in BIP 3 > * The set of acceptable licenses is too restrictive, and contradicts > recommendation to use upstream license. (eg, AGPL) Not having been used > before is not a good reason in itself to prohibit usage. > * Not all BIPs' Created dates are the dates of assignment. Are we going > to dig through history to see when precisely existing BIPs were assigned? > * Why increase the Title length? > * Rationale states the Layer is permitted for non-Specification BIPs, > but the "Changed from BIP 2" section plans to eliminate this reason for > doing so. > * "When is a BIP "accepted"?" writes off BIP 2's Comments feature, but > ignores that BIP 2 also includes extensive explainations for determining > if a BIP has been accepted or not, which seem still largely applicable. > "Why are Process BIPs living documents?" similarly reduces that feature > to "especially with fork proposals in mind" which is also untrue. These > should probably get improved, even if BIP 3 doesn't mirror this feature. > > Luke > > On 11/4/25 20:10, Murch wrote: > > Dear list, > > > > After planned work on BIP 3⁰ finished in February, BIP 3 was advanced > > to Proposed in March 2025¹. A few minor adjustments were made to BIP 3 > > since then (see below). I have since April maintained a pull request > > that would activate BIP 3: https://github.com/bitcoin/bips/pull/1820. > > > > At this point, BIP 3 has received over 600 comments on GitHub and has > > been discussed in multiple threads on this list. The proposal has been > > Proposed for over seven months, and while several minor improvements > > were proposed and processed, the proposal has no unaddressed > > objections stated here or on the activation pull request. A growing > > list of people has expressed explicit support for activating BIP 3 by > > leaving an ACK on the pull request after reviewing the BIP: > > https://github.com/bitcoin/bips/pull/1820#issue-2990155954 > > > > I formally propose a motion to adopt BIP 3 to replace BIP 2 as our > > BIPs Process. > > > > Since BIP 2 doesn’t specify a procedure for activating Process BIPs, I > > suggest that people who wish to state their support leave an ACK on > > #1820 or reply in this thread. Similarly, I would like to invite > > anyone to state concerns or raise objections here or on #1820. > > While BIP 3 has long been proposed and the activation PR has been open > > for over half a year, I suggest that we give all would-be reviewers > > another four weeks, until 2025-12-02, before evaluating whether there > > is rough consensus for merging the activation pull request. This > > should be ample time to review and discuss BIP 3 as well as the > > activation PR, even for people that have so far not engaged with the > > material. > > > > Best, > > Murch > > > > ---- > > > > Summary of changes since BIP 3 was advanced to Proposed: > > > > - The License header now uses SPDX License Expressions² > > - The License-Code header was dropped in favor of requiring that the > > license terms of the auxiliary files be specified in the respective > > directory or folder per a license header or LICENSE file² > > - The “Created” header has been renamed to “Assigned”³ > > - The BIP text has been improved to clarify: > > - the purpose of the BIPs repository⁴ > > - that authors should establish viability of their proposal on the > > mailing list⁴ > > - the distinction between publication, acceptance, and adoption of > > proposals⁴ > > - when Draft BIPs can be closed due to not making progress⁴ > > - that BIPs submissions may not be generated by AI/LLM⁵ > > > > ⁰ https://github.com/bitcoin/bips/blob/master/bip-0003.md > > ¹ https://github.com/bitcoin/bips/pull/1794 > > ² https://github.com/bitcoin/bips/pull/1892 > > ³ https://github.com/bitcoin/bips/pull/1970 > > ⁴ https://github.com/bitcoin/bips/pull/1819 > > ⁵ https://github.com/bitcoin/bips/pull/2006 > > > > -- > 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/9456f7d3-1a45-489a-81b8-bb8fdabb7a9b%40dashjr.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/CAAS2fgRSCqdjde%2B%3DZJcDkPmkfmSvEHdxcrM7fC1h8T7J6kzSFg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 10020 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-15 22:01 ` Luke Dashjr 2025-11-18 4:26 ` Greg Maxwell @ 2025-12-02 22:46 ` Murch 1 sibling, 0 replies; 31+ messages in thread From: Murch @ 2025-12-02 22:46 UTC (permalink / raw) To: bitcoindev Thanks for the review, Luke. On 2025-11-15 14:01, Luke Dashjr wrote: > I have completed my review of the current BIP 3 proposal, and opened PR > #2037 to address these issues: > > * It misses that BIPs should be relevant to more than just one Bitcoin > project. No, it doesn’t. It states so in the _Workflow > Ideation_ subsection. > * AI/LLM usage disclosure is too much. As long as no content is LLM- > generated, we should be fine. It looks to me like the prevailing opinion is that the change regarding AI should be rolled back either way. > * Authors/Deputies assumes the champion (Author) was involved in writing > the document. This is a deviation from the current process where the > champion can be reassigned by editors if the current one is MIA. While I don’t think BIP3 says that, it is generally the case that the Authors were involved in creating the document. Also, the line that you propose to change in your pull request describes the Deputies, not the Authors, which seems odd in the context of the commit message and your assertion here. Either way, BIP3 redefines Owner roles by introducing Deputies, so if an Author is MIA, someone that takes over the BIP could be assigned either as an Author or as a Deputy under BIP3. If the document is still in draft and the new owners are expected to evolve the document significantly, I don’t see an issue with them being referred to as Authors, if they are just advocating for the proposal, they could be Deputies. I’m not convinced this is a significant issue. > * Required sections lacks an actual content section (typically > Specification). Informational BIPs don’t need a Specification section. The BIP Types section clarifies that Specification BIPs need a Specification section, while heavily implying that Process BIPs do as well per “Process BIPs are like Specification BIPs, but [apply to Process]”. > * Reference Implementation is probably too specific with aux file or PR > requirement. One might conceive BIPs where the reference is an > independent/new software repository, for example. Sure, including dedicated repositories for providing Reference Implementations seems reasonable. > * Editors have always been able to assign numbers for their own BIPs - > that isn't considered self-assignment, and recent confusion in the > community suggests this should be clarified. I don’t recall anyone claiming that you weren’t allowed to assign a number, merely people pointing out that according to BIP2, no number has been assigned to dathonohm-reduced-data, yet. Your suggested rephrasing seems fine. > * The requirement for public discussion/feedback/interest is new, and > inappropriate. While typically this may be the case, it should be > possible to put forward BIPs without relying on other contributors. Your proposed change keeps the criteria exactly as are: correctly formatted, on-topic, and materially progressed beyond ideation phase. You only propose to remove the list of examples for how “progressed beyond ideation phase” might present. A list of examples is not generally considered to be exhaustive, and the provided examples are in line with the modus operandi — at least since we were appointed, no BIP numbers had been assigned before at least one reviewer commented on the BIP and the BIP author had addressed some comments. I don’t see how dropping the examples addresses above stated issue. It would make more sense to me if you were to propose adding another example or were to suggest rephrasing “materially progressed beyond ideation”, but as it is, the proposed change is a disimprovement. > * Test vectors may not be applicable to all specification BIPs. In that case, stating that should suffice, similar to the Backward Compatibility section being required even if just to say that there are no issues to be addressed. > * "Compliant" is often the wrong term, as BIPs are recommendations. > "Compatible" seems more appropriate. The terminology is correct. It must be possible to be compliant with a Specification BIP, i.e., a Specification BIP must lay out requirements in a way that implementers can conform with the requirements. > * Avoid implying every BIP Editor must reply to every new idea sent to > the ML The respective sentence already uses “should”, not “must”, but I’m fine with it being made more explicit that it is not necessary for BIP Editors to respond to every new BIP idea being posted to the mailing list. > * The recent addition of "proposed by one of the authors [to the ML]" is > confusing and contradictory: it doesn't make sense to require the author > to have initiated the discussion himself, and the person who did may not > be interested in taking on the champion role (and may not be willing to > cooperate with submitting it and subsequently trasferring it) Just like BIP2, BIP3 suggests that proposals are discussed at least once, preferably twice on the mailing list. Once as an idea, and then a second time when a first draft has been written. It’s unclear to me why anyone but someone involved in writing the proposal would send an early draft to the mailing list. Therefore, I don’t think it creates an undue burden to expect people to present their own work, but I’m also fine with this change being reverted. I don’t think it’s all that useful. > * The Rationale stated lowercase "bitcoin" is used to refer to units of > the currency, but no such reference is made, and instead it is only > incorrectly used lowercase. All instances have been corrected to > capitalized and the rationale entry removed. This came up in review with different reviewers either requesting capitalization or lowercasing, hence the footnote in the Rationale. I am not particularly invested either way. > Additionally, I identified the following issues which may need further > discussion to address: > > * It may make sense to replace "Authors" with "Champions"? I noticed that BIP2 used both terms interchangeably which I considered suboptimal. I initially used Champions throughout BIP3, but after several discussions with reviewers and numerous name suggestions (Champions, Authors, Proponents, Advocates,…), Authors was broadly preferred. See, e.g., https://github.com/murchandamus/bips/pull/2#discussion_r1671177693 > * "co-owned by the Bitcoin community" seems like a good idea abstractly, > but is under-defined and leaves too much to editors' interpretation I recall someone protesting that a BIP was proposed to get closed as obsolete, because a node implementation still uses it which resulted in the BIP remaining in Final instead. That’s the sort of consideration this section refers to. It also indicates that authors cannot willy-nilly change Specifications of deployed BIPs. > * License-Code should probably be either retained or past BIPs folded > into the single License header. See BIP Licensing > Specification: “A few BIP2-era BIPs (98, 116, 117, 330, 340) have a no longer used "License-Code" header indicating the license terms applicable to auxiliary source code files. For such cases, please refer to BIP2.” > * Some BIPs have introduced number registries (eg, HD derivation paths); > it might be nice to provide some formal guidance in BIP 3 I don’t consider this a blocker for the activation of BIP3. This could either be a separate proposal, or be added to BIP3 later, if someone wants to pick that up. I don’t plan on working on this. > * The set of acceptable licenses is too restrictive, and contradicts > recommendation to use upstream license. (eg, AGPL) Not having been used > before is not a good reason in itself to prohibit usage. As discussed previously and explained in the Rationale, reference implementations and/or test vectors being licensed solely under copyleft licenses could introduce friction for BIP implementers. As explained in the Specification, it is permitted to use more than one license, so BIP Authors could license their Reference Implementation or Test Vectors under an acceptable license with AGPL as an alternative. > * Not all BIPs' Created dates are the dates of assignment. Are we going > to dig through history to see when precisely existing BIPs were assigned? BIP2 was ambiguous in that it called the header Created and described it once as “date created on” and another time as the “date that the BIP was assigned a number”. Foremost, this change clarifies which of the two dates is expected to be used in future BIPs, but if people insist that past BIPs get corrected, it should be easy enough to crowdsource these corrections or work through them. > * Why increase the Title length? It was suggested by a reviewer here and seemed reasonable. The title limit is violated by numerous BIPs anyway. See: https://github.com/murchandamus/bips/pull/2#discussion_r1759508846 > * Rationale states the Layer is permitted for non-Specification BIPs, > but the "Changed from BIP 2" section plans to eliminate this reason for > doing so. I think you misread that. It says “the rule that [the layer header] is only available to _Standards Track_ BIPs is dropped” (emphasis added), and the _Changes from BIP 2_ sections says “The "Layer" header is optional for Specification BIPs or Informational BIPs”. I don’t think these two are contradictory, as either way, there currently exist a lot of Informational BIPs that have Layer headers. > * "When is a BIP "accepted"?" writes off BIP 2's Comments feature, but > ignores that BIP 2 also includes extensive explainations for determining > if a BIP has been accepted or not, which seem still largely applicable. It’s not clear to me what you think the problem here is, nor what you propose to change. The comment feature got hardly used and seemed more detrimental than useful which is why BIP3 proposes to remove it. > "Why are Process BIPs living documents?" similarly reduces that feature > to "especially with fork proposals in mind" which is also untrue. These > should probably get improved, even if BIP 3 doesn't mirror this feature. It is the description of when BIPs change status and the multitude of statuses in BIP2 that seemed particularly geared toward fork proposals. I’m not sure why you think BIPs being living documents has anything to do with the comment feature. In conclusion, it seems to me that the following changes could be adopted: - Revert guidance regarding AI - Broaden how Reference Implementations may be provided - Clarify language to remove implication BIP Editors may not assign numbers to their own BIPs - Make more explicit that BIP Editors don’t need to respond to every BIP idea or draft on the mailing list - Optional: Provide additional example how “Progressed beyond Ideation” may express Murch -- 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/af4c26b2-f802-4470-b31e-69c17511eb8c%40murch.one. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 Murch ` (5 preceding siblings ...) 2025-11-15 22:01 ` Luke Dashjr @ 2025-11-18 15:47 ` David A. Harding 2025-11-19 1:12 ` Greg Maxwell 6 siblings, 1 reply; 31+ messages in thread From: David A. Harding @ 2025-11-18 15:47 UTC (permalink / raw) To: Murch; +Cc: bitcoindev 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-18 15:47 ` David A. Harding @ 2025-11-19 1:12 ` Greg Maxwell 2025-11-19 1:20 ` Bryan Bishop ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Greg Maxwell @ 2025-11-19 1:12 UTC (permalink / raw) To: David A. Harding; +Cc: Murch, bitcoindev [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 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 2 siblings, 1 reply; 31+ messages in thread From: Bryan Bishop @ 2025-11-19 1:20 UTC (permalink / raw) To: Greg Maxwell Cc: David A. Harding, Murch, Bitcoin Development Mailing List, Bryan Bishop [-- Attachment #1: Type: text/plain, Size: 7010 bytes --] The social norm should be specifically against wasting the time of project volunteers or contributors. It doesn't matter whether the waste was generated by LLMs or biological neurons. If someone wants to donate LLM outputs to an open source project, then I think they should instead donate LLM token credits to any active existing contributors they wish, rather than LLM outputs. - Bryan https://x.com/kanzure On Tue, Nov 18, 2025, 7:18 PM 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/CABaSBaxR0ytoHHFEAe-%2B49VSWPaYan6N3J1DdG-51LK-d49xWA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 8919 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-19 1:20 ` Bryan Bishop @ 2025-11-19 21:21 ` Jon Atack 0 siblings, 0 replies; 31+ messages in thread From: Jon Atack @ 2025-11-19 21:21 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 7776 bytes --] Hi list, I agree with Greg Maxwell's thoughts on AI use. We have been seeing quite a bit of AI-generated PRs being thrown over the fence at us in the BIPs repository. In a few cases, the proposed fixes are useful. In many others, they seem to be a waste of review/maintenance/moderation bandwidth and time, and are demotivating to deal with. I am also aware of BIPs that turned out to have been largely generated or rewritten to final form by LLMs. I am not a lawyer, but the copyright situation WRT such BIPs seems unclear and evolving. This was not the principal motivation of the BIP 3 addition about AI/LLM use -- not wasting our time is -- but is a context that may need keeping tabs on. Personally, I don't wish to spend time manually reviewing AI slop or hallucinations. Due to what we're seeing and to what Greg rightly describes above, I think we'll need to set up auto-review by LLMs in the CI pipeline for (a) a degree of confidence grade of AI being used, and (b) perhaps an initial technical review. Similar to Drahtbot in Bitcoin Core and to what I see in use in other organizations that I review for. For now, these tools will vitally need to be followed by human review and subjective judgment calls on our part. The BIP 3 section about reducing judgment calls is probably unrealistic at this time and in need of an update before activation. Best. On Tue, Nov 18, 2025, 7:18 PM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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/624c9e1f-ffb8-4165-83f4-d445f8777476n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 9983 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-19 1:12 ` Greg Maxwell 2025-11-19 1:20 ` Bryan Bishop @ 2025-11-19 6:25 ` David A. Harding 2025-11-19 6:58 ` Bitcoin Error Log 2 siblings, 0 replies; 31+ messages in thread From: David A. Harding @ 2025-11-19 6:25 UTC (permalink / raw) To: Greg Maxwell; +Cc: Murch, bitcoindev > 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. What potential issues? I'm not familiar (and did not find in a quick search) any authors or publishers who were sued for using content generated by AI; all the lawsuits I found were against companies that produced AI tools. > the number of good submissions that could be made would hardly be > increased by LLMs [...] 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. What evidence do you have that the number of good submissions could hardly be increased by the use of LLMs? (Perhaps see my next point before replying to this one.) > I've never had an impression that drafting was at all a limiting step > in writing BIPs Ten years ago, I wrote the draft text for what became BIP125 because several developers in a public Bitcoin Core IRC meeting said they thought there should be a BIP. I think they were all hoping that someone else would do it, and I have no way to tell if it would've been written had I not volunteered. I wonder if there's a hidden survivorship bias in your impression of the situation. It's easy to think of all the great BIPs we have today---but how many great BIPs could we have had if creating them was faster and easier? I think many Bitcoin developers feel "better with code than words" and only undertake documentation tasks reluctantly; if AI can help write documentation, even just a rough draft, is that not a boon? > 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. Is it not equally something of an existential threat to open collaboration to deny to open collaborators the powerful tools that closed collaborators may use? I like AI-assisted writing; my response to BIP3 being deployed in its current form will not be to write manually; it will be to use AI but publish elsewhere---likely a place with fewer openly collaborating peer reviewers than the current BIPs repo. (This is hypothetical; I have no current plans to write any specification documents.) -Dave -- 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/d0eb41a70b2ef94c2645b3f0a4b12c30%40dtrt.org. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-19 1:12 ` Greg Maxwell 2025-11-19 1:20 ` Bryan Bishop 2025-11-19 6:25 ` David A. Harding @ 2025-11-19 6:58 ` Bitcoin Error Log 2025-11-20 1:22 ` Bitcoin Mechanic 2 siblings, 1 reply; 31+ messages in thread From: Bitcoin Error Log @ 2025-11-19 6:58 UTC (permalink / raw) To: Greg Maxwell; +Cc: David A. Harding, Murch, bitcoindev [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-19 6:58 ` Bitcoin Error Log @ 2025-11-20 1:22 ` Bitcoin Mechanic 2025-11-20 9:06 ` Oghenovo Usiwoma 0 siblings, 1 reply; 31+ messages in thread From: Bitcoin Mechanic @ 2025-11-20 1:22 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 10415 bytes --] 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 13411 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-20 1:22 ` Bitcoin Mechanic @ 2025-11-20 9:06 ` Oghenovo Usiwoma 2025-11-20 17:23 ` Greg Maxwell 2025-11-20 20:14 ` Mat Balez 0 siblings, 2 replies; 31+ messages in thread From: Oghenovo Usiwoma @ 2025-11-20 9:06 UTC (permalink / raw) To: Bitcoin Mechanic; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 11830 bytes --] > 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 AM Bitcoin Mechanic <bitcoinmechanic@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.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/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 14142 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-20 9:06 ` Oghenovo Usiwoma @ 2025-11-20 17:23 ` Greg Maxwell 2025-11-22 15:14 ` Jon Atack 2025-11-20 20:14 ` Mat Balez 1 sibling, 1 reply; 31+ messages in thread From: Greg Maxwell @ 2025-11-20 17:23 UTC (permalink / raw) To: Oghenovo Usiwoma; +Cc: Bitcoin Mechanic, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 13174 bytes --] 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 AM Oghenovo Usiwoma <eunovo9@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 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 AM Bitcoin Mechanic < > bitcoinmechanic@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.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/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%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/CAAS2fgSHLa9pumDip0X7Y6%3D%2BvNf_i_j2Jz9LQGDUNdquU9zHtA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 15656 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-20 17:23 ` Greg Maxwell @ 2025-11-22 15:14 ` Jon Atack 2025-11-22 19:30 ` Sjors Provoost 0 siblings, 1 reply; 31+ messages in thread From: Jon Atack @ 2025-11-22 15:14 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 14754 bytes --] 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic <bitcoin...@ocean.xyz> >> 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com >>> <https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.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+...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com >> <https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%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/27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 18714 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-22 15:14 ` Jon Atack @ 2025-11-22 19:30 ` Sjors Provoost 2025-11-22 20:53 ` /dev /fd0 2025-11-22 21:06 ` Bill MacDonald 0 siblings, 2 replies; 31+ messages in thread From: Sjors Provoost @ 2025-11-22 19:30 UTC (permalink / raw) To: Jon Atack, Greg Maxwell; +Cc: Bitcoin Development Mailing List 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 <jonnyatack@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 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic <bitcoin...@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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-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. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-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+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42%40sprovoost.nl. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-22 19:30 ` Sjors Provoost @ 2025-11-22 20:53 ` /dev /fd0 2025-11-28 15:35 ` Tim Ruffing 2025-11-22 21:06 ` Bill MacDonald 1 sibling, 1 reply; 31+ messages in thread From: /dev /fd0 @ 2025-11-22 20:53 UTC (permalink / raw) To: Sjors Provoost; +Cc: Jon Atack, Greg Maxwell, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 16780 bytes --] 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 AM Sjors Provoost <sjors@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 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 <jonnyatack@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 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic <bitcoin...@ocean.xyz> > 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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-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. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-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+unsubscribe@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42%40sprovoost.nl > . > -- 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/CALiT-ZpHpxC7vqUvK%2BQ%3DD49jsmcygGsz1NG_DTf%2BG8YEaWi64Q%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 19921 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-22 20:53 ` /dev /fd0 @ 2025-11-28 15:35 ` Tim Ruffing 2025-11-28 16:34 ` Jon Atack 0 siblings, 1 reply; 31+ messages in thread From: Tim Ruffing @ 2025-11-28 15:35 UTC (permalink / raw) To: /dev /fd0, Sjors Provoost Cc: Jon Atack, Greg Maxwell, Bitcoin Development Mailing List 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 AM Sjors Provoost <sjors@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 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 <jonnyatack@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 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic > > > <bitcoin...@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 > > > <da...@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+...@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+...@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-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. > > > To view this discussion visit > > > https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-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+unsubscribe@googlegroups.com. > > > To view this discussion visit > > > https://groups.google.com/d/msgid/bitcoindev/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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c550897a7c7479cb09120c1fd3799772270d2976.camel%40real-or-random.org. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-28 15:35 ` Tim Ruffing @ 2025-11-28 16:34 ` Jon Atack 2025-11-28 19:21 ` Pieter Wuille 0 siblings, 1 reply; 31+ messages in thread From: Jon Atack @ 2025-11-28 16:34 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 21945 bytes --] 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 community's time asking for review of LLM-generated BIP drafts, as they represent the most problematic submissions in their ease of slick slop generation 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. 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 Editor 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 be a living document that can hopefully evolve. On Friday, November 28, 2025 at 9:48:44 AM 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." 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 AM 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 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 <jonny...@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 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic > > > <bitcoin...@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 > > > <da...@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+...@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+...@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-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. > > > To view this discussion visit > > > https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-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-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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9b8c8573-cafb-447e-9923-b9a3b9e10950n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 29329 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-28 16:34 ` Jon Atack @ 2025-11-28 19:21 ` Pieter Wuille 0 siblings, 0 replies; 31+ messages in thread From: Pieter Wuille @ 2025-11-28 19:21 UTC (permalink / raw) To: Jon Atack; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 23875 bytes --] 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 state of affairs, and I think the question of LLM material is relative minor point compared to the other changes BIP 3 brings, of which our understanding may evolve 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 outlawing LLMs is the solution: if interpreted and enforced strictly, it will cut 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 the full text of low-quality material, including clearly LLM-generated text." -- Pieter On Friday, November 28th, 2025 at 11:57 AM, 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" -> 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 generation 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. > > 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 Editor 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 be a living document that can hopefully evolve. > > On Friday, November 28, 2025 at 9:48:44 AM 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." >> >> 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 AM 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 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 <jonny...@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 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic >>> > > <bitcoin...@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 >>> > > <da...@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+...@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+...@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-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. >>> > > To view this discussion visit >>> > > https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-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-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 email 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 "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/K4ckYujc4cGTRKkpUpEH5z5qlczjySkq7GeCc_Q5A7fsTkHdme_oA8gmeC2HOaho_Z1MOAEw38dTEvPepdm9emGF-l2-ct0AmK-cAEEoeMU%3D%40wuille.net. [-- Attachment #2: Type: text/html, Size: 32093 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-22 19:30 ` Sjors Provoost 2025-11-22 20:53 ` /dev /fd0 @ 2025-11-22 21:06 ` Bill MacDonald 1 sibling, 0 replies; 31+ messages in thread From: Bill MacDonald @ 2025-11-22 21:06 UTC (permalink / raw) To: Sjors Provoost; +Cc: Jon Atack, Greg Maxwell, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 17707 bytes --] There’s no real incentive for anyone to disclose their use of an LLM or any future assisting technology. If I’m a good actor and write a good BIP (good meaning compliant and high-quality), disclosing LLM usage doesn’t help my BIP get reviewed. Instead I (hopefully) would have already done the pre-work: discussing the idea in forums like this, gathering feedback, and refining it. That process, along with the quality of the work, is what leads to a review. Alternatively, if I’m a good actor and write a bad BIP, it gets ignored either way. And if I’m a bad actor and write a good BIP then I’m not going to disclose that I used an LLM simply because I don’t want to. The same applies if I’m a bad actor writing a bad BIP. This discussion isn’t really about AI. It’s about what Sjors describes as “low-effort contributions,” regardless of the tool used Kanzure identified it correctly: “It doesn't matter if it's LLM generated slop or non-LLM slop, slop is still slop.” I think removing the disclosure requirement and including a general warning like Sjors’ makes sense and is transparent. On Sat, Nov 22, 2025 at 12:38 PM Sjors Provoost <sjors@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 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 <jonnyatack@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 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 PM 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, 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 AM 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 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 AM Bitcoin Mechanic <bitcoin...@ocean.xyz> > 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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-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. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-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+unsubscribe@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42%40sprovoost.nl > . > -- 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/CADitH-yoK6ZbieG1GqXvDaLTbwboxi9cMDwegvF%2BU1KRXWxx1g%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 21624 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoindev] Motion to Activate BIP 3 2025-11-20 9:06 ` Oghenovo Usiwoma 2025-11-20 17:23 ` Greg Maxwell @ 2025-11-20 20:14 ` Mat Balez 1 sibling, 0 replies; 31+ messages in thread From: Mat Balez @ 2025-11-20 20:14 UTC (permalink / raw) To: Oghenovo Usiwoma; +Cc: Bitcoin Mechanic, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 14565 bytes --] More and more of writing by all humans, including BIP proposers, will inevitably involve AI in some more or less significant way. I don't expect people to reliably express the degree to which AI was used to inform the thinking behind the BIP, or the writing itself. I'm not aware of any common standard we would use to express those things. Adversarially, we have to assume people won't do it if it's not in their interests. Rather, I think the expectation should be that BIP proposers are entirely responsible for submitting high quality BIPs and they take ownership for what they are submitting (submitting garbage burns your rep, always has and always will). BIP reviewers should simply assume for all BIPs that AI was likely used significantly to create them, and judge BIPs only on the merit of the ideas and content. Because of the advent of LLMs (and their inevitable continued improvement) this will almost certainly result in an increased number of BIPs being advanced, many of low (slop-filled) quality but also, hopefully, more high quality ones as well—proposals that might not otherwise have seen the light of day and/or proposals themselves being strengthened with better arguments, ideas and language. The solution to such a rise in volume IMO is that BIP reviewers should also equip themselves with LLMs and other AI-powered tools to help filter/triage/assess BIPs to get a handle on the rise in noise level. Yet, just like BIP proposers, the onus should be on BIP reviewers to take ownership for the quality of the decision-making around BIP quality and that it not ever be entirely automated but retain "human in the loop" judgment—at least for the foreseeable future—just made more efficient and effective through the use of AI. On Thu, Nov 20, 2025 at 1:47 AM Oghenovo Usiwoma <eunovo9@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 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 AM Bitcoin Mechanic < > bitcoinmechanic@ocean.xyz> 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 PM 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 AM Greg Maxwell <gmax...@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 <da...@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+...@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+...@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/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.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/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CAOCjZ9TLtsyjXTdonWK-zUj-V%3DHtFnDeb92D_W%2BVPV6TCg%3Donw%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/CABd6%3DMPtx9rN2ZtTz7CbT-zb-3qVUecZZrmb56aFyCSVeLxsEQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 17070 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2025-12-02 22:55 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-05 1:10 [bitcoindev] Motion to Activate BIP 3 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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox