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.
In hodlinator’s headers-sync PR, if your system clock is so far behind the chain-start median time past that the unsigned commitment cap wraps, Core now aborts the node instead of eating low-work headers. Fresh datadirs hit this path. Existing chainstate already shuts down at load.
Sedited points at the 32.0 milestone, eight items are still open and branch-off is next week. Pinheadmz is still triaging agent findings on the new HTTP server.
Sipa did quote furszy: “Claude is down, sorry”, and fjahr asked if he forgot how to join IRC without agent help :).
The two PR’s that took the most review this week are the headers-sync abort, and a -walletnotify command-injection fix that the Red Team found.
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.
net: Disallow invalid HeadersSyncState due to lagging clock by hodlinator
Headers presync sizes
m_max_commitmentsfrom the elapsed time since the chain-start median time plusMAX_FUTURE_BLOCK_TIME. If your local clock is more than that far behind chain-start median time past, elapsed goes negative, the unsigned cap wraps to something huge, and low-work headers keep coming instead of the peer getting dropped.The old idea (#35208) was to clamp the cap to zero and let
HeadersSyncStatekeep eating headers. This PR refuses to construct an invalid state at all and aborts the node. In practice, if you already have chainstate, startup already notices the lagging clock and shuts down first. A fresh datadir is the path that actually hits this. hodlinator filed #36134 to make that comment match reality, and that one merged too.util: keep wallet names literal in notification commands by l0rinc
l0rinc fixed a v24 regression in-walletnotify.On non-Windows,
%win the notify command is replaced with the shell-escaped wallet name. Since #25803,ReplaceAll()has been feeding that replacement throughstd::regex_replace(). Regex replacement treats$'as “the rest of the subject,” so a wallet name containing$'can smash the quoting and run extra shell as the node user.This is not a P2P bug. You need an authenticated RPC caller who is allowed to create wallets. #35833 already started restricting control characters in new names; this one restores the literal, non-recursive contract
ReplaceAll()that existed before the Boost-to-std::regexswitch. The Red Team found it.
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.
l0rinc asked for a review in Thursday’s meeting. It is open, not a draft, and not Needs rebase. Last week’s prefetch PR (#36000) is still open too, he said a reindex-chainstate is often >50% faster now (about 30017s → 19609s on his HDD box). Branch-off is next week, so if you have one review slot, start here and keep #36000 in the other tab.
Problem:
getprioritisedtransactionslets node operators inspect fee adjustments. While building the response, the RPC checks each transaction ID against all previous IDs, even though duplicates are impossible. The same unnecessary search appears in a few other RPC responses built directly fromstd::maporstd::setkeys.Fix: Each changed response key comes from an
std::maporstd::set, where keys are unique, so insertion can skip the linearfindKey()call.
On a Pi 4 his reproducer was almost a minute before the fix and about half that after. Same shape anywhere we build JSON from map/set keys.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
--- Topic 1 ---
fjahr: #topic QA WG Update (brunoerg)
brunoerg: I ran a mutation analysis for the silent payments PR and got a positive feedback about the findings and many mutants were addressed. Now that the implementation is on master, I re-ran the analysis for sp code as part of the weekly run. It got 100% of mutation score (that's perfect) - I will probably run a full analysis to check if there is any leftover. Results can be seen at: https://secp256k1.space
brunoerg: I also re-ran the mutation analysis for src/script/interpreter.cpp, since it's critical code I generated all the possible mutants. I got over 1000 mutants for this file which only 80 of them survived. There are some PRs adding more test cases for the interpreter which I hope we will soon have full coverage of them.
brunoerg: Naiyoma is helping me to test the parallelization of the analysis, I hope to get it ready soon, it will make our mutation workflow faster and more practical.
brunoerg: Also, I appreciate feedback from kernel people in #647. the idea is doing differential fuzzing between the kernel and the Core's internals.
brunoerg: That's all
fjahr: cool, thanks!
--- Topic 2 ---
fjahr: #topic QML GUI WG Update (johnny9dev)
johnny9dev: continue to work on the staging branch and fixing issues
johnny9dev: thats all for now
--- Topic 3 ---
fjahr: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: A few of the quadratic iteration fixes were merged, #36096 is similar, review would be appreciated.
l0rinc: And as mentioned yesterday, #36000 was tuned a bit more, now a reindex-chainstate is often >50% faster.
l0rinc: IBD is probably internet bandwidth bounded now, will experiment with parallel undo/block flushes to see if it helps.
l0rinc: Will also profile a neutered validation-less and UTXO-less node to see the remaining bottlenecks.
l0rinc: That's it from me, thanks
--- Topic 4 ---
fjahr: #topic Kernel WG Update (sedited)
sedited: Been getting some good review on #35641 . Also had some external projects say they would be interested in its capability.
sedited: and will circle around to the things request in the pr brunoerg linked before
sedited: that's all
--- Topic 5 ---
fjahr: Anything else to discuss? Possibly the release?
sedited: there's still a few items in the milestone: https://github.com/bitcoin/bitcoin/milestone/84
sedited: would be good to get them in before branch-off.
fjahr: Please review! Anything else?
pinheadmz: Im getting lots of agent findings in the new HTTP
pinheadmz: im triaging solutions before branch off
pinheadmz: so just keep em coming.
fjahr: #endmeetingRead here for the full meeting
Releases
No releases
v32.0 is coming soon…
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