16:00:02 <stickies-v> #startmeeting 
16:00:02 <corebot> stickies-v: Meeting started at 2026-06-11T16:00+0000
16:00:03 <corebot> stickies-v: Current chairs: stickies-v
16:00:04 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:05 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:06 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:11 <janb84> hi
16:00:12 <sedited> hi
16:00:18 <stickies-v> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields danielabrozzoni darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar sedited S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack
16:00:18 <stickies-v> vasild willcl-ark
16:00:19 <Murch[m]> hi
16:00:23 <instagibbs> hi
16:00:25 <stringintech> hi
16:00:25 <cfields> hi
16:00:30 <stickies-v> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:00:32 <hebasto> hi
16:01:15 <pseudoramdom> hi
16:01:17 <andrewtoth> hi
16:01:29 <hodlinator> hi
16:02:03 <stickies-v> small meeting today, let's get started with the WGs
16:02:06 <stickies-v> #topic Kernel WG Update (sedited)
16:02:13 <sedited> nothing to share this week
16:02:17 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:02:22 <sliv3r__> hi
16:02:26 <andrewtoth> l0rinc opened #35465 to address the compaction.
16:02:29 <corebot> https://github.com/bitcoin/bitcoin/issues/35465 | coins: compact chainstate regularly after post-IBD flushes by l0rinc · Pull Request #35465 · bitcoin/bitcoin · GitHub
16:02:32 <andrewtoth> willcl-ark discovered a speed regression https://github.com/bitcoin/bitcoin/issues/35457. l0rinc is looking into ways to resolve that.
16:02:41 <andrewtoth> Got some good review on #35295. We are also now continuously fuzzing leveldb along with concurrent reads, which is used for chainstate reads in that PR. More review welcome.
16:02:45 <corebot> https://github.com/bitcoin/bitcoin/issues/35295 | validation: fetch block input prevouts in parallel during ConnectBlock by andrewtoth · Pull Request #35295 · bitcoin/bitcoin · GitHub
16:02:51 <andrewtoth> that's it
16:03:34 <kanzure> hi
16:03:35 <dergoegge> hi
16:04:14 <stickies-v> #topic Fuzzing WG Update (dergoegge)
16:04:28 <dergoegge> no update
16:04:57 <eugenesiegel> hi
16:05:43 <stickies-v> I don't see any other WG leaders here, so that concludes the WG section unless anyone pops in last-minute
16:05:55 <stickies-v> Anything else to discuss?
16:06:07 <andrewtoth> Can we consider merging https://github.com/bitcoin-core/bitcoincore.org/pull/1255 and making a mailing list post?
16:06:42 <sedited> not sure if that makes sense without a release.
16:07:06 <andrewtoth> Do we want to let users know about workarounds before a release?
16:07:41 <stickies-v> alerting earlier seems useful to me too, especially since the vulnerability is public already anyway
16:07:42 <sliv3r__> I think it makes sense anouncing before a release
16:07:54 <andrewtoth> I don't think that blog post would make sense as is with a release, since the best workaround would be to upgrade
16:08:48 <sliv3r__> agree, didn't read in detail the post but it basically gives workarounds until a fix is released, makes sense to publish it as soon as it is ready
16:09:48 <stickies-v> i think it would be useful if more contributors at least concept ack'd blog posts, not that this one seems controversial
16:10:10 <sedited> ok
16:10:48 <eugenesiegel> should this not have been public? afaict the security mailing list isn't for privacy issues. anybody have an idea on the preferred way to handle this?
16:11:26 <andrewtoth> all things considered it would be better IMO if this were not yet public
16:11:45 <andrewtoth> but, not sure how we would have made a fix without revealing it
16:12:51 <instagibbs> there are ways of doign so, but horse is out of the barn long ago
16:13:05 <andrewtoth> since it is public, it would be good to get info about it out
16:15:18 <stickies-v> alright, looks like we're done here. thanks for bringing it up andrewtoth
16:15:25 <andrewtoth> what is holding up a 31.1 release?
16:15:31 <Murch[m]> 31.1 should be out soon, right?
16:15:37 <stickies-v> (okay not done)
16:15:43 <Murch[m]> I just took a look at the milestone, all the todos seem to be checked off
16:16:27 <dergoegge> eugenesiegel: This was fine to be public imo
16:16:30 <sedited> I think we were waiting on #35465
16:16:33 <corebot> https://github.com/bitcoin/bitcoin/issues/35465 | coins: compact chainstate regularly after post-IBD flushes by l0rinc · Pull Request #35465 · bitcoin/bitcoin · GitHub
16:16:33 <Murch[m]> Ah sorry, the list of backports refers to merged PRs, but the PR is still draft
16:16:37 <Murch[m]> https://github.com/bitcoin/bitcoin/pull/35331
16:16:51 <andrewtoth> #35331 
16:16:53 <corebot> https://github.com/bitcoin/bitcoin/issues/35331 | [31.x] Backports by fanquake · Pull Request #35331 · bitcoin/bitcoin · GitHub
16:17:27 <andrewtoth> Please review 35465 then
16:19:46 <stickies-v> anything else here? otherwise i'm wrapping up
16:20:52 <Murch[m]> I though https://github.com/bitcoin-core/meta/issues/46 was an interesting question.
16:21:33 <Murch[m]> While it seems reasonable to judge code contributions on their own merit, it also seems reasonable that extremely uncharitable behavior in other avenues should at some point be addressed.
16:22:33 <Murch[m]> Anyway, if people haven’t seen that conversation yet, maybe take a look
16:23:07 <Murch[m]> :s/though/thought/
16:23:47 <instagibbs> thanks for bringing it up
16:24:47 <Murch[m]> Like, more concretely, if someone has been accusing us (without evidence) of crimes and shitting on our project in public for years, why should we continue to platform them in our repository?
16:25:48 <Murch[m]> I can’t think of any other situation in life where this sort of behavior would be acceptable
16:27:44 <stickies-v> so if someone is an asshole in real life, but contributes a good patch, we should not merge it because they're an asshole?
16:27:48 <stickies-v> that seems unworkable to me
16:28:21 <Murch[m]> I don’t think your description of the situation matches what’s going on
16:30:03 <Murch[m]> Anyway, I think that a ban would be in order. I don’t understand why we continue to subject ourselves to this person.
16:32:50 <stickies-v> maybe i missed a recent conversation or incident but i'm not getting it
16:33:03 <stickies-v> happy to review an issue or PR if there is one, i just subscribed to the meta repo
16:33:17 <stickies-v> it looks like we're done here, so i'll wrap up
16:33:19 <stickies-v> #endmeeting