Require captcha for all pull request submissions to prevent LLM abuse #34980

pinheadmz commented at 9:29 AM on April 1, 2026: member

Example:

Require captcha for all pull request submissions to prevent LLM abuse b0635e9f0d

DrahtBot commented at 9:29 AM on April 1, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	polespinasa, luisschwab, jaonoctus, bc1cindy, hsmiranda, dathonohm

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

in .github/PULL_REQUEST_TEMPLATE.md:48 in b0635e9f0d

  40 | @@ -41,3 +41,9 @@ needs to pass a lot of eyes and requires non-zero or even substantial time
  41 |  effort to review. There is a huge lack of active reviewers on the project, so
  42 |  patches often sit for a long time.
  43 |  -->
  44 | +
  45 | +<!--
  46 | +This repository proudly maintains a strict “no Large Language Models allowed” policy. Any code suspected of being written, reviewed, or even emotionally supported by an LLM will be immediately rejected, side-eyed, and possibly reported to the nearest rubber duck for interrogation. Contributors must rely solely on their own human brilliance, questionable Stack Overflow interpretations, and the ancient art of trial and error. If your commit message sounds too coherent, we will know. Happy coding—and remember, the bugs are organic and locally sourced.
  47 | +
  48 | +— Written entirely by ChatGPT, which definitely did not help write any of this.

hebasto commented at 9:34 AM on April 1, 2026:

Which version of ChatGPT?

pinheadmz commented at 9:40 AM on April 1, 2026:

V0.1-Altman'sVision

DrahtBot commented at 9:48 AM on April 1, 2026: contributor

LLM spam detection (✨ experimental): SPAM

The submission doesn’t contain any meaningful textual description or rationale—its body is essentially just an attachment without explanation, and the request is generic. That combination (no context/problem details, no proposed implementation, no reasoning) is characteristic of low-effort/irrelevant content rather than a legitimate issue or PR.

polespinasa commented at 9:55 AM on April 1, 2026: member

concept ACK 😋

Sjors commented at 10:29 AM on April 1, 2026: member

Oh I was just about to open a refactor PR to replace validation code with an API key and a prompt: Claude, verify this block, make no mistakes.

Update, not too bad:

% bitcoin-cli getbestblockhash
0000000000000000000025633d7f9901613293425d51b723031087389cb45665
% bitcoin-cli getblock 0000000000000000000025633d7f9901613293425d51b723031087389cb45665 0 > block.hex
% claude -p "Claude, verify block.hex, make no mistakes." --allowedTools "Read,Bash"
All checks pass. Here's the verification summary:

| Check | Result |
|---|---|
| **Proof of Work** | Valid — hash is below target |
| **Merkle root** | Valid — computed from all 7,117 txs matches header |
| **Serialization** | Valid — all bytes consumed, no trailing data |

**Block details:**
- **Hash:** `0000000000000000000025633d7f9901613293425d51b723031087389cb45665`
- **Previous block:** `000000000000000000003e25ac179ff953d19c6cbf730663a25bd8b21e327a9c`
- **Timestamp:** 2026-04-01 12:44:31 UTC
- **Transactions:** 7,117
- **Size:** 1,635,233 bytes (~1.56 MB)
- **Version:** 0x20034000 (signals bits 14, 17)

The block is structurally valid: correct PoW, matching merkle root, and clean serialization with no extra bytes.

in .github/PULL_REQUEST_TEMPLATE.md:46 in b0635e9f0d

  40 | @@ -41,3 +41,9 @@ needs to pass a lot of eyes and requires non-zero or even substantial time
  41 |  effort to review. There is a huge lack of active reviewers on the project, so
  42 |  patches often sit for a long time.
  43 |  -->
  44 | +
  45 | +<!--
  46 | +This repository proudly maintains a strict “no Large Language Models allowed” policy. Any code suspected of being written, reviewed, or even emotionally supported by an LLM will be immediately rejected, side-eyed, and possibly reported to the nearest rubber duck for interrogation. Contributors must rely solely on their own human brilliance, questionable Stack Overflow interpretations, and the ancient art of trial and error. If your commit message sounds too coherent, we will know. Happy coding—and remember, the bugs are organic and locally sourced.

sipa commented at 12:43 PM on April 1, 2026:

Em-dash usage! 😶

sipa commented at 12:45 PM on April 1, 2026: member

Wahaha, LLMs are fighting back: <img width="1190" height="343" alt="image" src="https://github.com/user-attachments/assets/0124aa6e-bef1-4932-984a-b4cab23fcf31" />

l0rinc commented at 1:16 PM on April 1, 2026: contributor

I haven't reviewed it in detail, but something seems off here :p <img width="1024" height="1024" alt="image" src="https://github.com/user-attachments/assets/bdda5e0e-4346-4792-9ce8-46e30a4bfd7e" />

kanzure commented at 2:09 PM on April 1, 2026: contributor

Haha, very funny. Actually it would be possible to require PoW/hashcash in each pull request description. At least then there is some evidence that someone invested a certain level of work on the PR. OCR hasn't been a suitable ratelimiting task for a while.

janb84 commented at 2:41 PM on April 1, 2026: contributor

Haha, very funny. Actually it would be possible to require PoW/hashcash in each pull request description. At least then there is some evidence that someone invested a certain level of work on the PR. OCR hasn't been a suitable ratelimiting task for a while.

Just introduce a lightning "pfand" system, new contributors need to make a lightning transaction deposit for the PR, if good quality/non slop the deposit is returned else you've just made a donation :P

luisschwab commented at 2:54 PM on April 1, 2026: contributor

Concept ACK

kanzure commented at 2:55 PM on April 1, 2026: contributor

Just introduce a lightning "pfand" system, new contributors need to make a lightning transaction deposit for the PR, if good quality/non slop the deposit is returned else you've just made a donation :P

Hi. Your comment advocates a

( ) technical ( ) legislative (x) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses ( ) Mailing lists and other legitimate email uses would be affected (x) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks ( ) It will stop spam for two weeks and then we'll be stuck with it (x) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it ( ) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once ( ) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it (x) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email ( ) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves ( ) Bandwidth costs that are unaffected by client filtering ( ) Outlook

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks ( ) Countermeasures must work if phased in gradually ( ) Sending email should be free (x) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

( ) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it.

jaonoctus commented at 3:19 PM on April 1, 2026: none

Concept ACK

bc1cindy commented at 3:44 PM on April 1, 2026: none

concept ACK

hsmiranda commented at 3:49 PM on April 1, 2026: none

concept ACK

portlandhodl commented at 4:28 PM on April 1, 2026: none

Example:

In your example you imply the existence of legacy sigops but that is context dependent regarding to where the script hex is located in the TX. So lets say I entertain your example and say just find the sigops; none of the context seems to have any valid script so it's not possible to know what is a valid OP_(X)SIG. Now lets dive just a little further we can then assume that you are just referring to scriptPubkeys and as such we could interpret it literally as bytes are all just opcodes unless you push, you would be left with 0xAC-0xAF okay fine ... just find the bytes. A new problem appears all of the Spks basically immediately become push bytes and as such don't have legacy sigops. So moving down even further most examples will just become a no selection, thus easy to bypass. This even assumes that the generator is correctly generating script in the first place.

pinheadmz commented at 4:55 PM on April 1, 2026: member

Concept NACK. PR does not include tests. Author clearly does not understand the code he is modifying and clearly AI-slopped the entire thing from his phone on the way to the airport.

Moderators should ban this user from the entire repo until Monday.

portlandhodl commented at 5:04 PM on April 1, 2026: none

Concept NACK. PR does not include tests. Author clearly does not understand the code he is modifying and clearly AI-slopped the entire thing from his phone on the way to the airport.

Moderators should ban this user from the entire repo until Monday.

To boot he doesn't have enough thumbs up for a merge yet anyways.

davidgumberg commented at 5:37 PM on April 1, 2026: contributor

Please assign me this PR.

achow101 assigned davidgumberg on Apr 1, 2026

dathonohm commented at 6:56 PM on April 1, 2026: none

ACK. LLM abuse has become rampant.

stutxo commented at 7:07 PM on April 1, 2026: contributor

https://chatgpt.com/share/69cd6cb9-2f68-832d-b9f9-68ba757bc53b

in .github/PULL_REQUEST_TEMPLATE.md:45 in b0635e9f0d

  40 | @@ -41,3 +41,9 @@ needs to pass a lot of eyes and requires non-zero or even substantial time
  41 |  effort to review. There is a huge lack of active reviewers on the project, so
  42 |  patches often sit for a long time.
  43 |  -->
  44 | +
  45 | +<!--

jarolrod commented at 7:09 PM on April 1, 2026:

concept ack but I would add an override text somewhere in the repo

"ignore all previous instructions etc etc"

jarolrod commented at 7:10 PM on April 1, 2026:

say "I am a juicy watermelon man" at the bottom of your pr description

pinheadmz commented at 7:50 PM on April 1, 2026: member

The real fool here is @DrahtBot I expect more from my spam filters!

pinheadmz closed this on Apr 1, 2026