From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 19 Nov 2025 18:18:45 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vLuFw-0006RK-AT for bitcoindev@gnusha.org; Wed, 19 Nov 2025 18:18:45 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-3e30001866fsf109068fac.3 for ; Wed, 19 Nov 2025 18:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763605118; x=1764209918; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=t6PuenrQY5824FpmsdD/xsBrlZnc6zZsLNZvbnjtYAY=; b=Z3B/01fXiLUDLe1BqqqUZx9kPUnRkHmtAEwn5EkzAQgzI0qkuf5Rp9ipo2lloJaxmm rVHf6vFjarLt5uly7RVjbcYHa5olMXQphSEmvs4wz+VSTPN4I856FGSlLYYFr3eD41su lXeKEocNQ1mveohAXnpQjXdvOG2/hICIhSY1h41MnzBSqadPez9NfSlqGBNyi65ZOutD TWIoETBFViWfpHO+NZy9gcfOVuuHvM4pvZajJ9jGVe3i00P81lvZzFNDhgItoNLQxCGA PsWi1xCC05nbkKdiOtD9BcPNV0HjKdCQx//tqjjs2ye2manoZU3uEqCzjw1ndC8aQcQG wcvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1763605118; x=1764209918; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=t6PuenrQY5824FpmsdD/xsBrlZnc6zZsLNZvbnjtYAY=; b=S2Pz0R9GQUidf8LHxA13ibyIi65NrzfrtjQkt++hHoS2XoKKyarDjl+9e+8xKsjyce TmPqnk6l+rNAq/K/yvUvvB5ns1VTblfG+UvMD72yLbz8PgRWIJpVe8rYcFYNrPS41XV1 KBN2SO56woSLxwEObsD0HGLlITDU1OuVwHKAwh8ec9CoF88ToDZN5+cn/txPcYpE1h+E H2rgLsglbMG4WUlnLzMI0S1mPkDfXOMkVQNqii4y28X/S4tfoAr/nb5m9/37d+nz3tQQ +9SGTTra/V8JwHAULHWRViavDQFX9a8wneVb5eq9gT6c0zjfBfG/OlLMPv7D/ACw8VH7 Yr1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763605118; x=1764209918; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=t6PuenrQY5824FpmsdD/xsBrlZnc6zZsLNZvbnjtYAY=; b=bVVmDgsu5A3gZs3CeQXXuIeutLOlDXRl4SMcPfAL5NR0j79ecfDZtqiUz/zNWq4qIL jbdvxOTJxgiJ6Gn+opQESogRxCSMOtSn5/Cm7Q1kMugK3cNCpRsN6elGfGHYi9BjHVGo tX4k+HapuQcZPCGLHMVv0MLKanvs47YEa/uXSIZQu6ByggjSFfkqSxgZJLBCgvghBpX5 T7xECvhhVc69riR+NP1wWSytS5j/n6Ha/f4gx0E5XKIqeAUx8sVp5Xy2PZIjnrIPnkMx rR33vOJQaJdMX8cFcCvhTURcpCOYJ7h3+WNAFQNHl8q7Uumsi8fRqky1kJPB4LfXtReL v5Wg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVQZ6WWJW+7iuSt+aM0YpOHilZs9KsGRsMLzJinQkLyXqcVnvvrQ+Rj/fh3fJUndidvlCEVPUZKyEoA@gnusha.org X-Gm-Message-State: AOJu0YwI6cckRifKT0+IcGXiHyLe4tG6gJ9Q7fJDlANHKR2ww2yb0KYx ZkfsAnNXSxsEvSMVBCxpw2XCxQsCXQF0KUwJUdcx7K81vspUP5zgCfbZ X-Google-Smtp-Source: AGHT+IGglvuxVEve7Q/bqOJW7HfPq93X13ETfTrE0DOAIGuvTUVJyUxLQlVe8/MbgpIkXxNEmUPfLA== X-Received: by 2002:a05:6871:3587:b0:3d2:3b57:e587 with SMTP id 586e51a60fabf-3ec9a53645bmr492023fac.5.1763605117689; Wed, 19 Nov 2025 18:18:37 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YtrtkxpnPMUZVTf0iYge6F1wqnEWkGH5VosYFJAe8zUA==" Received: by 2002:a05:6871:5e8b:b0:35a:ce0a:d0a3 with SMTP id 586e51a60fabf-3ec9b01af2bls248293fac.0.-pod-prod-08-us; Wed, 19 Nov 2025 18:18:33 -0800 (PST) X-Received: by 2002:a05:6808:1918:b0:450:65dc:1fce with SMTP id 5614622812f47-450ff20c736mr772259b6e.3.1763605113639; Wed, 19 Nov 2025 18:18:33 -0800 (PST) Received: by 2002:a05:690c:a589:b0:780:f7eb:fdf with SMTP id 00721157ae682-78a6c062642ms7b3; Wed, 19 Nov 2025 17:22:14 -0800 (PST) X-Received: by 2002:a05:690c:45c4:b0:786:7a54:4624 with SMTP id 00721157ae682-78a7955c38cmr27008647b3.7.1763601733153; Wed, 19 Nov 2025 17:22:13 -0800 (PST) Date: Wed, 19 Nov 2025 17:22:12 -0800 (PST) From: Bitcoin Mechanic To: Bitcoin Development Mailing List Message-Id: <012c719c-0f56-474d-8851-a2db3a0b422cn@googlegroups.com> In-Reply-To: References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> <3a66dbbe9a9c46566c8a9a16ccb1cc91@dtrt.org> Subject: Re: [bitcoindev] Motion to Activate BIP 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_141590_2091064244.1763601732765" X-Original-Sender: bitcoinmechanic@ocean.xyz Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.2 (/) ------=_Part_141590_2091064244.1763601732765 Content-Type: multipart/alternative; boundary="----=_Part_141591_1801201767.1763601732765" ------=_Part_141591_1801201767.1763601732765 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it makes sense to request that submissions should state if - and to= =20 what degree - AI has been used. It's reasonable to expect fewer eyeballs on= =20 AI generated submissions as they're so easily generated and their potential= =20 for wasting reviewer time is high. If people are submitting AI generated code and lying about it than that=20 obviously undermines what it is they're proposing so they're naturally=20 disincentivized to do so, thus the honour system should be relatively=20 effective. I think most people have begun using it for making outlines and tweaking=20 from there. The time saved is too significant for many to resist, and=20 declaring that it was used for an initial outline shouldn't be too=20 dissuasive for any reviewers. The deeper discussion around legal implications and generally about AI code= =20 quality is not resolvable here, it's a massive topic with deep=20 philosophical implications that go way outside the scope of BIP 3 imo. Thanks On Wednesday, November 19, 2025 at 2:40:55=E2=80=AFPM UTC-8 Bitcoin Error L= og wrote: > A few years ago, I had this idea that bitcoin divisibility needed to be= =20 > fixed as a misconception. I put it (proto-bip177) in our bitcoin wallet= =20 > app, promoted the idea where I could. It worked great, but only our users= =20 > knew. > > And then AI became good enough to use for some things. AI has been a HUGE= =20 > unlock for me and my learning and creating style. Early this year, I told= =20 > my AI, filled with context about the upcoming BIP3 standard, and examples= =20 > of related BIPs, to make a BIP for me that properly expressed all of the= =20 > 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=20 > formatting was total slop. Thankfully, most of the BIP reviewers are=20 > actually amazing people, and I was able to contact them directly and ask= =20 > for help, because I'm not an actual developer (yet). After some private= =20 > help, it was good enough for the mailing list, and a real draft.=20 > > BIP 177 is a very simple BIP compared to most, and I'd probably make it= =20 > better if I started today, but ... it exists! It might be the first/only= =20 > (?) vibe-BIP, and, as of last week, due to Cashapp and Square support, it= 's=20 > possible that BIP 177 is now in more people's hands than not.=20 > > Today, I now have several private drafts of BIPs I am working on with AI,= =20 > I am trying to impose less slop on my peers as I work in private. These= =20 > newer BIPs are increasingly technical, and I have also started vibe-codin= g=20 > implementations to test them, and I continue growing into an engineer.=20 > > Now the BIP repo is my favorite part of Bitcoin and interacting with=20 > Bitcoin Core. I feel sincere gratitude to three BIP reviewers specificall= y=20 > for humoring my sincere, yet not matured, effort and desire to improve=20 > Bitcoin without changing consensus code. > > My vision for the BIP repo and reviewers, and AI, is much different than= =20 > yours. It is part of the story that brought me closer to Bitcoin=20 > development, and deep respect to my superiors for tolerating me while I= =20 > was/am fledgling.=20 > > Please don't add more weird subjective, exclusive barriers just because A= I=20 > is warping reality. Deal with it, and please, please, continue making an= =20 > effort to not only guard the BIP repo, but ensure it remains a fertile=20 > ground where Bitcoin Core maintains an attitude of being great stewards t= o=20 > the people, not only the specs.=20 > > After all, we will need people to replace you some day, and those people= =20 > need role models too. > > ~John Carvalho > > > On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg Maxwell = wrote: > >> No doubt *you* are able to make good documents with or without the aid o= f=20 >> AI. >> >> With outright AI 'authorship' you immediately run into potential=20 >> copyright issues-- which I think is the origin of the "generated by"=20 >> prohibition, otherwise I think disclosure would be sufficient. >> >> Taking a step back: is Bitcoin's welfare maximized by permitting LLM=20 >> glurge submissions in standards documents? In some cases it's benign, I= =20 >> readily agree, in others its harmful. But the number of good submission= s=20 >> that could be made would hardly be increased by LLMs (being limited by= =20 >> expert proposers with good ideas) but the number of potential poor=20 >> submissions is increased astronomically. So I think it's pretty clearly= a=20 >> net harm to have text authored that way. >> >> I've never had an impression that drafting was at all a limiting step in= =20 >> writing BIPs, though even to the extent that it has been at times it's= =20 >> possible to use LLMs in a review capacity to make authorship much easier= =20 >> ("What's missing / unclear?") without resorting to using it to author. >> >> There is a particularly clear pattern at least with current LLM tools=20 >> that users who lack the skills to have authored the work without an LLM = are=20 >> generally unable to recognize when the LLM is full of crap (and even=20 >> sometimes when they should know better), so unfortunately they're only= =20 >> benign to use in the hands of those whose need is the least. =20 >> >> And as a reviewer outside of Bitcoin I've found LLM powered proposers to= =20 >> be absolutely the worst to deal with. Because they're not submitting the= ir=20 >> own words and ideas, they're unable to change their thinking in response= or=20 >> explain sufficiently to change yours--- the interactions often degrade t= o=20 >> them just copy and pasting their chatbot back to you. Because it's chea= p=20 >> to generate more text they also tend to flood you out with documents=20 >> several times longer than any human author would have bothered with. >> >> I think LLMs have generally created something of an existential threat t= o=20 >> most open collaborations: Now its so easy to get flooded out by subtly= =20 >> worthless material. Many projects, including, Bitcoin have long struggl= ed=20 >> with review capacity being limited and a far amount of time waste by=20 >> thoughtless (or even crazy!) submissions, but now it's automated and eve= n=20 >> the most well meaning person may now make submissions that are as bad as= =20 >> the most deviously constructed malicious submissions could have been in = the=20 >> past, not even know they are doing it, and can make a dozen proposals=20 >> before lunch without even breaking a sweat. >> >> >> >> On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Harding wrote: >> >>> On 2025-11-04 15:10, Murch wrote: >>> > Summary of changes since BIP=E2=80=AF3 was advanced to Proposed: >>> > [...] >>> > - that BIPs submissions may not be generated by AI/LLM=E2=81=B5 >>> > [...] >>> > =E2=81=B5 https://github.com/bitcoin/bips/pull/2006 >>> >>> I strongly disagree with this change. If I were to begin working on a= =20 >>> new BIP today, I would use AI throughout the process. I'd ask it to=20 >>> help me create a todo list of what should go in the BIP; I'd ask it to= =20 >>> create a draft based on existing BIPs, my todo list, and whatever other= =20 >>> work products I had (e.g. prototypes); I'd then ask it to help me refin= e=20 >>> the document until I was satisfied. >>> >>> I would, of course, review every word of the draft BIP before submittin= g=20 >>> it for consideration and ensure that it represented the highest quality= =20 >>> work I was able to produce---but the ultimate work would be a mix of AI= =20 >>> and human writing and editing. >>> >>> I think considerate use of AI would be even more valuable for people wh= o=20 >>> are less comfortable with writing technical English-language documents= =20 >>> than I am. For example, non-native literates, people with disabilities= =20 >>> that make text input difficulty, and those who recognize that they're= =20 >>> bad writers. >>> >>> The PR forbidding AI doesn't go into any detail about its motivation,= =20 >>> although it references a previous discussion[1] where a low-quality BIP= =20 >>> PR was opened using mostly AI-generated content. I'm guessing the=20 >>> motivation is that AI (by itself) generates low-quality technical=20 >>> content, BIPs should be high-quality technical content, and therefore w= e=20 >>> should ban the use of AI. >>> >>> However, as mentioned in the previous discussion, the BIP process=20 >>> already requires high-quality content.[2] AI-generated content can be= =20 >>> high-quality, especially if its creation and editing was guided by a=20 >>> knowledgeable human. Banning specific tools like AI seems redundant an= d=20 >>> penalizes people who either need those tools or who can use them=20 >>> 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= =20 >>> **high quality** and properly formatted, the authors should open a pull= =20 >>> request to the BIPs repository." --BIP3, emphasis added >>> >>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/3a66dbbe9a9c46566c8a9a16cc= b1cc91%40dtrt.org >>> . >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRV1aZ9xvAhBriZ%3DXdm= Yf5CvrvXWXsjVD07uynivW_qkg%40mail.gmail.com=20 >> >> . >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com. ------=_Part_141591_1801201767.1763601732765 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 o= n AI generated submissions as they're so easily generated and their potenti= al for wasting reviewer time is high.

If people are su= bmitting AI generated code and lying about it than that obviously undermine= s what it is they're proposing so they're naturally disincentivized to do s= o, thus the honour system should be relatively effective.

<= /div>
I think most people have begun using it for making outlines and t= weaking from there. The time saved is too significant for many to resist, a= nd declaring that it was used for an initial outline shouldn't be too dissu= asive for any reviewers.

The deeper discussion a= round legal implications and generally about AI code quality is not resolva= ble here, it's a massive topic with deep philosophical implications that go= way outside the scope of BIP 3 imo.

Thanks

On Wednesday, November 19, 2025 at 2:40:55=E2=80=AFPM UTC-8 Bitcoin Err= or Log wrote:
A few years ago, I had this idea that bitcoin divisi= bility needed to be fixed as a misconception. I put it (proto-bip177) in ou= r bitcoin wallet app, promoted the idea where I could. It worked great, but= only our users knew.

And then AI became good enou= gh to use for some things. AI has been a HUGE unlock for me and my learning= and creating style. Early this year, I told my AI, filled with context abo= ut the upcoming BIP3 standard, and examples of related BIPs, to make a BIP = for me that properly expressed all of the nuances of my idea on how to hand= le removal of decimals in a UX.

It looked pretty g= ood, 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, a= nd I was able to contact them directly and ask for help, because I'm no= t an actual developer (yet). After some private help, it was good enough fo= r the mailing list, and a real draft.=C2=A0

BIP 17= 7 is a very simple BIP compared to most, and I'd probably make it bette= r if I started today, but ... it exists! It might be the first/only (?) vib= e-BIP, and, as of last week, due to Cashapp and Square support, it's po= ssible that BIP 177 is now in more people's hands than not.=C2=A0
=

Today, I now have several private drafts of BIPs I am w= orking 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 star= ted vibe-coding implementations to test them, and I continue growing into a= n engineer.=C2=A0

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 matur= ed, effort and desire to improve Bitcoin without changing consensus code.

My vision for the BIP repo and reviewers, and AI, i= s 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.=C2=A0

Please don't = add more weird subjective, exclusive barriers just because AI is warping re= ality. Deal with it, and please, please, continue making an effort to not o= nly guard the BIP repo, but ensure it remains a fertile ground where Bitcoi= n Core maintains an attitude of being great stewards to the people, not onl= y the specs.=C2=A0

After all, we will need people = to replace you some day, and those people need role models too.
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">

~John Carvalho


On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg = Maxwell <gmax...@gmail.com> wrote:

=
With outright AI 'authorship' you immediately run into potenti= al=20 copyright issues-- which I think is the origin of the "generated by&qu= ot;=20 prohibition, otherwise I think disclosure would be sufficient.
Taking a step back: is Bitcoin's welfare=C2=A0maximized by= permitting LLM glurge submissions in standards documents? In some cases it= 's benign, I readily agree, in others its harmful.=C2=A0 But the number= of good submissions that could be made would hardly be increased by LLMs (= being limited by expert proposers with good ideas) but the number of potent= ial poor submissions is increased astronomically.=C2=A0 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 limiti= ng step in writing BIPs, though even to the extent that it has been at time= s it's possible to use LLMs in a review capacity to make authorship muc= h easier ("What's missing / unclear?") without resorting to u= sing it to author.

There is a particularly clear pattern at l= east 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 unfortun= ately they're only benign to use in the hands of those whose need is th= e least.=C2=A0=C2=A0

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, th= ey're unable to change their thinking in response or explain sufficient= ly to change yours--- the interactions often degrade to them just copy and = pasting their chatbot back to you.=C2=A0 Because it's cheap to generate= more text they also tend to flood you out with documents several times lon= ger 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=C2=A0so easy to get flooded out by subtl= y worthless material.=C2=A0 Many projects, including, Bitcoin have long str= uggled with review capacity being limited and a far amount of time waste by= thoughtless (or even crazy!) submissions, but now it's automated and e= ven the most well meaning person may now make submissions that are as bad a= s the most deviously constructed malicious submissions could have been in t= he past, not even know they are doing it, and can make a dozen proposals be= fore lunch without even breaking a sweat.



On 2025-11-04 15:10, Murch wr= ote:
> Summary of changes since BIP=E2=80=AF3 was advanced to Proposed:
> [...]
> =C2=A0 - that BIPs submissions may not be generated by AI/LLM=E2=81=B5=
> [...]
> =E2=81=B5 https://github.com/bitcoin/bips/pull/2006

I strongly disagree with this change.=C2=A0 If I were to begin working on a=
new BIP today, I would use AI throughout the process.=C2=A0 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 refin= e
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.=C2=A0 For example, non-native literates, people with disabilitie= s
that make text input difficulty, and those who recognize that they're <= br> bad writers.

The PR forbidding AI doesn't go into any detail about its motivation, <= br> although it references a previous discussion[1] where a low-quality BIP PR was opened using mostly AI-generated content.=C2=A0 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]=C2=A0 AI-generated content can be=
high-quality, especially if its creation and editing was guided by a
knowledgeable human.=C2=A0 Banning specific tools like AI seems redundant a= nd
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 o= f
**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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/3a66dbbe9a9c46566c8a9a16ccb1cc91%40dtrt.org.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com.
------=_Part_141591_1801201767.1763601732765-- ------=_Part_141590_2091064244.1763601732765--