Issue 03: August 6, 2025

CI migration, block header hashing benchmarks, and three new Utreexo BIPs

Aug 06, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from six working groups: Kernel, Stratum V2, MuSig2, Orphan Resolution, QML GUI, and Benchmarking.

Also, on the Bitcoin Development Mailing List, Bitcoin Core contributors Calvin Kim, Tadge Dryja, and Davidson Souza highlight three new Bitcoin Improvement Proposals (BIPs) that together implement Utreexo, an experimental feature that allows Bitcoin nodes to verify transactions without storing the full UTXO set—dramatically reducing RAM and disk space requirements.

Below is my write-up on the Bitcoin Core developers meeting that took place on Thursday, July 31, 2025, and other core Bitcoin discussions from this past week.

Yours truly,

Christine D. Kim

Core Release Schedule

First, here’s a quick overview of Bitcoin Core’s software release schedule and the status of the next major release:

Latest Stable Major Release: Bitcoin Core 29.0

Release Date: April 15, 2025

Latest Stable Minor Release: Bitcoin Core 28.2

Release Date: June 27, 2025

Upcoming Major Release: Bitcoin Core 30.0

Target Release Date: Early October 2025
Open issues: 10
Closed issues: 43
Milestone progress: 81% of issues are resolved

(Previous week’s snapshot showed 10 open issues, 39 closed, and a milestone progress of 79%.)

Meeting Minutes

Editor’s note: Some quotes featured in this section and the next have been edited slightly for grammar and clarity.

🗒️Topic #1: CI Migration to Cirrus Runners

Discussion: Bitcoin Core contributors Will Clark (“willcl-ark”) and Max Edwards (“m3dwards”) have opened a new pull request (PR) to the Bitcoin Core Github repository that will move the codebase’s continuous integration (CI) system from privately self-managed servers to hosted runners provided by Cirrus, a third-party service.

CI is the system that automatically tests Bitcoin Core’s code on every pull request or code change to make sure new updates don’t break existing functionalities or features.

About the migration, Clark said during the meeting:

In summary, it should make the CI maintainable by more people, not be reliant on the current infrastructure, and also provide "easier scaling"; if you want to scale more machines, just throw more $$$ at the problem. These are fleshed out further in the PR, and we'd welcome feedback there.

In his PR, Clark added that Cirrus runners cost $75/month each after an open-source discount (normally $150). A typical setup would need about 10 runners, totaling $750/month or $9,000/year. Further, each runner offers 16 CPU cores and 64 GB RAM.

Though there was no mention of what entity specifically would foot the bill for the migration, Bitcoin Core infrastructure costs (such as CI, servers, and domain hosting) have often historically been covered by:

Brink
Chaincode Labs
Blockstream
Individual sponsors like Jack Dorsey, CEO of Block
Bitcoin Core’s general donation fund

Clark said that he would appreciate more review from other Bitcoin Core contributors on his PR.

Takeaway: Bitcoin Core’s current CI system is powerful but challenging to maintain, as it requires a small number of skilled contributors to manually run and debug the infrastructure. By switching to Cirrus’s hosted runners, developers would no longer need to maintain any hardware or specialized CI servers, which simplifies code maintenance and allows developers to easily scale testing efforts of Bitcoin Core as the technology matures.

🗒️Topic #2: Inefficient Block Header Hashing

Discussion: “Phantomcircuit,” a pseudonymous Bitcoin Core contributor, raised the issue of excessive block header hashing during an initial node sync. They noted that using the function “cblockheader::gethash” during the initial block download (IBD) process, certain block hashes are recalculated hundreds, if not thousands of times.

As background, IBD refers to the process a new Bitcoin node goes through when it first connects to the Bitcoin network. During IBD, the node downloads and verifies every block from the beginning of Bitcoin’s history (Genesis Block) all the way to the present. Hashes are a fixed-size string of numbers and letters that, in the context of IBD, are used to identify individual blocks and order them sequentially in a chain-like fashion.

Phantomcircuit said:

I have instrumented `CBlockHeader::GetHash` to display the hash that it just calculated and even the first 200k blocks contain hundreds (sometimes even thousands) of hash calculations. … I'll investigate further.

Bitcoin Core contributor Ava Chow “achow101” responded, saying:

It definitely seems there's something to look at here. Phantomcircuit, I suggest you work with l0rinc and the others who have also been looking at IBD improvements and benchmarking.

Takeaway: Investigations are underway for potential improvements to the initial block download process, which may yield significant speedups for users when spinning up their Bitcoin nodes for the first time.

🗒️Other Topics

Kernel WG: A project that seeks to modularize Bitcoin Core by isolating and organizing consensus-critical logic into a cleaner, more reusable structure, separating it from wallet code, user interfaces, and other non-essential components.
- PR #30595 (kernel: Introduce initial C header API) has attracted attention from more Bitcoin Core contributors. Work on the PR is ongoing.
Stratum V2 WG: An initiative to modularize and refactor Bitcoin Core components to support a next-generation mining protocol known as Stratum V2. Stratum V2 enables Bitcoin miners to create block templates and influence transaction inclusion in blocks, thereby decentralizing and democratizing the power away from Bitcoin mining pools.
- PR #31802 (Add bitcoin-{node,gui} to release binaries for IPC) needs review for inclusion in the next major Bitcoin Core release.
- PR #31679 (cmake: Move internal binaries from bin/ to libexec/) needs review for inclusion in the next major Bitcoin Core release.
Orphan Resolution WG: An initiative to improve how nodes handle missing transaction data, or “orphan” transactions with missing data inputs, to make the network more efficient and resilient against spam and denial-of-service (DoS) attacks.
- PR #32941 (p2p: TxOrphanage revamp cleanups) has been merged and is slated for inclusion in the next major Bitcoin Core release.
QML GUI WG: An initiative to create a new modern graphical user interface (GUI) for Bitcoin Core using Qt Quick / QML (Qt Modeling Language).
- Migration work to the new development branch called “Qt6” is ongoing.
MuSig2 WG: An initiative to modernize the cryptographic scheme that combines multiple signatures authorizing a Bitcoin transaction into a single signature.
- PR #31244 (Implements MuSig2 support for miniscript descriptors) has been merged.

Benchmarking WG: Efforts to measure and improve the performance of Bitcoin Core software through benchmarking, that is, analyzing how long certain processes take—like syncing the blockchain for the first time (Initial Block Download), verifying transactions, or writing data to disk—and looking for ways to make those processes faster and more efficient.
- PR #31144 (IBD multi-byte block obfuscation) & PR #32279 (IBD prevector: store P2WSH/P2TR/P2PK scripts inline) both merged.
- PR #31645 (IBD flush UTXO set in batches proportional to dbcache size) & PR #32497 (merkle: pre‑reserve leaves to prevent reallocs with odd vtx count) review needed, with priority for the latter PR.

You’ve Got Mail! (& Other News)

Here’s a round-up of other core discussions that happened this past week from the Bitcoin Development Mailing List and other public forums:

📧 Email Thread

Subject line: [BIP Proposal] Utreexo Nodes

Date(s): July 29 - July 30, 2025

Discussion: Bitcoin Core contributors Calvin Kim, Tadge Dryja, and Davidson Souza have proposed three new Bitcoin Improvement Proposals (BIPs) that together create a way of verifying Bitcoin transactions without needing to store the entire UTXO (unspent transaction output) set.

As background, the UTXO set refers to the full list of all unspent bitcoins, or “outputs,” on the Bitcoin network. Every time a new transaction is initiated on Bitcoin, a Bitcoin node must check that the bitcoins being spent are included in the UTXO set and that the signature authorizing the transaction is valid. Only then can the transaction be validated and included in a Bitcoin block.

The three BIPs proposed by Kim, Dryja, and Souza describe a tool called Utreexo that has been under development since 2018. Utreexo eliminates the need for nodes to store the entire UTXO set, which is roughly 4GB, freeing up disk and RAM space on nodes and speeding up the process of syncing a new Bitcoin node, among other benefits.

It can be enabled through a consensus-compatible way, meaning no network-wide upgrades or forks are required for implementation. Kim noted in his email that the proposals are “not final” and subject to change, based on feedback from the Bitcoin developer community.

Kim said:

We are currently looking for conceptual review.

The 3 BIPs under review are:

The specification of the Utreexo accumulator, which is the cryptographic summary of the UTXO set that Bitcoin nodes would store in place of the full set. Its size is only about 1 KB.
The specification of Bitcoin block and transaction validation using the Utreexo accumulator.
The peer-to-peer networking changes required to enable Utreexo nodes.

Bitcoin Core contributor Javier Mateos responded to Kim, saying:

Thanks for sharing this important work ... It's exciting to see Utreexo maturing into a full BIP proposal. The modular split into the accumulator, validation, and P2P layers is very clean and helpful for review.

Takeaway: After years of research and prototyping, Utreexo is now ready for broader testing and review by the Bitcoin developer community. As with most BIPs, it is unlikely that Utreexo will be integrated into Bitcoin Core anytime soon, if ever. However, as a consensus-compatible change, adoption can be built for Utreexo among Bitcoin node operators who choose to enable its features locally through a forked version of Bitcoin Core.

🗞️Other News

Following the production-ready release of RGB, RGB Maintainer Maxim Orlovsky presents the formal specifications for the consensus of the RGB protocol, a smart contract protocol built atop Bitcoin and the Lightning Network. (Bitcoin Development Mailing List)
Blockstream engineer Russell O’Connor publishes a deep-dive post explaining Simplicity—a smart contract language designed for Bitcoin-like blockchains that recently launched on the Liquid sidechain. (Delving Bitcoin)
Bitcoin Core contributor “0xB10C” shares statistics on compact block reconstruction, a technique used by nodes to make block propagation across the network faster and more bandwidth-efficient. They suggest enabling the replace-by-fee (RBF) feature in nodes by default may improve block reconstruction speeds. (Delving Bitcoin)
Former Bitcoin Core contributor and moderator of Bitcoin Talk, Greg Maxwell (“gmaxwell”), explains the incentives at play when miners select transactions to include in a block and the ongoing efforts to improve transaction selection logic by the Cluster Mempool WG. (Bitcoin Talk)

🟠 That’s all for my round-up of the core discussions on Bitcoin from the past week. You are now officially caught up on the state of Bitcoin Core development and governance!

🙏 Thank you for reading this issue of BTC Before Light. If you like what you read, consider sharing it with a friend who might also enjoy the content.

💥If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by responding to the following poll or leaving a comment.