MSVC support dropped - This Week in Bitcoin Core #54
This week MSVC support was dropped...
Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo.
This week’s IRC meeting asked a simple question from hebasto: do we still want MSVC as a supported compiler?
Release binaries were never built with it. Those are MinGW. Native Windows from source is the last place MSVC still shows up, and clang-cl already works there. #31507 would make Clang first-class on Windows, which is when reviewers started asking why we still carry workarounds for a closed-source compiler we cannot patch.
The case for keeping it was compiler diversity. In practice, the bugs it finds are bugs in MSVC, patches already get almost no review, and it would be the only platform with three toolchains. A few ACKs later, the room was “so let’s drop MSVC support.” hebasto is opening an issue for how hard we cut.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, multiple changes were merged. Here are some I found interesting this week.
rest: add Cache-Control headers to REST responses by w0xlt
This week w0xlt had a REST PR merged that finally tells caches how to treat Bitcoin Core’s REST responses. Before this, REST replies had no Cache-Control header, so a reverse proxy or CDN sitting in front of a node had no idea what was safe to cache and what would go stale.The policy is conservative on purpose. Hash-addressed, immutable data (raw /block and /block/notxdetails bin/hex, plus /blockpart, /blockfilter, /spenttxouts, and /deploymentinfo/.json) gets Cache-Control: public, immutable, max-age=86400. Everything else — JSON block views with tip-dependent fields, /tx, /headers, /chaininfo, mempool, UTXOs, errors, unmatched 404s — gets no-store.
Reviewers pushed back on a one-year TTL for immutable responses. A day is enough to take load off the node, and it avoids getting stuck with a stale cached format after an upgrade. Operators who want something more aggressive can still override the defaults in nginx or a CDN.
wallet, test: Ancient Wallet Migration from v0.14.3 (no-HD and Single Chain) by w0xlt
w0xlt also landed test coverage for migrating wallets from Bitcoin Core v0.14.3 — that’s 2017 — over to today’s descriptor wallet format. The point is to make sure users can upgrade without losing funds, history, or addresses.
The test covers two old wallet types that current migration tests were not hitting: non-HD wallets created with
-usehd=0, and the first-generation HD wallets from that era (VERSION_HD_BASE, single chain). A 0.14.3 node cannot use the normal test-framework sync RPCs, so the test feeds blocks over withdumb_sync_blocksbefore running the migration.It also checks encrypted variants, that migration does not sneak in a rescan, and that the backup is a real file. If you still have a wallet from that vintage sitting around, this is the kind of coverage you want in Core before you hit migrate.
There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.
txindex: hash keys and pack positions to reduce disk usage by andrewtoth
The current txindex uses the full 32-byte txid as keys, which takes up about 66 GB of disk space today on mainnet. Using a 5-byte key prefix instead drops the disk usage to 26 GB - cutting the size to less than half. Using the full 32-bytes is unnecessary since a 5-byte salted siphash will produce collisions in about 1 in 1.1 trillion. Some collisions will occur, but the penalty is just an extra disk read, deserialization and hash. The tx position can be appended to the key instead of used as a value, and a LevelDB iterator can seek to the prefix and then scan for the correct tx. This is an almost identical approach to txospenderindex.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
--- Topic 1 ---
fjahr: #topic Fuzzing WG Update (dergoegge, marcofleon)
dergoegge: I have some fun things to share
dergoegge: I've vibed up an extension to https://github.com/antithesishq/bombadil that can test the qml gui
dergoegge: https://drive.google.com/file/d/1ioXLPUTvnxi9oo1gn4Hb6ggHsXVb26KY/view this is a video of the fuzzer working
dzxzg: hi
dergoegge: I also had claude use fuzzamoto to test a vibe coded node implementation (rbitcoin) over the weekend
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)
dergoegge: Not an attempt to dunk on the implementation but perhaps this increases the confidence in the types of bugs that fuzzamoto can find
dergoegge: There are some funny ones in there too imo
dergoegge: that's it
dergoegge: actually i think eugene has something to share as well
eugenesiegel: Hi yes
eugenesiegel: I've been working on something called incremental snapshots for fuzzamoto and wrote up a short blog post about benchmarking it:
eugenesiegel: https://crypt-iq.github.io/2026/08/07/incrementalsnapshots.html
eugenesiegel: It's basically a way to speed up the fuzzer and focus on deeper code paths
dergoegge: 🚀
eugenesiegel: that's it, if you have any questions or something was unclear let me know
marcofleon: lfg
brunoerg: nice
sipa: really cool
--- Topic 2 ---
fjahr: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #35531 is ready for review, I think it would fit nicely with the other optimizations we did in this release
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!
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?
l0rinc: that's it from me
--- Topic 3 ---
fjahr: #topic QML GUI WG Update (johnny9dev)
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.
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.
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
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.
johnny9dev: this should make cleaner history and easier to review. I will make an effort to attribute each commit with all contributors involved
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.
johnny9dev: thats all for this week
--- Topic 4 ---
fjahr: #topic QA WG Update (brunoerg)
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.
fjahr: That's it for the WGs
--- Topic 5 ---
fjahr: #topic Compiler diversity: to drop MSVC or keep it? (hebasto)
hebasto: hi
hebasto: On Windows, as on most other systems, there is more than one compiler that can be used to build Bitcoin Core.
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.
hebasto: While it's possible to use clang-cl.exe now, #31507 improves the build experience and makes Clang support first-class on Windows.
hebasto: At some point, reviewers suggested that support for MSVC, which produces inferior binaries, could be dropped entirely.
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.
hebasto: Here is the question for today's meeting:
hebasto: Do we want to keep MSVC as a supported compiler?
purpleKarrot: Should this be a vote?
cfields: I think that depends on the meaning of "support".
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
fanquake: Confusing to have simeltaneous PRs open which drop support for a thing, and add more support for a thing
hebasto: by support I mean workaroands for compiler bugs and MSVC- specifc diagnostics
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.
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.
hebasto: note that clang-cl still uses MS's standard library
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
fanquake: (similar to what we've seen with all the BSDs lately)
hebasto: fanquake: we can keep a MSVC ci job in the main repo though
dzxzg: if a MSVC ci job was kept in the main repo what would be changing about our support for MSVC
cfields: hebasto: could you describe exactly what you mean by dropping support, then? Explicitly allowing MSVC builds to fail? Ripping out the MSVC ifdefs?
cfields: Asking because as-of-now, release builds are mingw. So strictly as far as users are concerned, MSVC is "unsupported".
hebasto: https://github.com/bitcoin/bitcoin/pull/31507/changes/96d2380dc40e703e342dc0fad5d294cc49b25ff9 removes the ci jobs, documentation and msvc-specific diagnostics from the build system
hebasto: yes, it's not related to release binaries
hebasto: but we support building from source on Windows
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.
cfields: *diversity
hebasto: fanquake: do you agree to keep the current msvc support?
cfields: Perhaps there's a middle-ground keeping some subset of builds working? kernel? bitcoind?
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
fanquake: Some pushback here too: https://github.com/bitcoin/bitcoin/pull/31507#issuecomment-3928937728
sedited: it would be the only platform where we support targeting it with three different toolchains.
hebasto: well, clang-cl produces much better binaries for people who prefer build from source on Windows
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
fanquake: *why are we
fanquake: Especially given off all the compilers we use, it's the only one we can't actually fix
fanquake: (can't submit patches upstream, microsoft forum for supporting bugs close to useless etc)
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.
cfields: sedited: good point. And with the fewest eyeballs.
fanquake: purpleKarrot: the only issues we've found with MSVC so far, as bugs in the compiler, as far as I'm aware
fanquake: Not sure what the "best" compiler is for building releases, but it needs to be an open source one
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
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
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.
sipa: And (2) is great to help for testing diversity too, but doesn't need specifically optimizing for
fanquake: sipa: sure, but that maintains the loop of merging, and having to continually re-factor/fix code
fanquake: where breakage is reported after the fact
fanquake: wasting reviewer time, and creating churn
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
jonatack: hi
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
hebasto: cfields: did I get it correctly that you are no longer against dropping msvc support?
sipa: fanquake: or we can choose to treat MSVC as not even falling under (2) ?
fanquake: (maybe we should just have more jobs in the CI in the repo)
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"
hebasto: ^^ this seems reasonable
cfields: hebasto: not on the grounds of benefiting from diversity, at least.
lightlike: do we know if we have users/devs who build with msvc (and tend complain if something breaks), or is it just CI?
stickies-v: accepting patches but not running in ci seems like the worst of both worlds to me tbh
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
hebasto: lightlike: I build from source on Windows, but prefer clang-cl
sedited: yeah, msvc patches are already getting close to no review. Not having it in CI will probably drop that to zero.
cfields: dzxzg: hmm? Not the only one for Windows.
dzxzg: *native windows not WSL or cross-compiling
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
fjahr: Let's tie this topic up in the next 2-3 minutes and possibly continue after the meeting
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
hebasto: could end up keep support for both msvc and clnag-cl for a single release cycle and decide later?
hebasto: * clang-cl
sipa: m
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.
fjahr: sedited: Did you still want to give a kernel update?
sedited: not today
hebasto: so let's drop msvc support
sedited: ack
janb84: ack
stickies-v: maybe open an issue for it?
cfields: hebasto: how about opening an issue with a concrete proposal and we can resume discussing there?
hebasto: will do
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.
fjahr: Sorry, let me squeeze in my lil topic and continue discussion in the issue :)
--- Topic 6 ---
fjahr: #topic Kartograf 0.5.0 (fjahr)
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:
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.
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
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: <>
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.
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.
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.
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.
sipa: do we expect more agreement on the kartograf output with these changes?
sipa: (among participants all running 0.5.0)
fjahr: Afaict that should be unrelated, the disagreement typically come from rpki which these changes don't have impact on
sipa: ok
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
fjahr: Last one was 7/10 matches
sipa: nice
fjahr: "My code doesn't work, I have no idea why; My code works, I have no idea why"
fanquake: Next asmap run likely to be the one included in 32.0 ?
fjahr: Yeah, good queue I guess: feature freeze is in 1 week. Any last minute comments on that?
sipa: does new asmap data count as a feature? :)
fanquake: I think new asmap data is more like chainparams and similar
fanquake: So just pre branch off
fjahr: Yeah, no, but I forgot about making room for that topic :)
sipa: also fyi i'll be back from vacation tomorrow, i hooe to do some reviews for 32 where valuable stillRead here for the full meeting
Releases
No releases
Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!
If there are any comments, suggestions, or errors, do not hesitate to reach out or comment