16:00:00 <fjahr> #startmeeting 
16:00:00 <corebot> fjahr: Meeting started at 2026-08-13T16:00+0000
16:00:01 <corebot> fjahr: Current chairs: fjahr
16:00:03 <corebot> fjahr: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:04 <corebot> fjahr: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:05 <corebot> fjahr: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:07 <yuvicc> Hi
16:00:10 <dergoegge> hi
16:00:11 <fjahr> #bitcoin -core-dev Meeting: _aj_ abubakarsadiq achow101 andrewtoth b10c brunoerg cfields danielabrozzoni darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy hebasto hodlinator instagibbs janb84 jarolrod johnny9dev jonatack josie jurraca kanzure kevkevin laanwj lightlike l0rinc maflcko marcofleon maxedw Murch pinheadmz provoostenator pseudoramdom ryanofsky sdaftuar sedited sipa sliv3r__ sr_gi stickies-v stringintech theStack
16:00:11 <fjahr> vasild willcl-ark
16:00:13 <eugenesiegel> hi
16:00:14 <brunoerg> hi
16:00:15 <l0rinc> hi
16:00:16 <hebasto> hi
16:00:18 <jurraca> hi
16:00:19 <janb84> hi
16:00:19 <lightlike> hi
16:00:20 <stickies-v> hi
16:00:25 <fjahr> There are two pre-proposed meeting topics this week. Any last minute ones to add?
16:00:31 <stringintech> hi
16:01:02 <sr_gi> hi
16:01:09 <kanzure> hi
16:01:10 <johnny9dev> hi
16:01:31 <purpleKarrot> hi
16:01:34 <cfields> hi
16:01:34 <fjahr> Starting with the working groups...
16:01:37 <fjahr> #topic Fuzzing WG Update (dergoegge, marcofleon)
16:01:49 <dergoegge> I have some fun things to share
16:02:12 <dergoegge> I've vibed up an extension to https://github.com/antithesishq/bombadil that can test the qml gui
16:02:28 <dergoegge> https://drive.google.com/file/d/1ioXLPUTvnxi9oo1gn4Hb6ggHsXVb26KY/view this is a video of the fuzzer working
16:03:04 <dzxzg> hi
16:03:08 <dergoegge> I also had claude use fuzzamoto to test a vibe coded node implementation (rbitcoin) over the weekend
16:03:24 <dergoegge> It found a lot of bugs: https://github.com/reardencode/rbitcoin/tree/master/docs/external_findings (a couple of them are from the red team, the rest is from fuzzamoto)
16:03:48 <dergoegge> Not an attempt to dunk on the implementation but perhaps this increases the confidence in the types of bugs that fuzzamoto can find
16:04:02 <willcl-ark> hi
16:04:07 <dergoegge> There are some funny ones in there too imo
16:04:13 <dergoegge> that's it
16:04:23 <dergoegge> actually i think eugene has something to share as well
16:04:29 <eugenesiegel> Hi yes
16:05:15 <eugenesiegel> I've been working on something called incremental snapshots for fuzzamoto and wrote up a short blog post about benchmarking it:
16:05:15 <eugenesiegel> https://crypt-iq.github.io/2026/08/07/incrementalsnapshots.html
16:05:16 <eugenesiegel> It's basically a way to speed up the fuzzer and focus on deeper code paths
16:05:31 <dergoegge> 🚀
16:05:36 <eugenesiegel> that's it, if you have any questions or something was unclear let me know
16:05:43 <marcofleon> lfg
16:05:46 <brunoerg> nice
16:05:47 <sipa> really cool
16:06:08 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:06:15 <l0rinc> #35531 is ready for review, I think it would fit nicely with the other optimizations we did in this release
16:06:18 <corebot> https://github.com/bitcoin/bitcoin/issues/35531 | txindex: hash keys and pack positions to reduce disk usage by andrewtoth · Pull Request #35531 · bitcoin/bitcoin · GitHub
16:06:31 <l0rinc> and the good news is that I have benchmarked bitcoindev1337's idea to prefetch blocks before connection and it does show a significant speedup, more than my 5% estimation, so it's worth a deeper investigation!
16:06:50 <l0rinc> bitcoindev1337 do you want to push something or do you want us to do it? If the latter, what's your github username to add you as coauthor?
16:07:38 <l0rinc> that's it from me
16:07:51 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:08:07 <johnny9dev> We got a ton of feedback last week on the preview and have started working on those issues. The project board will continue to the be place where we track the work.
16:08:24 <johnny9dev> We currently have about 80 issues we want to complete before starting our PR and about 20 that we think need to have complete before it is releasable.
16:09:07 <johnny9dev> I think the feedback/impressions i got on the current staging branch were all i needed to decide to change course. I am now working on just taking the best version of what we have and building up the application in stages. This will include introducing all of our testing frameworks right from the start. The different stages will be very similar to our current git history on the project
16:09:16 <johnny9dev> 1. Introduce the build and main  2.add first node lifecycle and model. 3. add onboarding, settings, and node running features 4. add desktop wallet creation 5. add send/activity/receive .... with he last few stages will be adding feature pages to the app.
16:09:46 <johnny9dev> this should make cleaner history and easier to review. I will make an effort to attribute each commit with all contributors involved
16:10:03 <johnny9dev> When I get closer I think I will create an issue in bitcoin/bitcoin with the plan and include tracking all of the steps we need to complete and look to start the PR for the first chunk.
16:10:49 <johnny9dev> thats all for this week
16:10:55 <fjahr> #topic QA WG Update (brunoerg)
16:11:10 <brunoerg> Hi, published at https://bitcoincore.space the latest analysis for src/psbt.cpp and src/private_broadcast.cpp. Also, spent some time filtering the survived mutants for src/script/interpreter.cpp, so the surviving ones may be most of interesting ones to be addressed. That's all, thanks.
16:11:54 <fjahr> That's it for the WGs
16:11:56 <fjahr> #topic Compiler diversity: to drop MSVC or keep it? (hebasto)
16:12:03 <hebasto> hi
16:12:10 <hebasto> On Windows, as on most other systems, there is more than one compiler that can be used to build Bitcoin Core.
16:12:18 <hebasto> Clang provides the clang-cl.exe tool, which is compatible with MSVC's cl.exe. The latter point is important when it comes to a shared libbitcoinkernel.dll.
16:12:26 <hebasto> While it's possible to use clang-cl.exe now, #31507 improves the build experience and makes Clang support first-class on Windows.
16:12:28 <corebot> https://github.com/bitcoin/bitcoin/issues/31507 | build: Use clang-cl to build on Windows natively by hebasto · Pull Request #31507 · bitcoin/bitcoin · GitHub
16:12:35 <hebasto> At some point, reviewers suggested that support for MSVC, which produces inferior binaries, could be dropped entirely.
16:12:45 <hebasto> Dropping MSVC support has many benefits, but the drawback is that it reduces the diversity of compilers testing the Bitcoin Core codebase, which was noted by cfields during the last CoreDev.
16:12:56 <hebasto> Here is the question for today's meeting:
16:13:03 <hebasto> Do we want to keep MSVC as a supported compiler?
16:13:25 <purpleKarrot> Should this be a vote?
16:13:32 <cfields> I think that depends on the meaning of "support".
16:13:38 <emzy> hi
16:14:13 <fanquake> I think this also came up because #31507 (which drops it) was tagged for 32, but there are other PRs like #24773 open, which add more MSVC specific code
16:14:15 <corebot> https://github.com/bitcoin/bitcoin/issues/31507 | build: Use clang-cl to build on Windows natively by hebasto · Pull Request #31507 · bitcoin/bitcoin · GitHub
16:14:17 <corebot> https://github.com/bitcoin/bitcoin/issues/24773 | Enable HW-accelerated implementations of SHA256 for MSVC builds by hebasto · Pull Request #24773 · bitcoin/bitcoin · GitHub
16:14:29 <fanquake> Confusing to have simeltaneous PRs open which drop support for a thing, and add more support for a thing
16:14:48 <hebasto> by support I mean workaroands for compiler bugs (https://gist.github.com/hebasto/aa42915f88faa4a0ee02655bb55ee624) and MSVC- specifc diagnostics
16:15:58 <purpleKarrot> By support I understand having a requirement that the code builds and tests run successfully when using MSVC as the compiler. Everything else (workaround for bugs, etc) are downstream from that requirement.
16:16:15 <cfields> I think it'd be a shame to stop building/testing against non-(gcc|clang). I think "should we avoid pessimizing because MSVC doesn't support X" is a different question.
16:16:27 <hebasto> note that clang-cl still uses MS's standard library
16:16:53 <sedited> hi
16:17:25 <fanquake> We also don't want to end up in any one of these "nightly" support loops, where no real CI is run, and we have to continue to re-factor/change code to support something after the fact
16:18:23 <fanquake> (similar to what we've seen with all the BSDs lately)
16:18:53 <hebasto> fanquake: we can keep a MSVC ci job in the main repo though
16:19:41 <dzxzg> if a MSVC ci job was kept in the main repo what would be changing about our support for MSVC
16:19:53 <cfields> hebasto: could you describe exactly what you mean by dropping support, then? Explicitly allowing MSVC builds to fail? Ripping out the MSVC ifdefs?
16:20:24 <cfields> Asking because as-of-now, release builds are mingw. So strictly as far as users are concerned, MSVC is "unsupported".
16:21:23 <hebasto> https://github.com/bitcoin/bitcoin/pull/31507/changes/96d2380dc40e703e342dc0fad5d294cc49b25ff9 removes the ci jobs, documentation and msvc-specific diagnostics from the build system
16:21:54 <hebasto> yes, it's not related to release binaries
16:22:38 <hebasto> but we support building from source on Windows
16:25:09 <cfields> I still think it'd be a shame to lose that diversit. But that's easy to say as someone who doesn't do any work to keep msvc compiling.
16:25:13 <cfields> *diversity
16:26:00 <hebasto> fanquake: do you agree to keep the current msvc support?
16:26:24 <cfields> Perhaps there's a middle-ground keeping some subset of builds working? kernel? bitcoind?
16:28:03 <fanquake> I don't mind that much. As mentioned, this doesn't meaningfully change our release binaries, but that was also a reason to push back, because 31507 is adding support for clang, awhich dds *another* way to compile for windows (new ci jobs, more build complexity etc), without actually improving anything we ship
16:28:36 <fanquake> Some pushback here too: https://github.com/bitcoin/bitcoin/pull/31507#issuecomment-3928937728
16:29:02 <sedited> it would be the only platform where we support targeting it with three different toolchains.
16:29:02 <hebasto> well, clang-cl produces much better binaries for people who prefer build from source on Windows
16:29:12 <fanquake> basically, if the motivation to use clang, was to avoid all the MSVC compiler bugs/ICE, then we are we continuing to keep supporting/testing it, with all the baggage
16:29:25 <fanquake> *why are we
16:29:46 <fanquake> Especially given off all the compilers we use, it's the only one we can't actually fix
16:30:07 <fanquake> (can't submit patches upstream, microsoft forum for supporting bugs close to useless etc)
16:30:34 <purpleKarrot> We should not mix two different topic. We want to build release binaries with the compiler that produces the best binaries. And we want a diverse test setup to find issues in the code.
16:30:34 <cfields> sedited: good point. And with the fewest eyeballs.
16:31:37 <fanquake> purpleKarrot: the only issues we've found with MSVC so far, as bugs in the compiler, as far as I'm aware
16:31:54 <fanquake> Not sure what the "best" compiler is for building releases, but it needs to be an open source one
16:32:46 <cfields> fanquake: yeah, ok, I withdraw my objection. I suppose it's philosophical without much grounding in reality these days. It may be diverse, but it's also shitty :p
16:32:54 <dzxzg> +1, although having compiler diversity is nice, MSVC is by far the most opaque when issues arise, it is hard to weigh an uncertain but possible benefit that MSVC might catch something that otherwise would have gone unnoticed against the real and constant maintenance cost
16:33:01 <sipa> (only half following, am travelling) I think it makes sense to have two different levels of "support", (1) whatever our published release binaries use and (2) systems/platforms where we think people should ve able to build for, but without testing guarantees. For example, I think some BSDs fall in the second category.
16:33:30 <sipa> And (2) is great to help for testing diversity too, but doesn't need specifically optimizing for
16:33:55 <fanquake> sipa: sure, but that maintains the loop of merging, and having to continually re-factor/fix code
16:34:02 <fanquake> where breakage is reported after the fact
16:34:13 <fanquake> wasting reviewer time, and creating churn
16:35:41 <fanquake> Maybe that is fine, and the build can just remain broken on those platforms/in the cis, until people want to circle back to it
16:35:59 <jonatack> hi
16:36:22 <janb84> If it does not provide new code issue/insight abd only compiler issues/bugs that need workarounds, i do not see what it brings us
16:36:37 <hebasto> cfields: did I get it correctly that you are no longer against dropping msvc support?
16:36:41 <sipa> fanquake: or we can choose to treat MSVC as not even falling under (2) ?
16:36:41 <fanquake> (maybe we should just have more jobs in the CI in the repo)
16:37:39 <sipa> there can even more fine-grained levels i guess, e.g. a "no CI for this config, but we accept patches to fix for"
16:37:48 <hebasto> ^^ this seems reasonable
16:38:14 <cfields> hebasto: not on the grounds of benefiting from diversity, at least.
16:38:15 <lightlike> do we know if we have users/devs who build with msvc (and tend complain if something breaks), or is it just CI?
16:38:31 <stickies-v> accepting patches but not running in ci seems like the worst of both worlds to me tbh
16:39:10 <dzxzg> lightlike: we have some since it's currently the only supported windows build system, but I imagine we would have close to 0 after clang-cl support is merged and is used in the build instructions
16:39:18 <hebasto> lightlike: I build from source on Windows, but prefer clang-cl
16:39:38 <sedited> yeah, msvc patches are already getting close to no review. Not having it in CI will probably drop that to zero.
16:39:52 <cfields> dzxzg: hmm? Not the only one for Windows.
16:40:13 <dzxzg> *native windows not WSL or cross-compiling
16:40:29 <sipa> stickies-v: i think that is the reality for e.g. FreeBSD, or has been in the past at leasr; i'm more trying classifying thr current reality than suggesting a policy
16:42:02 <fjahr> Let's tie this topic up in the next 2-3 minutes and possibly continue after the meeting
16:43:01 <stickies-v> if it's not helping us catch a lot of bugs, it's not used much, and it's a closed source and painful toolchain to use, fully dropping support seems sensible to me, but i'm not really involved with it so happy either way if ppl want to support it
16:43:02 <hebasto> could end up keep support for both msvc and clnag-cl for a single release cycle and decide later?
16:43:25 <hebasto> * clang-cl
16:44:29 <sipa> m
16:44:39 <cfields> stickies-v: +1. I think I'm onboard with that opinion now. It'd be different if it were open and we could improve it. But thinking towards a future where we (for ex) migrate to c++26, it's hard to imagine supporting MSVC doing anything for us but slowing us down.
16:45:02 <fjahr> sedited: Did you still want to give a kernel update?
16:45:08 <sedited> not today
16:45:52 <hebasto> so let's drop msvc support
16:46:52 <sedited> ack
16:46:58 <janb84> ack
16:47:12 <stickies-v> maybe open an issue for it?
16:47:29 <cfields> hebasto: how about opening an issue with a concrete proposal and we can resume discussing there?
16:47:50 <hebasto> will do
16:48:01 <cfields> It's still unclear to me exactly how much you propose we drop. For ex, ripping out everything from CMake would mean that no one could even _try_ to build it anymore.
16:48:37 <fjahr> Sorry, let me squeeze in my lil topic and continue discussion in the issue :)
16:48:41 <fjahr> #topic Kartograf 0.5.0 (fjahr)
16:48:51 <fjahr> Hi, we have a new release for kartograf, v0.5.0. The big headline is that there are two bugfixes that are breaking reproducible results so with this new version you are not able reproduce the maps that were created with an older version of kartograf and included in the asmap-data repository. For this reason I am proposing to add a note on that in the asmap-data repo to make users aware of this:
16:48:51 <fjahr> https://github.com/bitcoin-core/asmap-data/pull/67 In the past we have seen many users just use master and that might lead to some false alarm in the future.
16:49:01 <fjahr> Some more info for people to understand the impact: The two bugfixes are 1. https://github.com/asmap/kartograf/pull/145 A bug in the merge code prevented shorter prefixes from being merged when longer prefixes where already present in the higher priority input of the map. This means the results after the fix with the same inputs have more entries and larger coverage but the new coverage appears to be mostly unutilised address space
16:49:01 <fjahr> included in IRR DBs, so the real impact is for our purpose appears to be small. On the last 5 historical maps, the impact to the bitcoin network is that 3-4 peers which previously did not have a mapping do have one with the new map. See a more detailed analysis by Joris here: https://gist.github.com/jorisstrakeljahn/30235e943db90f78fecb9e397ffee9c5
16:49:18 <fjahr> 2. https://github.com/asmap/kartograf/pull/148 The IRR DBs we were downloading have inconsistent formatting and since we expected them to always end with an empty line, sometimes the very last entry was skipped when that was not the case. This only resulted in in a single additional prefix mapping (if any) in the final file in the recent runs and bitcoin nodes mappings were not affected by it.
16:49:29 <fjahr> Also, I previously stated that I don’t think releases make sense for us because participants usually just use master anyway but in this case it makes communication a lot easier so I guess we aren’t moving away from it for now.
16:49:41 <fjahr> Happy to hear feedback on this. Of course we did some additional (AI assisted) review of the code base to ensure we aren’t leaving any other breaking changes we would want on the table that we could bundle with this. But we couldn’t find anything else.
16:50:10 <fjahr> And sorry for dumping a wall of text but the kartograf repo doesn't get so many eyes so I rather put it here directly.
16:50:39 <sipa> do we expect more agreement on the kartograf output with these changes?
16:50:51 <sipa> (among participants all running 0.5.0)
16:51:20 <fjahr> Afaict that should be unrelated, the disagreement typically come from rpki which these changes don't have impact on
16:54:09 <sipa> ok
16:54:10 <fjahr> We still don't know where the recent rise in mismatches comes from exactly but the last one was better so the smaller changes in the downloading steps we made might have helped
16:54:33 <fjahr> Last one was 7/10 matches
16:54:59 <sipa> nice
16:56:09 <fjahr> "My code doesn't work, I have no idea why; My code works, I have no idea why"
16:57:41 <fanquake> Next asmap run likely to be the one included in 32.0 ?
16:58:18 <fjahr> Yeah, good queue I guess: feature freeze is in 1 week. Any last minute comments on that?
16:58:38 <sipa> does new asmap data count as a feature? :)
16:58:45 <fanquake> I think new asmap data is more like chainparams and similar
16:58:49 <fanquake> So just pre branch off
16:59:11 <fjahr> Yeah, no, but I forgot about making room for that topic :)
16:59:31 <sipa> also fyi i'll be back from vacation tomorrow, i hooe to do some reviews for 32 where valuable still
17:00:06 <fjahr> #endmeeting