16:00:02 <stickies-v> #startmeeting 
16:00:02 <corebot> stickies-v: Meeting started at 2026-06-18T16:00+0000
16:00:03 <corebot> stickies-v: Current chairs: stickies-v
16:00:05 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:06 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:07 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:09 <Murch[m]> Hi
16:00:10 <janb84> hi
16:00:10 <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:10 <stickies-v> vasild willcl-ark
16:00:12 <sedited> hi
16:00:14 <jonatack> hi
16:00:15 <brunoerg> hi
16:00:16 <cfields> hi
16:00:16 <sipa> hi
16:00:17 <abubakarsadiq> hi
16:00:17 <yuvicc> hi
16:00:19 <stringintech> hi
16:00:27 <pseudoramdom> hi
16:00:30 <eugenesiegel> hi
16:00:41 <stickies-v> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:00:46 <johnny9dev> hi
16:00:48 <furszy> hi
16:00:50 <b10c> hi
16:00:57 <hodlinator> hi
16:01:01 <marcofleon> hi
16:01:09 <dergoegge> hi
16:01:15 <pinheadmz> Yo
16:01:18 <stickies-v> #topic Fuzzing WG Update (dergoegge, marcofleon )
16:01:54 <marcofleon> update next week
16:01:57 <dergoegge> huge
16:02:00 <stickies-v> tm
16:02:14 <stickies-v> #topic Kernel WG Update (sedited)
16:02:24 <andrewtoth> hi
16:03:03 <sedited> pupleKarrot has been blogging on a serialization refactor: https://purplekarrot.net/blog/serialization.html
16:03:36 <kanzure> hi
16:03:49 <sedited> in general wanted to highlight his blog which has some other thoughts posted on the library's direction: https://purplekarrot.net/
16:03:49 <sipa> sedited: cool will read
16:04:16 <sedited> that's all
16:04:30 <willcl-ark> hi
16:04:39 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:04:41 <l0rinc> https://github.com/bitcoin-core/secp256k1/pull/1859 ("field: force-inline 5x52 mul and sqr") was merged.
16:04:49 <l0rinc> It speeds up script validation by up to 12% and silent payment benchmarks indicate a >7% speedup (https://github.com/bitcoin-core/secp256k1/pull/1765#issuecomment-4730561343)
16:04:50 <jonatack> sedited: interesting
16:05:17 <sipa> l0rinc: after subtree merge, i assume?
16:05:46 <l0rinc> of course, the benchmarks in secp already show the speedups though
16:05:51 <l0rinc> #35215 was updated to support 32-byte jumboblock path needed in #35531 - reviews are welcome.
16:05:52 <fanquake> sipa: was probably going to pull today / tomorrow
16:05:53 <corebot> https://github.com/bitcoin/bitcoin/issues/35215 | coins: use jumboblock SipHash-1-3 for hashing CCoinsMap keys by l0rinc · Pull Request #35215 · bitcoin/bitcoin · GitHub
16:05:55 <corebot> https://github.com/bitcoin/bitcoin/issues/35531 | txindex: use 5-byte siphash keys to optimize disk usage by andrewtoth · Pull Request #35531 · bitcoin/bitcoin · GitHub
16:06:11 <l0rinc> #35465 is feature complete with several ACKs, I'm running a few more checks to see if we can safely recommend it for cherry-picking to older versions as well (see https://github.com/bitcoin/bitcoin/pull/35331#issuecomment-4727463324)
16:06:14 <corebot> https://github.com/bitcoin/bitcoin/issues/35465 | coins: compact chainstate regularly by l0rinc · Pull Request #35465 · bitcoin/bitcoin · GitHub
16:06:29 <l0rinc> that's it from me - andrewtoth?
16:06:43 <sipa> i'm in favor of backporting 35465, though waiting for benchmarks seems useful
16:06:44 <andrewtoth> thanks for all review on #35295. More review welcome :)
16:06:49 <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:07:01 <andrewtoth> sipa: same
16:07:29 <andrewtoth> Talking with 0xb10c, he has been running with seek compaction disabled and sees performance improvements all around
16:07:44 <sedited> nice
16:07:55 <andrewtoth> lower disk IO, no compactions on CPU in background, and faster block connection
16:08:05 <andrewtoth> that's it from me
16:08:10 <sipa> l0rinc: i have a patched tree which should force leveldb into one of its 4 table cache regimes based on a macro, would you be interested in benchmarking them?
16:08:13 <l0rinc> sweet. I emailed one of the LevelDB maintainers for a review - let's see if he can help us out with a review
16:08:16 <Murch[m]> Awesome
16:08:32 <l0rinc> of course, I just bought 3 new servers
16:08:42 <yancy> hi
16:09:03 <sipa> alright, i'll do some minimal testing, and explain what would be useful to look at out of band
16:10:01 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:10:15 <johnny9dev> https://github.com/orgs/bitcoin-core/projects/1/views/3 is up to date
16:10:40 <johnny9dev> We have 4 PRs in review right now and once those are finished and merged we will be ready to start sharing preview builds
16:11:15 <johnny9dev> I think I've decided to sign those builds myself and do our best to have a big warning on them to make it clear of the purpose. That being to get feedback and help address UX issues early
16:11:42 <johnny9dev> hebasto and I have also started work on how to construct the "staging" branch that will end up being what we PR
16:12:14 <Murch[m]> Excited to see the preview!
16:12:26 <johnny9dev> the rough idea for that is to pull the commits from gui-qml on top of bitcoin/bitcoin using filter-branching and ammending the commits with backport-style metadata "Rebased-From" and "Github-Pull"
16:13:27 <johnny9dev> we should have more to share on that next week. I hope to be able to have python scripts available to reproduce the staging branch from the gui-qml repo. We want to do what we can to make the review process go smoothly
16:14:14 <johnny9dev> the messier part will be the patching of earlier commits to make this buildable throughout. working on some ideas to make that work
16:15:04 <Murch[m]> How can people not involved in the GUI code help?
16:15:28 <Murch[m]> I assume spinning it up and going through their own usual workflows and noting any feedback would be a start?
16:15:44 <johnny9dev> w'll have lots of things to get feedback on very soon with the preview release and our staging branch
16:16:16 <sipa> johnny9dev: cool
16:16:42 <fanquake> Is the idea that the staging branch has already been reviewed, and is just being merged, or is it going to be split up and re-reviewed?
16:17:46 <johnny9dev> something in between. the link to what was reviewed should mean alot of the code has already has eyes on it and reviewed but there will be the integration pieces with making this line up with the rest of bitcoin/bitcoin that should get some review on too
16:18:09 <johnny9dev> things like the python scripts for gui testing, the cmake files, and the build config flags
16:18:26 <johnny9dev> guix buids and new depends
16:18:40 <fanquake> Just wondering, because if stuff is being re-reviewed anyways, don't think you need all the metadata pointing to other commits, that haven't been merged/might not have been reviewed anyways
16:21:07 <johnny9dev> every commit has had a review other than the scaffolding to get it to align with bitcoin/bitcoin's cmake and depends
16:21:45 <johnny9dev> im confused by what you mean about re-review. i dont think it will be necessary to re-review most of the historical commits of the project
16:22:10 <johnny9dev> and the links to the old PR reviews will be there so it can be understood how the application was built up
16:24:04 <johnny9dev> the goal being to limit what exactly needs to be reviewed in the PR
16:24:12 <fanquake> I'm not sure. I don't what the review quality has been on the qml repo. So I don't know if something has been "reviewed" and should just be merged into bitcoin/bitcoin if it has 1 ACK from a contributor I've never heard of, in a different repo. Not a blocker now anyways, will see what you come up with
16:24:57 <johnny9dev> yes ill try to have more clarity and an example next week
16:25:13 <stickies-v> #topic LevelDB block cache (sipa)
16:25:52 <sipa> I spent some time trying to dig into all the ways the different LevelDB resource limits (open files, file descriptors, mmap regions) interact (see https://github.com/bitcoin-core/leveldb-subtree/pull/63#issuecomment-4735688019), and discovered something surprising: in our typical builds, the block cache is entire unused.
16:26:53 <sipa> It looks like (though can use some more verification) that the cache is only used when either the table files are compressed on-disk (which we disable) or mmap() cannot be used (so, just on 32-bit platforms).
16:27:26 <sipa> So maybe the complex cache-distribution logic (eg #34646) can be simplified/dropped in light of that.
16:27:30 <corebot> https://github.com/bitcoin/bitcoin/issues/34646 | Fix two issues in p2p_private_broadcast.py by vasild · Pull Request #34646 · bitcoin/bitcoin · GitHub
16:27:34 <sipa> ehh
16:27:38 <sipa> #34636 
16:27:41 <corebot> https://github.com/bitcoin/bitcoin/issues/34636 | node: allocate index caches proportional to usage patterns by svanstaa · Pull Request #34636 · bitcoin/bitcoin · GitHub
16:27:57 <sipa> That's it, just wanted to give it some attention.
16:28:30 <sedited> I saw your comment and have been trying to see if there is any difference in performance, couldn't see one so far (probably should have done that when looking at the pull request :P)
16:28:32 <sipa> ("block" here is LevelDB table file blocks, not Bitcoin blocks)
16:28:35 <andrewtoth> alternatively we can just transfer the amount reserved for table cache to the memtable?
16:28:45 <sipa> andrewtoth: yeah
16:29:04 <andrewtoth> (I think l0rinc has been experimenting with that)
16:29:19 <sipa> though there are other interactions too, where the max_open_files limit passed to LevelDB may have a substantial impact on memory usage (depending on mmap or not) too, outside of the block cache.
16:29:35 <sipa> So we may want to rethink more generally how memory usage is accounted for and distributed.
16:30:25 <sedited> is there a table cache knob?
16:31:00 <sipa> max_open_files is effectively the knob for how many table files the database memory structure has cached
16:31:26 <sipa> and the per-file memory impact depends on whether it's opened through mmap or not, and how big the file is
16:32:09 <sipa> which does mean that by increasing the table file size to 32 MiB, we may have inadvertently also increased base memory usage (though, probably not much, because it's only set high on mmap-capable platforms where the impact isn't large)
16:32:43 <andrewtoth> sedited: there are knobs in GetOptions in dbwrapper.cpp
16:33:21 <andrewtoth> I think block_cache is useless, is what sipa is saying, and write_buffer_size can take more of that memory?
16:33:22 <sedited> yes, just wasn't caught up on the mechanics that sipa just described.
16:33:38 <sipa> That's it for me. We can discuss more on the relevant PRs.
16:34:02 <stickies-v> Anything else to discuss?
16:34:20 <b10c> my vibe-coded https://github.com/0xb10c/bitcoind-gunix side-project is now able compile all binaries and tarballs for v31.0 byte-for-byte in Nix, without any byte-patching needed. The Nix SHA256SUMS match the Guix SHA256SUMS
16:34:27 <b10c> Not sure about the future of this project yet, but pretty cool to see that this is even possible
16:34:38 <sipa> b10c: woah
16:34:40 <sedited> cool!
16:35:09 <janb84> fun
16:35:39 <yuvicc> great!
16:36:41 <Murch[m]> Since there are a lot of BIP authors here. I have started looking over BIPs in Draft to see if some of them should be advanced to Complete or should be Closed. If you have Draft BIPs that you think should be advanced to a different status, you could help by opening a PR yourself :)
16:36:43 <fanquake> b10c: what is left to do on the nix bootstrapping front? Or is that already solved?
16:37:16 <fanquake> I did see something recently about re-using guix packages in nix, or vice-versa (cc willcl-ark)
16:38:10 <b10c> fanquake: I haven't checked in a while. Will have a look at some point!
16:40:41 <jonatack> Murch[m]: +1 good idea
16:41:32 <stickies-v> looks like we're all done here. thanks everyone for chiming in!
16:41:39 <stickies-v> #endmeeting