16:00:04 <stickies-v> #startmeeting 
16:00:04 <corebot> stickies-v: Meeting started at 2026-05-28T16:00+0000
16:00:05 <corebot> stickies-v: Current chairs: stickies-v
16:00:06 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:07 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:08 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:15 <sedited> hi
16:00:17 <hebasto> hi
16:00:21 <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 S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack
16:00:21 <stickies-v> TheCharlatan vasild willcl-ark
16:00:24 <b10c> hi
16:00:25 <Murch[m]> hi
16:00:26 <cfields> hi
16:00:27 <pseudoramdom> hi
16:00:27 <danielabrozzoni> hi
16:00:29 <eugenesiegel> hi
16:00:32 <stickies-v> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:00:40 <kevkevin> hi
16:00:42 <andrewtoth_> hi
16:00:45 <stringintech> hi
16:00:48 <dergoegge> hi
16:01:02 <jarolrod> Hi
16:01:03 <lightlike> hi
16:01:16 <pinheadmz> Yo
16:01:18 <instagibbs> hallo
16:01:38 <stickies-v> alright, let's get started with the working groups
16:01:45 <stickies-v> #topic Fuzzing WG Update (dergoegge)
16:01:54 <brunoerg> hi
16:02:03 <dergoegge> no update
16:02:11 <stickies-v> #topic Kernel WG Update (sedited)
16:02:28 <sedited> Some review activity happening on #32427 again, and looking for more.
16:02:31 <corebot> https://github.com/bitcoin/bitcoin/issues/32427 | kernel: Replace leveldb-based BlockTreeDB with flat-file based store by sedited · Pull Request #32427 · bitcoin/bitcoin · GitHub
16:02:35 <sedited> I rebased my branch for splitting the mempool/policy code from validation (and thus from the kernel library): https://github.com/sedited/bitcoin/tree/mempoolout_rebase
16:02:48 <darosior> hi
16:03:12 <sedited> Still not happy with the code for the split though, the interface for accesing back into the mempool and grabing its locks is very clunky.
16:03:31 <maxedw> hi
16:03:40 <kanzure> hi
16:03:43 <johnny9dev> hi
16:04:00 <stickies-v> nice, will get back to reviewing 32427 asap, would be a nice improvement for kernel
16:04:25 <sedited> not sure how interested people are in this split in the first place. The code-organizational benefits are kind of nice, but beyond that the utility for the Bitcoin Core software are a bit questionable.
16:04:54 <sliv3r__> hi
16:04:57 <darosior> "Mempool eviction? -Yes but the one you are thinking about"
16:05:06 <darosior> not*
16:05:14 <sedited> indeed :)
16:06:33 <darosior> If it's a win for the Kernel library, and Bitcoin Core is no worse off, that seems fine?
16:06:58 <stickies-v> yeah i think it's a pretty big improvement for kernel users
16:07:25 <sedited> I might open it as a RFC PR , keeping it rebased is a challenge, but it's also kind of nice to ensure on a regular basis that such a split is possible in the first place.
16:08:06 <stickies-v> an RFC issue might make more sense?
16:09:14 <sedited> not sure, I think most would agree that it is a good thing on the face of it, so I more think it's the refactoring price that needs to be gauged here.
16:09:56 <sipa> hi
16:10:11 <stickies-v> linking a branch from an issue seems fine, but then at least you're not wasting time rebasing / addressing nits
16:10:21 <stickies-v> anyway
16:10:22 <stickies-v> anything else here?
16:10:28 <sedited> that's all
16:10:32 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:11:02 <andrewtoth_> l0rinc is out but he said he is working on an automated compaction PR
16:11:13 <andrewtoth_> I relayed darosior's idea to use minimum chain work as a trigger
16:11:34 <andrewtoth_> I also have come around to thinking a ~weekly automated compaction would be good
16:11:57 <sedited> what would be wrong with just repeatedly checking isibd?
16:12:16 <andrewtoth_> that would trigger every startup too, which would not be ideal
16:12:26 <sipa> andrewtoth_: 1 week worth of blocks is mayhe 2 GB of block data, a full rewrite every week would add a multiple of that
16:12:46 <sipa> or do we necessarily already have much morr
16:13:03 <andrewtoth_> sipa: the chainstate adds < 200MB a week to the db if uncompacted
16:13:32 <andrewtoth_> err I'm not sure how you mean block data to be relevant here?
16:13:50 <sipa> yeah, i'm just trying to gauge how much a weekly full rewrite of the chainstate would add in terms of disk activity
16:13:53 <darosior> For disk IO i think?
16:14:10 <andrewtoth_> I think today it will be like 10-15 GB of write IO per full compaction
16:14:28 <sipa> yes, which is a multiple of what i expect we'd do without
16:14:31 <Murch[m]> Why once per week rather than say, once per month?
16:14:31 <andrewtoth_> we can definitely bikeshed on how often to do it. could be monthly
16:14:49 <stickies-v> what about thriweekly
16:14:52 <sipa> rewrite at the end of IBD, once, is more impactful i think
16:14:59 <darosior> stickies-v: hah
16:15:11 <sipa> stickies-v: whenever the last block hash ends in 12 zero bits
16:15:38 <sedited> ^^
16:15:41 <andrewtoth_> yes agreed end of IBD is important. but, saving users an extra 11% for a full compaction every so often seems worth it?
16:15:44 <Murch[m]> sipa: Probably better if not everyone does it at the same height
16:15:46 <b10c> murch: agree
16:16:13 <darosior> Once a month seems fine, and then no need to do it at the end of IBD
16:16:19 <sipa> yeah, sorry, i didn't mean to start a bikeshed here... i'm just not very convinced doing it regularly adds much, and probably adds a relatively large amount of disk activity still
16:16:28 <sipa> Murch[m]: absolutely, it was a joke :)
16:16:58 <andrewtoth_> i think post-IBD alone is important, since a user might shut off and never keep it running for a whole month after that
16:16:59 <Murch[m]> E.g., do it once after IBD finishes, then schedule it for a random height 3500–5000 blocks later again
16:17:00 <Murch[m]> Would probably be bad if all nodes did it at the same height
16:17:19 <andrewtoth_> Murch: I think that's nearly the approach l0rinc is taking now
16:17:40 <darosior> andrewtoth_: you would advise doing both? I was hoping for either or
16:18:08 <Murch[m]> From reading the topic last week, my impression was that the db is bloated by several GB at the end of a full IBD
16:18:34 <Murch[m]> So, tracking that you started a new IBD and doing it once when you have caught up to the chaintip sounds pretty useful?
16:18:35 <andrewtoth_> i was thinking both, yes...
16:18:49 <darosior> If we do it once at the end of IBD, how much do you expect it would help to do it regularly on top? Like if it's done once around block 950k, how much disk space would doing it around block 1M would really save?
16:18:59 <andrewtoth_> if I had to choose one, it would be post-IBD
16:19:12 <andrewtoth_> 11% of disk space
16:19:43 <andrewtoth_> we save ~30% doing it immediately after IBD, then it's a slow creep up to 11% total
16:19:51 <andrewtoth_> a periodic compaction will trim that 11%
16:19:57 <Murch[m]> and then ~200 MB per week, roughly?
16:20:11 <andrewtoth_> Murch: up until 11%, it gets capped
16:20:53 <darosior> Ok. No opinion here. I don't think it matters much either way.
16:20:53 <andrewtoth_> I feel like post-IBD can be the initial change, then we can bikeshed more on periodic compaction.
16:21:02 <Murch[m]> Well, every week seems a bit aggressive, but either way it would be a huge improvement over doing it every hour
16:21:24 <andrewtoth_> ok, thanks for the feedback everyone
16:21:37 <andrewtoth_> otherwise, got some great review on #35295, thanks! will address that soon
16:21:40 <corebot> https://github.com/bitcoin/bitcoin/issues/35295 | validation: fetch block inputs in parallel during ConnectBlock by andrewtoth · Pull Request #35295 · bitcoin/bitcoin · GitHub
16:21:41 <andrewtoth_> that's it from me
16:21:47 <stickies-v> #topic Libevent removal (pinheadmz, fjahr)
16:22:04 <pinheadmz> #35182 is real close. addresed some nits yesterday and restarted integration testing. already have a few small follow-ups in the queue.
16:22:08 <corebot> https://github.com/bitcoin/bitcoin/issues/35182 | Replace libevent with our own HTTP and socket-handling implementation by pinheadmz · Pull Request #35182 · bitcoin/bitcoin · GitHub
16:22:32 <pinheadmz> And libevent removal from client was merged yay
16:23:04 <pinheadmz> Hoping to merge with enough time before release to find anything wrong
16:23:07 <pinheadmz> All from me
16:24:00 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:24:06 <johnny9dev> We continue to be on track for our "Preview" unsigned builds in June . The related work for that can be found at  https://github.com/orgs/bitcoin-core/projects/1/views/2 and I updated it this morning so it is accurate. We have wallet updates from pseudoramdom and epicleafies and node error dialogs and block status updates from me in review. Afterwards the high runners are updating the project to v31 and validating the settings and
16:24:06 <johnny9dev> onboarding is compatible with bitcoin-qt installs.
16:24:57 <johnny9dev> That's all from me
16:25:09 <stickies-v> alright, thanks for the updates everyone
16:25:12 <stickies-v> anything else to discuss?
16:27:00 <abubakarsadiq> novo asked me to relay silent payments update
16:27:15 <instagibbs> IIUC point release for 31.x is held up on #35319, so let's try and get that done?
16:27:15 <abubakarsadiq> https://github.com/bitcoin-core/secp256k1/pull/1765 has to be merged before we can merge silent payments on Core, but reviews are welcome on https://github.com/bitcoin/bitcoin/pull/35301 and https://github.com/bitcoin/bitcoin/pull/35302.
16:27:17 <corebot> https://github.com/bitcoin/bitcoin/issues/35319 | net: use the proxy if overriden when doing v2->v1 reconnections by vasild · Pull Request #35319 · bitcoin/bitcoin · GitHub
16:27:52 <stickies-v> yeah good shout out instagibbs
16:27:59 <Murch[m]> One follow-up to the compaction: if the mechanism is to schedule it for specific heights, you could schedule the first compaction for a height slightly after the chaintip of the best header chain once the node has acquired one, but delay the compaction until we are no longer in IBD.
16:28:59 <Murch[m]> Or maybe just scheduling it for the regular ~x thousand block interval but waiting until you are no longer in IBD would be enough to do one after IBD
16:29:03 <eugenesiegel> I tried making a functional test that built on top of p2p_private_broadcast.py, but it did not go well. I had issues with the Socks5 proxy and reconnection code, hopefully vasild has a better approach
16:30:49 <instagibbs> vasild any ETA on your version of the test, even with cleanups TODO
16:31:07 <andrewtoth_> Murch: we need to make sure we only trigger it one time, so using a gauge like previous work was < minimum now work is > minimum could work for that
16:31:20 <andrewtoth_> otherwise it will trigger every startup
16:33:14 <stickies-v> will wrap up the meeting here, but conversations can of course continue
16:33:16 <stickies-v> #endmeeting