08:20 <willcl-ark> maflcko: Would there be any downsides to pruning the fuzz inputs say twice per release cycle? Some of the fuzz CI runtimes are getting quite long e.g. https://willcl-ark.github.io/bitcoin-core-ci-stats/graph/execution/#MSan,%20fuzz

11:08 <fanquake> Does anyone use openrc? Might want to review: #35978

11:08 <corebot> https://github.com/bitcoin/bitcoin/issues/35978 | contrib/init: fix unused variables in openrc script by jpk68 · Pull Request #35978 · bitcoin/bitcoin · GitHub

11:28 <dergoegge> https://gist.github.com/dergoegge/84a77eb85d90ca5cb70c60481c3e8f40 would be curious to hear thoughts on this

11:50 <fjahr> I think you mean "decrease the likelyhood" in bullet 4?

11:54 <fjahr> Just fix it all doesn't seem workable if we want to still make progress on bigger projects and not lower the level of human scrutiy on each change, so I don't think that is acceptable. I would guess that moderation of these kinds of reports could be mostly automated though by checking new issues against existing issues that were closed with won't fix (or issues in the public repo you mentioned)?

12:18 <dergoegge> Yes, decrease

12:51 <_aj_> dergoegge: hot take: have the AI prioritise them, and look through open issues/PRs for duplicates. any that are already reported, add any additional info project loupe found, and/or a generic +1. once that's done, make sure there are open issues/PRs for the five highest priority. as those get resolved, open new issues for the new five highest priority until they're all fixed/not-a-bug'ed.

12:56 <_aj_> dergoegge: (prioritse == rank in importance from 1..100, not just "low/medium/high/critical". maybe should have a 2d severity covering both difficulty-to-trigger/impact-when-triggered)

13:58 <sipa> github down for everyone?

13:58 <brunoerg> yes

14:02 <_aj_> only mostly dead, which means slightly alive

17:13 <nkaretnikov> _aj_: agree. the only question is who is going to pay for all these tokens, especially if the volume grows over time

17:15 <nkaretnikov> also, it would only matter if ai is able to get these into a mergeable shape, so that when a maintainer opens one, it’s only necessary to click on the merge button most of the time

17:17 <nkaretnikov> another thing you could potentially do is to add a claude.md or an equivalent file that would be picked up by ai (that these reporters use) that would instruct on what issues not to report. this will hopefully prevent people from submitting the same issue 20 times that you have no intention of merging anyway

18:43 <achow101> dergoegge: I think we should just open issues for them, even if they never get fixed or get closed as won't fix. Reporters need to be looking through previously reported issues before opening a new issue and stop opening duplicates.

18:59 <jonatack> achow101: agree

19:32 <lightlike> achow101: I dont think that is the issue: if we open 100 issue for all of them in one go, there will be almost as many AI-generated PRs by new contributors / drive-by AI bots etc. - who is going to review all of these?

19:33 <achow101> lightlike: close all those prs for violating the ai policy

19:33 <achow101> and make drahtbot more aggressive and closing things

19:42 <sliv3r__> can we maybe group them in one big issue by topic and severity, and hide the details under <details>? Idk if github has a max text lenght in descriptions.

19:42 <lightlike> I think I'd prefer a release in batches (by priority) to that.

19:43 <sliv3r__> I agree with opening issues for them, they serve also serve as documentation

20:32 <l0rinc> dergoegge: dergoegge/loupe-bitcoin-core-public#1 is already worked on in https://github.com/bitcoin/bitcoin/pull/35752 (just converted to draft because of review, will push an update soon)

20:32 <corebot> l0rinc: Error: That URL raised <HTTP Error 404: Not Found>

20:43 <l0rinc> Agree with achow101, the Red Team also has a lot of findings that we're reviewing, most of them seem minor, but real bugs, we should eventually fix most of them. We're already prioritizing them with other AIs, but if we only fix the serious ones we'd reveal which ones we consider serious, so I still think we should fix most of these one by one. Also, serious vulnerabilities are usually built by chaining many simple ones, so we shouldn't neglect

20:43 <l0rinc> them just because they're not imminent threats. I expect capable AIs to be able to chain the minor findings very efficiently, so I think we should prioritize fixing and reviewing them.

21:44 <pinheadmz> think i need a restart here, looks like a cache error?

21:44 <pinheadmz> https://github.com/bitcoin/bitcoin/actions/runs/32064923738/job/95494585601?pr=35730

21:52 <sipa> pinheadmz: done

21:59 <pinheadmz> Tank ewe !

22:35 <l0rinc> bitcoindev1337: had to wait until others exhausted the boring PR numbers, pushed your idea as #36000.

22:35 <corebot> https://github.com/bitcoin/bitcoin/issues/36000 | validation: prefetch blocks while connecting by l0rinc · Pull Request #36000 · bitcoin/bitcoin · GitHub

22:35 <l0rinc> I'm still running some benchmarks to fine-tune the thread count, but the end result is very simple now that the machinery was already committed earlier.