.
. #35291
pull taserz wants to merge 1 commits into bitcoin:master from taserz:fix/p2p-oversized-notfound changing 2 files +18 −7-
taserz commented at 5:47 PM on May 14, 2026: none
- DrahtBot added the label P2P on May 14, 2026
-
DrahtBot commented at 5:47 PM on May 14, 2026: contributor
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
Code Coverage & Benchmarks
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35291.
<!--021abf342d371248e50ceaed478a90ca-->
Reviews
See the guideline for information on the review process. A summary of reviews will appear here.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
-
97941ce774
p2p: ban peers sending oversized NOTFOUND messages
NOTFOUND is sent in response to GETDATA, which is capped at MAX_INV_SZ (50000) items. A NOTFOUND with more items than MAX_INV_SZ is therefore impossible from a well-behaved peer, just as it is for INV and GETDATA, both of which already call Misbehaving() for this case. The previous handler allocated a full std::vector<CInv> before checking its size, allowing a peer to force up to ~4 MB of allocation (bounded only by the network message size limit). Fix this by reading the compact size prefix first and only deserialising items if within bounds, avoiding the allocation entirely for oversized messages. While here, move ReceivedNotFound() and its lock inside the conditional block so the mutex is not acquired when there are no items to process. Fixes #34771
- taserz renamed this:
p2p: discourage peers that send oversized NOTFOUND messages
p2p: ban peers sending oversized NOTFOUND messages
on May 14, 2026 - taserz force-pushed on May 14, 2026
-
maflcko commented at 5:56 PM on May 14, 2026: member
Thx, but LLM output is not accepted if the author can not properly explain, test or could have written the change themselves.
The bottleneck in this project has always been review and testing, not writing code. Development here is intentionally conservative and slow, and reviewer attention is the scarcest resource we have. LLMs have made this worse, anyone can now prompt them and post their output as PRs. There is an infinite amount plausible looking "improvements" for LLMs to suggest and work on.
Unless we fully trust LLMs to both write and review code, humans still have to spend time understanding the proposed changes, which incurs a non-zero cost for every opened PR.
I understand that contributing to this project can be intimidating, and using LLMs may seem tempting, but it really creates more issues for this project than it solves. The best way to help this project, is to review and test changes. You can use LLMs for this, but you shouldn't solely rely on them, or just post their output.
I'm not asking you to close this PR. I am asking you to reconsider whether it's something you genuinely think the project should pursue, independent of what your LLM suggested.
- maflcko closed this on May 14, 2026
- fanquake renamed this:
p2p: ban peers sending oversized NOTFOUND messages
.
on May 18, 2026 - DrahtBot removed the label P2P on May 18, 2026
- bitcoin locked this on May 18, 2026
