From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 22 Nov 2025 13:41:11 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vMvLx-0005Ea-Sp for bitcoindev@gnusha.org; Sat, 22 Nov 2025 13:41:11 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3e09d7998b3sf4420406fac.3 for ; Sat, 22 Nov 2025 13:41:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763847664; cv=pass; d=google.com; s=arc-20240605; b=TERrMc2RMuzWSEfB/DdisHKSodq9t9ModvZgVnfK4L6Fp6JnKfJhdXLYpi7DWTFuHU DEsIWKpCPyBe5H81Hgud/DYBf5zncAf2ZqfHrjWK0PY46/T7z/Mp2133XXGpP9z6Aq7M cBLtR8mIb43p3jAJe6GGqOm1r0erEnViTok9h5WiBOsZoFNrMLvMQY/H61o1dThpO/yY uqMNbssGGgY4/YH4u3LA7AMnarPt1qXqEGFZ+0OyQL5TieLHSldF1uR9AwlgrPOoufO8 98KMDBkm+dsdNxYw1uwgHpaJbiYwFH2dzbltYbZnYXTeU4IV+BCMQX8GYghi6JWxpk7T uOUg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=1JSjyDc0NH0l/8qaWa9ax5BR+cHKP9TH2m+pCmZ49UU=; fh=+l8RWB/aB34sFa67kBG1bGWVt6xM2G6zQSgSRmQSQNY=; b=ilQ+3sIOx98kl2wM9a+TS3LNnlfn1b3Id4/kaRQdn4YWr5P9DcQkF5kRbHTN9Ujadh SGHqPjRJpXwPdcdAue1HGkyO14c3/2em+YRQPdSfdeFO1GfvMihr3WKrkORRlz1t38dv uLrWwc4FUbwscIEnNqH5r4RmmwIe7qURl7pmcQn9rAlow+C4M2HCvozcrf2++e41m4WH vmZDZm4LcLWetNyVcmh+Kvk+LrVqhbhBa+82UL/LPf9IN1R0nM/klcxZ5BYjIJvCOr2L gcQSPqh40fmQ32HjGk5GCDmyL02pplGRNaX0g/ynsdQwjMHzWgUKIw1oIlYBIrR48hOy BtRQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=hZfVlHpC; spf=pass (google.com: domain of billymacdo@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=billymacdo@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763847664; x=1764452464; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=1JSjyDc0NH0l/8qaWa9ax5BR+cHKP9TH2m+pCmZ49UU=; b=LXEpBxtgDM0dy5pmYRgjRNhNcC1Jfv3WhRcHRcwtLmSfSuSngza0aYbDVMmx2U+idz pWB0jPSJwwSFrh5eXPwOOd65Pa5pCJ8ZhUNmIwLdSzAa3UggW+N0qFj5QShVzvN5SAeM LW27qfXxoaspCegA6AFwhM5o+i2DiD8zDKghLfEPuF/ARMn+DMrxvhtK+MVhdVIAQXG4 O20LM06i1YDvGLoR1mKXJy0orNpppUMk7tjfc6ET7q0b/7BMFWcBSYSaRY58Nz9nzNWO aSowb8ITyOAmUML6vQHsGjAhp60/F8J/KG24dXbs5YZcx/nmCu5QlSoid1fzw5yzIZQ5 M2iQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763847664; x=1764452464; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1JSjyDc0NH0l/8qaWa9ax5BR+cHKP9TH2m+pCmZ49UU=; b=W9vDIxE91urhBJqULb2VFJHYSncwbT/dmPLO8vXsxr76BL/fIezUYtY7ZB8I/laF8s GZxEY6/MwLiueBwSaIyuIN1PtXT09hIvrTbwQeVp7/6I0kbcSO+6k1VDFF0sPUxg7jLw FvSmQG+uIZtfgN7shRpwp8jlqFuBW+PuEVDBNRdJd9fMuthkrfFYZU/Xf3cUH7rdGf+4 j64CzMQ73guTD9UOTEALQQOzbSMS6uvqsYNTXwkvVWuq3pqjrBJu/wLrFNmXyQhMjtvd spwsEZI3anvDjGZvPE9GeZefJK8MC17YDlPGvLEVszGEmoMKxHzb/i5raLXSKFlmO84w jGvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763847664; x=1764452464; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=1JSjyDc0NH0l/8qaWa9ax5BR+cHKP9TH2m+pCmZ49UU=; b=OLE8nv14MYoQEJ1hrmsxwBo422t0Xp6ny3ky/WnlauOZWBV5FqSPU6Y0/HgvvStKdp M+AaHPulk+Lg5t3s8HOjEtgSyY0SXAOQMOkxnMFKiSAbrtpwrdG2AA7M2XtZ/BNVJJBb wjgvd8Hjjdn+SE7KCmviC0rUIdeCKecv4p50Q3HkevTDgQncwHyKCW7YWWLVCnxPnWid hYIVyIeH0ZTHKf+fMTWWIAuGGUN6tGUhKoQz8vZMOvA+UNySqkQlhQZib1iq9043abId q3a4of+dWvq4DA5MlGmsIRBgn8mevjRYvrHCrP4ALyDLrNB5gwjSPg5lAkKHvk7jHnm0 yl7Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXW0T42ASqCMqHijNy6uCbJJoBYYodJJeRfdotP2Mn1YLH9yJcGKhDYhqKWrBcRG7fK58sAy2H8FyDP@gnusha.org X-Gm-Message-State: AOJu0Ywe5ie5xHZhj0RmlbBXyyaUvHzVnSMOOXcs/CdVTKsDRksW6LZJ A/dzzFdJrteneg9XGaIUNOO6ckd9RRUnMAKi9luZ5fP45BfeFXjMhKYy X-Google-Smtp-Source: AGHT+IHBDXMJeNy1KeEQHhPLNtaCce3OAGc1TYNP7KTgXOmybajpPnbWeY2nEKCO1LwB9vr+aFcocA== X-Received: by 2002:a05:6871:c1c4:b0:3ae:f15:5dfa with SMTP id 586e51a60fabf-3ecbe51b570mr3038597fac.28.1763847663587; Sat, 22 Nov 2025 13:41:03 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bC1VIsKhLPIhCp4xkQFrYqWpWm5evDB/qSsU/62hysqw==" Received: by 2002:a05:6870:a688:b0:331:5ba5:afd3 with SMTP id 586e51a60fabf-3ec9b404c81ls1910966fac.1.-pod-prod-07-us; Sat, 22 Nov 2025 13:40:59 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXT/YgWBQBZ4BbJP7uTzad+QOGDLm5mz5lAyhATStSuti5CpwU3kSGDc7Z5Zv/RY3QAnOk4i+pvH86f@googlegroups.com X-Received: by 2002:a05:6808:14c7:b0:450:3fb0:6dd1 with SMTP id 5614622812f47-45112976947mr3434252b6e.20.1763847659359; Sat, 22 Nov 2025 13:40:59 -0800 (PST) Received: by 2002:a7b:c055:0:b0:471:13aa:415a with SMTP id 5b1f17b1804b1-477bfdf813ams5e9; Sat, 22 Nov 2025 13:06:45 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWND0PEQbUOqYFqu1DVXOCo47Hi2jZ2BOoG8yj9rvMAnUJnSZ06uuU0CeRkNLvvB0nEIZGbELn5L4ln@googlegroups.com X-Received: by 2002:a5d:64c3:0:b0:429:ccd7:9d94 with SMTP id ffacd0b85a97d-42cc1d217demr7155472f8f.51.1763845603202; Sat, 22 Nov 2025 13:06:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763845603; cv=none; d=google.com; s=arc-20240605; b=NUtA9rpo0mFlWtOYxiYcTB+hFmncJtXnRnqCs4UoRXTmpz/lhne1gAfKW7IlIAvFhh Apz4K0ILC3Yi8r53VJjZV8qgT1lj+BwZto5SDM32+Yckz+rngw/IMF/EeHH0Ko0t6Izw m0ZNHDbrz7zsk4jtK1+8myQCIEi01fPXIJPspLsq6O/dt+KfYP1zUe8WD7BCP0TacHbt 1x7MHgOMnulQfveIqBp9IZ6MBMf37qcZ3+fy0wd2DNTUovSrQbMZqcHiAK0y/wSh/LIX OCNcBeRt/jSDE/FnsIfL+ZSth8XBGJqCiDX5+kXSrBVqZVGj4ezNUrFNvSjQse7BcP8G 721A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=QilLIX1HoOPjdKkUyCgYM22SG03ePyR/MG1djZMPStY=; fh=2cbRusZYteTm57kw9PYnocxlramyaV7VK3dXKAs/IuA=; b=VoRmLpGmFxeOGpdVrYyGGuDpUFJYWtyw19q7u5kXB1uGIvJNrXvsBoYJu6cM6ruIWY s+8/n45irGW3D79S0nCedkho25XdYwxK0L9HhrAa5NYN19L48XfxnKFE6E6SUzebomtF 8cgi/qWgaUN3WI9M6DiStYQMVrntjYVfNh7mLeig5av8mxTdcUoLDP1riMPgudTiu/zE xKcd1VjR4PE58RhITZaEWkPTg16uWcY3SQb3WzwTa/1VzbGXV28GIqL3+1Qi/ET1n9jy ftw+wNE4fkmti5fLNylR2sygAWsAREqfh5ISd45v1ZzLU+gzNZzBPY4XkJjEbp2LNdwV gCzw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=hZfVlHpC; spf=pass (google.com: domain of billymacdo@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=billymacdo@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com. [2a00:1450:4864:20::62b]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-42cb7eb42f2si155641f8f.0.2025.11.22.13.06.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Nov 2025 13:06:43 -0800 (PST) Received-SPF: pass (google.com: domain of billymacdo@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) client-ip=2a00:1450:4864:20::62b; Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b739b3fc2a0so439375566b.3 for ; Sat, 22 Nov 2025 13:06:43 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWCb499wFhygURLfhRBT+oEprIVZh2CXJs0AVcdMiEWqEp6ekGzNosoARg78TkAaXpbL/tPFe6v8uVc@googlegroups.com X-Gm-Gg: ASbGncuzGRHXdEHVVykdSCt7gODOp/DZuksnodRL32rTQB++HO1P+JLaqpvHSSQ95Xb GJLyWOfmxCnwG9gnnq6/9pfqX/+5LuOSPGIvQ5ROkHkwdNGBF+zSX7XaaLYRfhpmZqIvqwSYG9g sGrSQoM+ITwSRo1OZcuJVDQEdhOAQ4+cPPUkyujEyIbyeY4js+gyT2DBWLuJmkQABhGUIC4T5/s L416cGFj4f6TkrI9YB7DcfBdgvA1Hat5zjsBJOdxRYYCf1aFQSYHIfTl13zOHJj+F3Zzd8sa1/N kSRSZqBx4aLKbPox9PzQ39xMx7E= X-Received: by 2002:a17:907:d1a:b0:b72:de4f:cea6 with SMTP id a640c23a62f3a-b76718cf709mr774061566b.48.1763845602295; Sat, 22 Nov 2025 13:06:42 -0800 (PST) MIME-Version: 1.0 References: <205b3532-ccc1-4b2f-964f-264fc6e0e70b@murch.one> <3a66dbbe9a9c46566c8a9a16ccb1cc91@dtrt.org> <012c719c-0f56-474d-8851-a2db3a0b422cn@googlegroups.com> <27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn@googlegroups.com> <0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42@sprovoost.nl> In-Reply-To: <0B127C48-9B11-4AAA-9F3E-B9BE3CD42F42@sprovoost.nl> From: Bill MacDonald Date: Sat, 22 Nov 2025 13:06:31 -0800 X-Gm-Features: AWmQ_bkPdGOcOc4XRNeMqMtnaiA8Cp-x-zk4ZjFwrLzalkiXQzRgvIzfbCwzwGA Message-ID: Subject: Re: [bitcoindev] Motion to Activate BIP 3 To: Sjors Provoost Cc: Jon Atack , Greg Maxwell , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000009042a70644354e9c" X-Original-Sender: billymacdo@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=hZfVlHpC; spf=pass (google.com: domain of billymacdo@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=billymacdo@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000009042a70644354e9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There=E2=80=99s no real incentive for anyone to disclose their use of an LL= M or any future assisting technology. If I=E2=80=99m a good actor and write a good BIP (good meaning compliant an= d high-quality), disclosing LLM usage doesn=E2=80=99t help my BIP get reviewe= d. 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=E2=80=99m a good actor and write a bad BIP, it gets ign= ored either way. And if I=E2=80=99m a bad actor and write a good BIP then I=E2=80=99m not go= ing to disclose that I used an LLM simply because I don=E2=80=99t want to. The same applies= if I=E2=80=99m a bad actor writing a bad BIP. This discussion isn=E2=80=99t really about AI. It=E2=80=99s about what Sjor= s describes as =E2=80=9Clow-effort contributions,=E2=80=9D regardless of the tool used Kanzure identified it correctly: =E2=80=9CIt doesn't matter if it's LLM generated slop or non-LLM slop, slop= is still slop.=E2=80=9D I think removing the disclosure requirement and including a general warning like Sjors=E2=80=99 makes sense and is transparent. On Sat, Nov 22, 2025 at 12:38=E2=80=AFPM Sjors Provoost 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 enforc= e > 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. A= ll > 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 a= re > 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 het > volgende geschreven: > > > > The fundamental problem at this time is that prospective authors want t= o > 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 analy= ze > and auto-close those submissions relatively reliably and fairly. Even wit= h > AI tooling to help, who wants to spend their time reviewing LLM content o= r > 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 beco= me > 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 m= ay > be helpful to clarify for now in BIP 3 that such submissions are likely t= o > 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=E2=80=AFPM UTC-6 Greg Maxwell w= rote: > > Because if you don't you'll eventually get figured out and people will > ignore all your further submissions--- in fact, that will *already* happe= n, > 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=E2=80=AFAM Oghenovo Usiwoma > 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=E2=80=AFAM Bitcoin Mechanic > wrote: > > I think it makes sense to request that submissions should state if - an= d > to what degree - AI has been used. It's reasonable to expect fewer eyebal= ls > 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 tweakin= g > 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=E2=80=AFPM UTC-8 Bitcoin Err= or 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 al= l > 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. The= se > newer BIPs are increasingly technical, and I have also started vibe-codin= g > 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 specificall= y > 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 tha= n > 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 t= o > the people, not only the specs. > > > > After all, we will need people to replace you some day, and those peopl= e > 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 > 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 i= n > 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 a= re > 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 t= o > be absolutely the worst to deal with. Because they're not submitting thei= r > 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 struggle= d > 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 t= he > 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=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 > > 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 refin= e > > the document until I was satisfied. > > > > I would, of course, review every word of the draft BIP before submittin= g > > 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 wh= o > > 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 w= e > > 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 an= d > > 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/3a66dbbe9a9c46566c8a9a16ccb1= cc91%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%3DXdmY= f5CvrvXWXsjVD07uynivW_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-a2db= 3a0b422cn%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%3= DHtFnDeb92D_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-cf3f= bbe5fafdn%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-B9BE= 3CD42F42%40sprovoost.nl > . > --=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/= CADitH-yoK6ZbieG1GqXvDaLTbwboxi9cMDwegvF%2BU1KRXWxx1g%40mail.gmail.com. --0000000000009042a70644354e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There=E2=80=99s no real incentive for anyone to disclose th= eir use of an LLM or any future assisting technology.

If I=E2=80=99m a good actor and write a good BIP (good mean= ing compliant and high-quality), disclosing LLM usage doesn=E2=80=99t 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 refi= ning it. That process, along with the quality of the work, is what leads to= a review.

Alternatively, if I=E2=80=99m a good actor and write a bad = BIP, it gets ignored either way.

And if I=E2=80=99m a bad actor and write a good BIP then I= =E2=80=99m not going to disclose that I used an LLM simply because I don=E2= =80=99t want to. The same applies if I=E2=80=99m a bad actor writing a bad = BIP.

This discussion isn=E2=80=99t really about AI. It=E2=80=99s= about what Sjors describes as =E2=80=9Clow-effort contributions,=E2=80=9D = regardless of the tool used

Kanzure identified = it correctly:

=E2=80=9CIt doesn&#= 39;t matter if it's LLM generated slop or non-LLM slop, slop is still s= lop.=E2=80=9D


I think removing the disclosure requirement and includi= ng a general warning like Sjors=E2=80=99 makes sense and is transparent.



On Sat, Nov 22, 2025 at 12:38=E2=80=AFPM Sjors Provoost &= lt;sjors@sprovoost.nl> wrote:<= br>
Why not have a simple rule which states that &quo= t;low effort contributions, such as fully LLM generated proposals, may be i= gnored without a full reading".

That should give BIP editors permission to use tools to detect and auto-clo= se such content. They need to detect it anyway in order to enforce the prop= osed rule (of not allowing it).

Judging effort is subjective, just like judging quality (an existing criter= ion), 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 overzealo= us. If an author believes their proposal was unfairly closed they can demon= strate their effort, e.g. link to a conference talk about the topic, have s= omeone 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 takedow= n notice for a particular BIP, just take it down, and then either start a l= egal fight or rewrite it in different words. We're not talking about pa= tents 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 somet= imes when they should know better), so unfortunately they're only benig= n to use in the hands of those whose need is the least.=C2=A0

This is indeed an issue and also applies to high effort contributions, wher= e 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 s= uperfluous or incorrect paragraphs. So I would expect that actually importa= nt 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 submi= ssions and the few experienced reviewers available to review the submission= s at an asymmetric disadvantage... until or unless AI can analyze and auto-= close those submissions relatively reliably and fairly. Even with AI toolin= g 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 pe= rsonal referrals/recommendations to review are therefore likely to become e= ven more important. Maybe this should this be expressed in BIP 3 to set exp= ectations.
>
> We have seen a wave of BIP draft PRs opened by new GitHub accounts wit= h no history or proof of work and often appearing to be LLM-generated. It m= ay 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=E2=80=AFPM UTC-6 Greg Maxwell = wrote:
> Because if you don't you'll eventually get figured out and peo= ple will ignore all your further submissions--- in fact, that will *already= * happen, which is part of why the guidance is useful.=C2=A0 No one is obli= gated to even read any of these submissions and if indeed there are many lo= w 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=E2=80=AFAM Oghenovo Usiwoma <eun...@gmail.com> wro= te:
> > I think it makes sense to request that submissions should state i= f - and to what degree - AI has been used. It's reasonable to expect fe= wer 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 e= asiest method available to them to achieve their goals. If we agree that hu= mans 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" t= o my BIP when I know that it will cause reviewers to ignore it?
>
> On Thu, Nov 20, 2025 at 3:18=E2=80=AFAM Bitcoin Mechanic <bitcoin...@ocean.xyz= > wrote:
> I think it makes sense to request that submissions should state if - a= nd to what degree - AI has been used. It's reasonable to expect fewer e= yeballs 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 tha= t obviously undermines what it is they're proposing so they're natu= rally disincentivized to do so, thus the honour system should be relatively= effective.
>
> I think most people have begun using it for making outlines and tweaki= ng from there. The time saved is too significant for many to resist, and de= claring that it was used for an initial outline shouldn't be too dissua= sive 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 ph= ilosophical 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 Er= ror Log wrote:
> A few years ago, I had this idea that bitcoin divisibility needed to b= e fixed as a misconception. I put it (proto-bip177) in our bitcoin wallet a= pp, promoted the idea where I could. It worked great, but only our users kn= ew.
>
> And then AI became good enough to use for some things. AI has been a H= UGE unlock for me and my learning and creating style. Early this year, I to= ld my AI, filled with context about the upcoming BIP3 standard, and example= s 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 t= he formatting was total slop. Thankfully, most of the BIP reviewers are act= ually amazing people, and I was able to contact them directly and ask for h= elp, 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 ma= ke it better if I started today, but ... it exists! It might be the first/o= nly (?) 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 B= itcoin Core. I feel sincere gratitude to three BIP reviewers specifically f= or humoring my sincere, yet not matured, effort and desire to improve Bitco= in without changing consensus code.
>
> My vision for the BIP repo and reviewers, and AI, is much different th= an yours. It is part of the story that brought me closer to Bitcoin develop= ment, and deep respect to my superiors for tolerating me while I was/am fle= dgling.
>
> Please don't add more weird subjective, exclusive barriers just be= cause AI is warping reality. Deal with it, and please, please, continue mak= ing an effort to not only guard the BIP repo, but ensure it remains a ferti= le 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 peop= le need role models too.
>
> ~John Carvalho
>
>
> On Wed, Nov 19, 2025 at 1:18=E2=80=AFAM Greg Maxwell <gmax...@gmail.com> wrote:<= br> > No doubt *you* are able to make good documents with or without the aid= of AI.
>
> With outright AI 'authorship' you immediately run into potenti= al 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 L= LM 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 subm= issions that could be made would hardly be increased by LLMs (being limited= by expert proposers with good ideas) but the number of potential poor subm= issions is increased astronomically.=C2=A0 So I think it's pretty clear= ly a net harm to have text authored that way.
>
> I've never had an impression that drafting was at all a limiting s= tep 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 ea= sier ("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 somet= imes when they should know better), so unfortunately they're only benig= n to use in the hands of those whose need is the least.=C2=A0
>
> And as a reviewer outside of Bitcoin I've found LLM powered propos= ers to be absolutely the worst to deal with. Because they're not submit= ting their own words and ideas, they're unable to change their thinking= in response or explain sufficiently to change yours--- the interactions of= ten 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 ou= t with documents several times longer than any human author would have both= ered 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.=C2=A0 Many projects, including, Bitcoin have long strug= gled with review capacity being limited and a far amount of time waste by t= houghtless (or even crazy!) submissions, but now it's automated and eve= n 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 befo= re lunch without even breaking a sweat.
>
>
>
> On Wed, Nov 19, 2025 at 12:06=E2=80=AFAM David A. Harding <da...@dtrt.org> wrote:<= br> > On 2025-11-04 15:10, Murch wrote:
> > Summary of changes since BIP=E2=80=AF3 was advanced to Proposed:<= br> > > [...]
> >=C2=A0 =C2=A0- that BIPs submissions may not be generated by AI/LL= M=E2=81=B5
> > [...]
> > =E2=81=B5 https://github.com/bitcoin/bips/pull/20= 06
>
> 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 as= k it to
> help me create a todo list of what should go in the BIP; I'd ask i= t to
> create a draft based on existing BIPs, my todo list, and whatever othe= r
> 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 submitti= ng
> it for consideration and ensure that it represented the highest qualit= y
> work I was able to produce---but the ultimate work would be a mix of A= I
> and human writing and editing.
>
> I think considerate use of AI would be even more valuable for people w= ho
> are less comfortable with writing technical English-language documents=
> than I am.=C2=A0 For example, non-native literates, people with disabi= lities
> 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 motivati= on,
> although it references a previous discussion[1] where a low-quality BI= P
> PR was opened using mostly AI-generated content.=C2=A0 I'm guessin= g 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 c= an be
> high-quality, especially if its creation and editing was guided by a <= br> > knowledgeable human.=C2=A0 Banning specific tools like AI seems redund= ant 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 pul= l
> request to the BIPs repository." --BIP3, emphasis added
>
> --
> You received this message because you are subscribed to the Google Gro= ups "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/3a66dbb= e9a9c46566c8a9a16ccb1cc91%40dtrt.org.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "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%4= 0mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "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/bitco= indev/012c719c-0f56-474d-8851-a2db3a0b422cn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "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 Gro= ups "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/bitco= indev/27b2b0ba-ba85-41f5-96b8-cf3fbbe5fafdn%40googlegroups.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0B12= 7C48-9B11-4AAA-9F3E-B9BE3CD42F42%40sprovoost.nl.

--
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/bitcoindev/CADitH-yoK6ZbieG1GqXvDaLTbwboxi9cMDwegvF%2BU1KRXWxx1g%40ma= il.gmail.com.
--0000000000009042a70644354e9c--