Hello ๐ folks, Iโm Kevkevin. Iโm an open-source developer and reporter for Insider Edition. This week the native Windows build changed compilers, and an RPC stopped hiding disk errors.
Native Windows builds now use clang-cl. The presets are renamed to windows and windows-static, and CMakeโs MSVC variable stays true because clang-cl.exe is the driver compatible with cl.exe. The MSVC standard library, runtime, and vcpkg stay the same, but cl.exe is no longer a supported compiler. Hennadii Stepanovโs benches show ConnectBlockAllEcdsa going from 7.40 to 11.52 blocks/s.
GetTransaction also got stricter. A failed block read used to return null, the same as โtransaction not in this block.โ It now throws I/O error reading block data for block %s, so getrawtransaction, gettxoutproof, and REST return an internal error instead of saying the transaction is missing. Thursdayโs meeting covered the working groups, a new address relay group, disk error handling, and follow-ups to last weekโs CVE fixes.
Merged PRโs
Every week, several changes are officially added to Bitcoin Core. This week, 66 changes were merged. Here are some I found interesting this week.
Native Windows builds are now supported only with clang-cl.exe, which stays compatible with the Visual Studio build environment, the MSVC standard library and runtime, and vcpkg. CMakePresets.json renames vs2026 and vs2026-static to windows and windows-static, and both set toolset to ClangCL. MSVC has no inline assembly on x64 and ARM64, which blocked some hardware-accelerated implementations, and it needed workarounds for internal compiler errors no other supported compiler hits.
The benches he posted: ConnectBlockAllEcdsa goes from 7.40 to 11.52 blocks/s, ConnectBlockAllSchnorr from 7.32 to 11.81, and the Windows CI job he linked from 20m 35s to 12m 43s. doc/build-windows-msvc.md is renamed to doc/build-windows-native.md, and the CI jobs are now Windows native, clang-cl and Windows native, fuzz, clang-cl.
node::GetTransaction used to return a null CTransactionRef both when the transaction was not in the block and when the block could not be read. A failed BlockManager::ReadBlock now throws I/O error reading block data for block %s. getrawtransaction, gettxoutproof, utxoupdatepsbt, and descriptorprocesspsbt return an internal error, and REST /rest/tx/<TX-HASH> returns HTTP 500 with the error text.
TxIndex::FindTx used to log a warning and continue on a bad index entry or block read, so a confirmed transaction could come back as missing. It now throws in those cases. A known block with no data that is not in the active chain is still skipped, so a stale entry after an unclean shutdown does not abort the lookup. feature_io_errors.py renames blk00000.dat aside and checks each of these paths.
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.
This adds a callback in the kernel library C header that reports the script evaluation state on each step, so an external program can see how Bitcoin Core evaluates a script. It is compiled in with -DENABLE_SCRIPT_TRACE=ON, and without that flag the hooks are stubs. He also suggested the frames as a way to check that the script tests are exercising the interpreter, not an error path that hides the behavior. He asked for review again at Thursdayโs meeting.
The traces are divided into separate frames. RAII is used to guarantee that every script evaluation has at least its start and end state captured. Each instruction generates a unique frame as well.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
--- Topic 1 ---
๐ฑ๐๐
๐๐ด: #topic Fuzzing WG Update (eugenesiegel, marcofleon)
๐ฑ๐๐
๐๐ด: (also there are no pre-proposed meeting topics this week, feel free to suggest any)
--- Topic 2 ---
๐ฑ๐๐
๐๐ด: #topic QML GUI WG Update (johnny9dev)
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Ralph review bot was enabled on the repo posting comments directly and we're trying it out. I like the idea and we'll see what works and how to improve it.
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Other than that we are working through all of the PRs we have
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: That's all
--- Topic 3 ---
๐ฑ๐๐
๐๐ด: #topic Benchmarking WG Update (l0rinc)
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ_: not strictly benchmarking, but pushed another step toward narrowing AssumeUTXO: #36778 replaces the loading RPC with a startup arg, so we can at least avoid all the weird corner cases of loading a UTXO set on top of an existing chainstate
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ_: that's it from me
--- Topic 4 ---
๐ฑ๐๐
๐๐ด: #topic Kernel WG Update (sedited)
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: still hunting for review on #35641
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: Also wanted to highlight a tracking issue for making our unit tests more declarative in style: https://github.com/bitcoin/bitcoin/issues/36692
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: I think this is an interesting initiative, since we've seen other implementations port our existing unit tests with LLMs.
๐ท๐ผ๐ป๐ฎ๐๐ฎ๐ฐ๐ธ: sorry to interject: asmap run in 6 minutes https://github.com/bitcoin-core/asmap-data/issues/79
๐ฏ๐ญ๐ฌ๐ฐ: jonatack: thanks, would have forgot
--- Topic 5 ---
๐ฑ๐๐
๐๐ด: #topic QA WG Update (brunoerg)
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: no update this week
--- Topic 6 ---
๐ฑ๐๐
๐๐ด: #topic addr-relay WG update (stratospher)
๐ฑ๐๐
๐๐ด: I'm not sure that stratospher is here but I can say a bit
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Go ahead, i'll ping her IRL
๐ฏ๐ญ๐ฌ๐ฐ: she can read, but not type
๐ฑ๐๐
๐๐ด: There has been ongoing spam of existing addresses with fresh timestamps, this pins addresses in the new table, some discussions were had recently about how to mitigate this, and a WG has been formed to move forward with these changes
๐ฑ๐๐
๐๐ด: There are also some longstanding issues in Addrman that should be addressed, like the service flags problems, and address relay problems that exist because peers control the address timestamps
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Stratospher says "we have an address relay WG now. feel free to ping me if you'd like to join. (getting my IRC ready)"
๐น๐ถ๐ด๐ต๐๐น๐ถ๐ธ๐ฒ: see https://bnoc.xyz/t/address-relay-under-stress/163 and https://bnoc.xyz/t/address-relay-under-stress-attack-characteristics-and-measuring-its-effects/164 for some more details of current problems.
--- Topic 7 ---
๐ฑ๐๐
๐๐ด: #topic Disk error handling inconsistencies
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: the way disk errors are handled is extremely inconsistent depending on the exact code path that triggers the error
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: for example anything that triggers inside the try/catch block in process messages will be ignored unless specifically handled, but if the exact same error is triggered in rpc it might cause the node to shutdown entirely
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: some of the things ignored in the try/catch should actually cause a wallet node to abort but a non-wallet node not to abort, etc etc
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: my point is this needs an actual plan instead of piecemeal looking at crashes
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: im interested in other peoples thoughts on it
๐ท๐ผ๐ป๐ฎ๐๐ฎ๐ฐ๐ธ: bitcoindev1337: is there an RFC issue open
๐ท๐ผ๐ป๐ฎ๐๐ฎ๐ฐ๐ธ: seems worth discussing in one
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: there's many pull requests open addressing aspects of it, with a lot of discussions on the topic over the past years.
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: i dont think so and i'd open one but i got banned for a comment on 36761
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: there's also #36101
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: i really dislike discussion like that in pull requests since the op often has their own ideas which push around the discussion unduly
๐ฝ๐ถ๐ป๐ต๐ฒ๐ฎ๐ฑ๐บ๐: bitcoindev1337 ill unblock you but please keep the quality up
๐ฝ๐ถ๐ป๐ต๐ฒ๐ฎ๐ฑ๐บ๐: also see #35003
๐ฑ๐๐
๐๐ด: OK, it seems like #36101 might be the most relevant place to discuss if people have further thoughts
--- Topic 8 ---
๐ฑ๐๐
๐๐ด: #topic CVE-2026-117349 and CVE-2026-117350 followups (darosior)
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: So we deployed patches for CVE-2026-117349 and CVE-2026-117350 last week. Thanks everyone involved in reviewing and accelerating that process. We had binaries available within about 48h of the mitigations PRs being made public, which is not bad for a first run of this new policy
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Now that those were made available, i'm curious if anyone has been thinking about cleanups, as well as improving our testing / understanding there?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Cleanups because those were merely stopgaps, we should aim to fix those issues more fundamentally now that the dust settled down. For instance for CVE-2026-117349, the root cause is that we have unbounded growth in some p2p data structure. We fixed it with a timer to keep the growth manageable, but this is brittle, we should aim to have bounds on the memory usage peers can impose on us
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: I've been working on this for CVE-2026-117350, hardening our tests in this area, and i opened #36761 to discuss longer term cleanups
๐ฏ๐ถ๐๐ฐ๐ผ๐ถ๐ป๐ฑ๐ฒ๐๐ญ๐ฏ๐ฏ๐ณ: darosior like the select/poll thing that's a surprisingly hard thing to do without accidentally disconnecting legitimate peers
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: bitcoindev1337: i think always disconnecting on polling errors is fine, just not ideal for the http server
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: But we should be consistent, and document our choices, and test our invariants, to prevent something similar to happen in the future because barely anyone remembers how it works in details, and then such a surprise happens
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: are you specifically seeking feedback about poll/select or other things also related to sockets ?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: I am curious what everyone thinks we should do about those, and i have one more question i'm typing now
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Like just deploying the stopgap and forgetting about those will come back to bite us
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: I've also been looking into post CVE-2026-117349 cleanups, and that would be some non completely trivial refactorings, but doable. However i have other things i'd like to work on that i temporarily dropped for the security releases, and these hardenings, so i'd like to know if there is any will to review such refactorings before i commit more time to implementing those
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: what did roughly did you have in mind?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: For 117349?
๐ท๐ผ๐ป๐ฎ๐๐ฎ๐ฐ๐ธ: yes
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: ja
๐ฑ๐๐
๐๐ด: I'd help review, I agree that leaving it mitigated and poorly understood leaves dangerous technical debt
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: sedited: 1) changing the tx INVs token bucket manager to use a single, bounded queue for all peers. Each peer keeps its cursor. 2) moving the parts of SendMessages() that actually pile up messages for peers towards the end, and early return on fPauseSend to not reach those
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: It's just incredibly surprising that fPauseSend does not pause SendMessages(), but there are good reasons for doing so currently
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 3) some minor cleanups for other less frequent announcements
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: I could review as a backup if I'm able to clear some of my backlog. I think fundamentally fixing these issues is the right idea. I also think the socket code deserves more scrutiny
๐ท๐ผ๐ป๐ฎ๐๐ฎ๐ฐ๐ธ: darosior: feel free to ping me to review the PR
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: sedited: but it's just one half-baked idea, which is why i ask here, my thoughts have mostly been on #36761 the past couple weeks.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Ok, thanks everyone. That's all i had.
๐ฑ๐๐
๐๐ด: Anything else to discuss?Releases
There were no new releases this week.
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.