Hello ๐ folks, Iโm Kevkevin. Iโm an open-source developer and reporter for Insider Edition. Happy Halloween ๐! The scariest thing this week was a memory bug, and Bitcoin Core moved fast to put it to rest.
32.1 came out quickly because of security fixes. CVE-2026-117350 let a peer exhaust a nodeโs memory by sending TCP urgent data on anything other than Linux. It was reported on 2026-10-23, and 32.1, 31.2, 30.4, and 29.5 were all out by 2026-10-28.
On the merge side, the fuzz targets got a reachability tracker. A missed goal leaves a ghostly FAIL on stderr, but the process still exits zero unless FUZZ_ENFORCE_REACHABILITY=1. And -acceptnonstdtxn=1 on test nets now checks only consensus flags, so non-standard scripts can be relayed and mined.
Merged PRโs
Every week, several changes are officially added to Bitcoin Core. This week, 27 changes were merged. Here are some I found interesting this week.
A ReachabilityGoal is identified by the std::source_location of its declaration: file, line, and column. RegisterReachabilityGoal runs before any input, and ObserveReachabilityGoal ORs a hit into that goal for the life of the process. The tracker destructor writes one line per goal, PASS or FAIL reachability goal "...", with the file, line, and column.
FUZZ_ENFORCE_REACHABILITY is read in the constructor. Unset or 0 leaves enforcement off, so a miss is only that line. 1 makes a miss call std::_Exit(EXIT_FAILURE) after flushing stderr. Any other value aborts immediately. The instrumented targets include cmpctblock, p2p_handshake, package_eval, process_message, tx_pool, utxo_snapshot, and validation_load_mempool. He replayed the current qa-assets corpora for those targets with FUZZ_ENFORCE_REACHABILITY=1.
-acceptnonstdtxn=1 now also skips non-mandatory script checks. The option stays test-net only. MemPoolAccept::PolicyScriptChecks used to call CheckInputScripts with STANDARD_SCRIPT_VERIFY_FLAGS unconditionally. The flag set is now STANDARD_SCRIPT_VERIFY_FLAGS when require_standard is set, and m_all_consensus_script_flags when it is not. Those are the flags that may be enforced as consensus for some chain state, so a transaction that could become consensus-invalid is still rejected.
CheckInputScripts takes CheckInputScriptsFor::Mempool or ::Block. A script failure on the mempool path is TX_NOT_STANDARD and mempool-script-verify-flag-failed. On the block path it is TX_CONSENSUS and block-script-verify-flag-failed. In p2p_segwit.py, spending a higher-version witness output is now accepted on the node with -acceptnonstdtxn.
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.
orphanage: Fix orphan reconsideration disconnect hole, add 1p1c invariant harness by Gregory Sanders
The first commit adds p2p_1p1c_liveness, an end-to-end fuzz target for parent and child relay. It drives a real PeerManager with real messages and validation. If an honest peer announces the child of an acceptable parent and child, the child has to reach the mempool within a bounded time, whatever the other peers do. Known liveness holes are flags on the target that turn the check off once that hole is open.
The second commit hands reconsideration to a remaining announcer when the marked announcement is erased, and removes the flag for this hole. The follow-up that fills the remaining holes is #36506. On the channel he said v33 is the target for that follow-up.
With that flag turned off, the target finds this bug on master from an empty corpus in under an hour on one core.
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)
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: no update from my side
--- Topic 2 ---
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: #topic QML GUI WG Update (johnny9dev)
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Merged in our integration test fixtures
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: We're working through some multi wallet management improvements and threading
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Once those are in well be ready to focus in building up the staging branch.
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: That's all for now.
--- Topic 3 ---
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: #topic QA WG Update (brunoerg)
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: just uploaded the results of a mutation testing for src/node/blockstorage.cpp, there are some interesting cases, in case anyone wants to see: https://mutanthub.space/projects/bitcoin/bitcoin/code/src/node/blockstorage.cpp?ref=4fe28722a572793da7614734a0c9cc8e1adc751a
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: That's all
๐๐ฎ๐ป๐ฐ๐: brunoerg these are some interesting mutations. I feel like this might actully be something an LLM might be good at writing fixes for.
--- Topic 4 ---
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: that's all for the working groups! anything else to discuss?
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: i think it's pretty impressive how we managed to crank out all those releases this week, kudos to everyone helping out
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: as per https://bitcoincore.org/en/2026/10/28/disclose-tcp-oom/ : going from first report on 2026-10-23 to finishing release on 2026-10-28 must be a record?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: stickies-v +1, good work to everyone including builders for being available to get it done
--- Topic 5 ---
๐๐ฎ๐ป๐ฐ๐: just curious, what exactly is the merge policy or is there one.
๐๐ฎ๐ป๐ฐ๐: I've submitted some small patches over the years, but never really been clear on that
๐๐ฎ๐ป๐ฐ๐: and the user docs on contributing doesn't really say anything of use
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: afaik it's not documented explicitly no, it's also really hard to quantify that in exact non-gameable criteria
๐๐ฎ๐ป๐ฐ๐: got it
๐๐ฎ๐ป๐ฐ๐: in othere projects, there's sort of a two maintaner ack policy sometimes
๐๐ฎ๐ป๐ฐ๐: wasn't sure what it might be in core since I've never observed any pattern
๐๐ฎ๐๐ถ๐น๐ฑ: yancy: there is _some_ reasoning in CONTRIBUTING.md, under "Decision Making" Process
๐๐ฎ๐ป๐ฐ๐: vasild yeah, I've read that. I was just looking for feedback on if there was or wasn't a ACK merge policy, and it doesn't sound like there is.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: PRs can sit around for a long time for various reasons
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: including lack of attention by reviewers
๐๐ฎ๐ป๐ฐ๐: for sure. Shame reviewers :P
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: can't remember the last time i saw a pr that was RFM and then not merged reasonably quickly; it's always lack of review/consensus in my experience
--- Topic 6 ---
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: despite how quickly and seemingly smooth this release went, i wonder if there are things we can do to make it easier / more automated, so we can continue to quickly publish releases when necessary
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: e.g. i think one unnecessary point of friction is that release notes are reviewed in the PR, and then again during a release. the release is often months after a PR was merged, so almost no one still has good context on that change. i feel like it makes more sense to just only review release notes in the first PR, and then the final release notes is a purely mechanistic aggregation of all those excerpts
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: this might require some more (llm-lintable) rules on release notes in PRs, e.g. make sure they are assigned to an appropriate category, are complete, etc
๐๐ฎ๐๐ถ๐น๐ฑ: stickies-v: +1
--- Topic 7 ---
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: eugenesiegel looking to get some eyes on #36437 which sets up a 1p1c fuzz harness for follow up work to improve robutness(up to a limit)
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: instagibbs: might not have time to review soon (trying to add a feature to fuzzamoto), but after that's done I can
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: cool, v33 is target for follow up which fixes the most egregious issues with few loc
Releases
32.1 and 31.2 were released 2026-10-27. Signed binaries for 32.1 are in bitcoincore.org/bin/bitcoin-core-32.1. This was a quick security release for CVE-2026-117350, with fixes #36665 and #36667 by Antoine Poinsot.
30.4 and 29.5 were released 2026-10-28. Both binary directories are up, with checksums.
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.