A new working group just hatched 🐣 - This week in Bitcoin Core #35

This week a new working group was hatched...

Mar 20, 2026

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.

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 18 changes were merged. Here are some I thought were interesting from this week.

validation: Explicitly move blocks to validation signals by sedited
This enforces behaviour that is currently already implicit: The destructor for blocks runs mostly in the scheduler thread. The change should make it a bit clearer what the ownership semantics for these validation signals are.
BlockConnected already takes a reference to a block that is emplaced in connected_blocks. Once connected_blocks is iterated through, it is not reused. Similarly BlockDisconnected currently takes a reference to a block that is discarded after the call to it. Note that this does not give the guarantee that blocks’ lifetimes are extended by other means once they are connected. For example after IBD, the block’s lifetime is extended in net_processing’s m_most_recent_block and ActivateBestChain itself takes a copy of the block’s shared pointer, meaning its caller may delay de-allocation.
fuzz: wallet: add target for MigrateToDescriptor by brunoerg
If you’re not familiar with Fuzz Testing, I would read this summary.

This change by Bruno Garcia adds fuzz coverage to the scriptpubkeyman migration. It adds a new fuzz target spkm_migration. Garcia notes that this is only for migrating scriptpubkeyman, not the entire migration process. This is because attempting to fuzz the entire migration process would be much more expensive, and mocking would require significantly more refactoring.

He also notes that this explicitly avoids any encryption stuff because it would make the fuzz target run much slower.
rpc: Run type check on decodepsbt result by maflcko
Marco Falke updated RPCResults to type-check when the type may be ELISION, because it is confusing and brittle. The elision should only affect the help output and not the type itself. We also want the type to be the real type, so we can run type checks on it.

Falke also introduced a new print_elision option and uses it in decodedpsbt. Falke also gave instructions in the pull request description to test the failure.

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.

test: throttle large testmempoolaccept rpcs in p2p_orphan_handling test by rkrux
Addresses #34731
Reasons why I don’t believe it is a deadlock issue based on the debug logs and debugger thread backtrace output shared in the issue:
- The HTTP worker threads (b-http_pool_x) are waiting on the condition variable and not on the mutex that signals that these threads are idle & waiting for work to be assigned to them.
- The HTTP thread (b-http) is epoll waiting that means it is waiting for a request (or a part of it) to be received.
- The added logs show that the first few testmempool RPCs were successful and the next one timed out. But the logs don’t show a request for it being logged unlike in the previous ones, hinting that the server never received such a request (or in full) and thus never processed it. Even then the functional test client timed out, which means that it did send it (at least a part of it).
- The large orphan transactions being sent are each 780KB in size that are sent sequentially by the test. It tries to send 60 of them in a loop amounting to 46MB of data over a single HTTP connection that is reused.
This PR throttles the RPCs on client side. I’ve not been able to reproduce this intermittent issue and thus I don’t gurantee that this fixes the issue altogether.
A previous approach in this PR tried to not reuse the HTTP connection for the RPCs in this test instead. But I noticed a CI run where this affected test took around 75mins to complete that led me to move to this approach where the HTTP connection is reused like before but with some throttling.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

16:02:03 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:02:17 <dergoegge> no update

16:02:28 <fjahr> #topic Kernel WG Update (sedited)
16:02:43 <sedited> aj and cory left some interesting comments on #32317. Haven’t gotten around to work on them yet, but I’d like to encourage others to read them.
16:02:54 <yancy> hi
16:04:03 <sedited> we’ve also had craig raw try out #32427 for faster silent payment scanning: https://github.com/bitcoin/bitcoin/pull/32427#pullrequestreview-3935024360
16:04:25 <sedited> which lead to some interesting discussions on that PR too.
16:04:38 <sedited> that’s all.

16:04:53 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:05:10 <fjahr> l0rinc left an update earlier
16:05:26 <fjahr> https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-03-19#1204475;

16:06:03 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:06:35 <johnny9dev> Started PRs for wallet migration flows and wallet import/restore flows. Last PR for decoupling the qml project from the original qt-widgets is up and when those are merged that will be completed
16:07:17 <johnny9dev> We’ve introduced GMock to the project to mock out the wallet and node interfaces for easier unittesting
16:07:46 <johnny9dev> epicleafies: can you add your status?
16:08:06 <epicleafies> I’ve started PRs for adding the desktop tray icon and another for language and units settings.
16:08:44 <johnny9dev> nice
16:09:28 <johnny9dev> i think that is all for now. the PRs are pilling up so we’ll need to clear them soon

16:09:47 <fjahr> #topic Libevent removal (pinheadmz, fjahr)
16:09:51 <fjahr> A new working group just hatched 🐣. There has been quite a bit of development and review lately way to the goal is pretty clear so we thought it would be a good idea to try to give status updates regularly. All the necessary pieces already exist, you can find them all in the tracking issue: #31194.
16:09:59 <pinheadmz> Work continues on #32061 after many great reviews. After next rebase I will close that PR and reopen a fresh PR with the same code, but without a year and 300+ comments. Review has also exposed some new tests I want to add to master, and tweaks to some utilities we already merged last month I now realize are mostly wrong <grimace emoji>. SO stay tuned for three new PRs. Well, one reborn and two little guys.
16:10:19 <fjahr> pinheadmz: we should have synced better :D
16:10:26 <furszy> ACK
16:10:37 <pinheadmz> were doing great bruh
16:11:21 <pinheadmz> thats all
16:11:42 <fjahr> So review focus is on #34772 (new prerequisite to the http server) and #34158
16:12:11 <fjahr> Anything else to discuss?

16:12:35 <fjahr> #topic `MempoolUpdated` ValidationInterface callback (abubakarsadiq)
16:12:45 <abubakarsadiq> Opened #34803, which adds a `MempoolUpdated` ValidationInterface callback emitting before/after fee rate diagram chunks on every mempool update  enabling cluster-aware fee estimation and eliminating redundant block template rebuilds in the mining interface. The change is minimal; most of the diff is tests. Looking forward to feedback.
16:13:13 <abubakarsadiq> That’s all. thanks
16:13:53 <fjahr> Any other topics?

16:13:55 <jurraca> #topic ASmap
16:13:58 <jurraca> i opened #34842 to add asmap attestation scripts to contrib/asmap, wanted to ask if there are opinions for/against putting this in the core repo. The alternative would be putting them in the asmap.sigs repo along with the attestations themselves.
16:15:39 <fjahr> They are currently in the asmap.sigs repo
16:15:53 <fjahr> But these are updated a bit right?
16:15:58 <jurraca> yea

Releases

https://github.com/bitcoin/bitcoin/tree/v31.0rc1

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

Discussion about this post

Ready for more?