Issue 10: September 24, 2025

Ubuntu 22.04 support, malware signatures on the blockchain, and more possible v30 changes to quell community dissent

Sep 24, 2025

Good morning,

The debate about Bitcoin Core’s v30 release continues to rage on.

What’s most exhausting about this debate is that there is little to no progress week over week towards a conclusion or resolution.

Neither side of the debate is willing to concede any ground, and thus, a stalemate persists, with no clear end in sight, only ongoing division, fear, uncertainty, and doubt.

Before diving back into this rather dark topic, I summarize one of the main topics from last Thursday’s Bitcoin Core developers meeting, where developers discussed end-of-life support for Ubuntu 22.04, a popular Linux distribution slated for deprecation in 2027.

It was a nice reprieve for me to write about a Bitcoin development topic unrelated to v30, as I’m sure it will also be for recurring readers of this newsletter, who, like me, could use a break from reading about v30 drama.

I’ll admit it’s a short break, because after the Bitcoin Core developers meeting summary, we’re going straight back into the fire. ;)

Without further ado, below is my write-up on the Bitcoin Core developers meeting that took place on Thursday, September 18, 2025, and other core Bitcoin discussions from this past week.

Yours truly,

Christine D. Kim

Core Release Schedule

(For background on the Bitcoin software development process, refer to the Bitcoin Governance 101 document in the BTC Toolkit.)

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 29.1

Release Date: September 5, 2025

Upcoming Major Release: Bitcoin Core 30.0

Target Release Date: Early October 2025
Open issues: 8
Closed issues: 106
Milestone progress: 92%

(Previous week’s snapshot showed 11 open issues, 96 closed, and a milestone progress of 89%.)

Meeting Minutes

(Quotes featured in this section and the next may be edited slightly for grammar and clarity. For more information on the people quoted in this section, refer to the Bitcoin Project Contributor Directory in the BTC Toolkit.)

🗒️Ubuntu 22.04 Support: Taking Care of a Long Tail of Users

Discussion: At last week’s Bitcoin Core dev meeting, contributors debated how to best continue support of Ubuntu 22.04, a popular Linux distribution that certain node operators rely on to compile Bitcoin Core software from source.

Most users download pre-built binaries of Bitcoin Core, which are ready-to-run versions of the software. Compiling from source means downloading the project’s raw code and using your computer’s build tools (like CMake and compilers) to create the Bitcoin Core software yourself. Developers and advanced users often do this to test new features, customize builds, or ensure security by verifying every step of the process.

Bitcoin Core maintainer “hebasto” wrote:

Ubuntu 22.04 reaches end of standard support in April 2027. … By the time Bitcoin Core v31.0 is released, Ubuntu 26.04 LTS will be available. Ubuntu 22.04’s default repositories provide dependency packages that are outdated and problematic to maintain, such as: CMake 3.22.1, Qt 6.2.4, Cap'n Proto 0.8.0. Furthermore, Ubuntu 22.04’s default repositories do not provide the minimum required Clang version. My initial proposed action was to stop considering Ubuntu 22.04 as a build platform starting from the v31 release cycle.

He added that bumping the minimum CMake requirement for Bitcoin Core builds to version 3.25 would unlock “very useful” features for ongoing development, such as improved support for node optimizations and cleaner build scripts.

However, other developers in the meeting emphasized the risks of leaving users behind.

Core developer “Darosior” said:

Tangentially, I've had report of people stuck on [Bitcoin Core v]27 because of our glibc bump. Fanquake also had some. I would suspect there is more. It probably means a lot of people that won't upgrade in case of vulnerability disclosures. I don't know the upsides to breaking support for some platform in this instance, but I'd like to underline there are.

Core maintainer “Achow101” said:

If Ubuntu 22.04 is supported until 2027, I’d rather not drop support for it until it is EOL [end-of-life].

As a possible compromise, developers discussed making new features in Bitcoin Core that depend on newer versions of CMake build tools optional. Hebasto said:

Features that depends on cmake policy can be enabled optionally.

They also discussed creating a new static build of Bitcoin Core that would reduce compatibility issues across different Linux distributions.

Takeaway: Developers are exploring ways to continue supporting Ubuntu 22.04 until its official end-of-life in 2027. However, in doing so, they may request that node operators using this Linux distribution upgrade certain build tools, such as CMake.

The discussion highlights a tension that exists in both Bitcoin and Ethereum protocol development. Whilst developers of these protocols seek to push software advancements forward, they seek to do so ideally without cutting off the long tail of users who secure the network on diverse hardware and operating systems.

🗒️Other Topics

Kernel WG: The Kernel WG aims to modularize Bitcoin Core by isolating and organizing consensus-critical logic from wallet code, user interfaces, and other non-consensus-critical components.

Bitcoin Core developer “TheCharlatan” requested review of PR #30595 (kernel: Introduce initial C header API). About the PR, TheCharlatan said, “A bunch of people and teams are building on top of it now, which led to a bunch of improvements on it the past few months.”

Cluster Mempool WG: An initiative to build a graph-based mempool that would enable nodes to reason about the relationship between unconfirmed transactions and bundle related ones together for improved transaction fee estimation, prioritization, and storage.

Bitcoin Core developer “Sipa” said the review of PR #28676 (Cluster mempool implementation) is ongoing.
Additionally, PR #33157 (cluster mempool: control/optimize TxGraph memory usage) is nearing completion.

Stratum V2 WG: Stratum V2 is a mining protocol that enables Bitcoin miners to create their own block templates and influence transaction inclusion in blocks, thereby decentralizing and democratizing the power away from Bitcoin mining pools.

Bitcoin Core developer “Sjors” requested review of PR #33374 (mining: add applySolution() to interface). Since Thursday’s meeting, there has been additional discussion about the PR.
Bitcoin Core maintainer “Ryanofsky” asked about it, “Main question is why is this new applySolution method needed at all if submitSolution() modifies the block and there is already a getBlock() method?”
Sjors acknowledged there is no need for the new method and has since closed the PR.

MuSig2 WG: An initiative to modernize the cryptographic scheme that combines multiple signatures authorizing a Bitcoin transaction into a single, compact signature.

Achow101 said they are addressing comments on PR #29675 (wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys).

Bitcoin Core v30 Major Release: The next major version of the Bitcoin Core software. For a detailed breakdown of major changes in the v30 release, refer to this prior BTC Before Light issue.

It has been two weeks since Bitcoin Core developers created the first release candidate (RC) for Bitcoin Core v30. They are now preparing to create the second RC. The full list of changes incorporated into v30 RC2 can be found here.
About the v30 release, Bitcoin Core developer “L0rinc” said, “For the record, I've compared V30 to previous releases (23-29) and it seems V30 is exactly 2x faster than v25 thanks to all the optimization efforts in the past releases.”

You’ve Got Mail! (& Other News)

(For a comprehensive overview of all major Bitcoin development meetings and forums, refer to this post in the BTC Toolkit.)

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

🪙 Bitcoin Talk Thread

Subject line: Security disclosure, OP_RETURN embedding of Malware signatures into Blockchain

Date(s): September 17 - September 21, 2025

Discussion: One of the most popular arguments against uncapping the datacarrier size limit in the OP_RETURN field of Bitcoin transactions is the worry that this change in the Bitcoin Core v30 release will result in illegal, malicious, and otherwise unsavory data on the blockchain.

To be clear, this data in the OP_RETURN field can be provably pruned by Bitcoin nodes after blocks have been processed. However, the concern is that the existence of this data in nodes before pruning will heighten the operational risk of running a Bitcoin node, especially on cloud services where regular scans of user activity are conducted for any illegal data or content.

Risks that Child Sexual Abuse Material (CSAM) will overrun the OP_RETURN field have been emphasized recently by prominent Bitcoin community members, such as Ocean Mining CTO and Bitcoin Improvement Proposal (BIP) Editor Luke Dash Jr.

In a recent Bitcoin Talk thread, one community member, “wrapperband0lite,” wrote that malware-like signatures can be embedded in Bitcoin. They wrote:

A regtest reproduction shows that AV-signature-like bytes (canonical EICAR test string) can be embedded in an OP_RETURN output, mined into a block, and persist in chain data. … Increasing OP_RETURN capacity enables embedding of malware-signature-like strings (and potentially larger payloads) into immutable chain data. Routine AV scans of blocks/, backups, or archives may produce false positives (or fail inconsistently), causing: quarantine, deletion, operational incident response. This is a risk for node operators, exchanges, and custodians who store blockchain data.

Bitcoin Core maintainer “Achow101” responded:

This is neither new nor unique to OP_RETURN. It has been possible to embed virus signatures into the blockchain for a very long time. I'm pretty sure the Eicar string is already in the blockchain, and has been in it, for well over a decade. … UTXO set obfuscation exists because of virus signatures in outputs since AVs were quarantining the database files. This was implemented over a decade ago. Blocks obfuscation was recently added as well, for similar reasons, although block files typically were not being quarantined because they are too big.

Former Bitcoin Core developer “Gmaxwell” added that the type of attack against Bitcoin node operators described by Wrapperband0lite is already possible.

Large op_returns from an attack perspective *cannot be prevented* (without a consensus change which no one has proposed) because the attacker can just use nicehash and rent hashpower, also because major miners *already eliminated the limit*, and one need only directly hand the transaction to their nodes.

Takeaway: Block and transaction-level obfuscation techniques already exist in Bitcoin Core to reduce the risk of automatic scans of node activity triggering unwanted node quarantines or shutdown responses.

Moreover, as Gmaxwell notes, the likelihood in an extreme case of large amounts of illegal data being purposefully stored on Bitcoin in such a way that evades obfuscation techniques remains the same regardless of the change to the datacarriersize limit in OP_RETURN.

The arguments that Bitcoin Core v30 will certainly make it easier for unsavory data to proliferate on Bitcoin are unreasonable. As stated in this BTC Before Light issue, technical arguments against Bitcoin Core v30 are mostly masking deep distrust of the institution that is Bitcoin Core, rather than being rooted in the factual realities of how the Bitcoin Core software works.

👾 Bitcoin Pull Request Conversation

Subject line: docs, Undeprecate datacarrier and datacarriersize configuration options

Date(s): September 22 - September 23, 2025

Discussion: In an attempt to quell growing distrust of Bitcoin Core, Mike Schmidt, the executive director of Brink, an organization that funds Bitcoin Core development, proposed a pull request (PR) to change documentation in Bitcoin Core v30 that states the datacarriersize limit will be deprecated in a future release.

Schmidt wrote:

Many current Bitcoin Core users want to continue using [the datacarriersize] option. … The deprecation intent is unclear to users. This echo’s Ava Chow’s comment from #32714 that “IMO we should not have removal warnings if there is no current plan to actually remove them.” In months since that comment, partially due to increased feedback from Bitcoin Core users wanting to keep this option, there is even less likelihood of a near term plan to remove these options. That leaves Bitcoin Core users in an unclear situation: the option could be removed in the next version or perhaps never.

So far, 22 Bitcoin Core developers and Bitcoin contributors have responded to the PR in the comments. Eighteen are in favor of the general goal or approach, and four are against it.

Of those who support the proposal, many acknowledge that, although minor, the change in the documentation language of the v30 release will help signal to Bitcoin Core users that those who want to use data carrier size options to filter transactions may possibly continue to do so in future Core releases.

Bitcoin Core developer “Kevkevinpal” wrote:

I agree that removing the deprecation does not have a major effect on users, and it also gives users who want to use this flag a signal that it will not be removed in a future release. I see no issue in offering flexibility for node runners.

Of those who were against the proposal, some viewed the PR as a concession to unreasonable demands.

Swan Bitcoin Engineer Manager Brandon Black wrote:

Bitcoin Core is not here to be everyone's everything implementation. It's here to be the best software for operating the network. Adding, or in this case not removing, code with only negative effects on the actual operation of users' nodes is not responsible stewardship of bitcoin. Bowing to demands from people who do not understand what they are asking for (as repeatedly demonstrated in online argumentation) is not how any successful project can operate.

Others viewed the PR as not going far enough to address community concerns. Bitcoin contributor Chris Guida wrote:

It does not matter whether this option is deprecated or not. With the merging of #32406, core has already signaled that it is absolutely unwilling to address data spam, ever, and is now accelerating towards spam maximization.

Takeaway: Bitcoin Core developers are not backing down from changing the default limit of datacarriersize options in nodes.

The PR in question simply reaffirms that it is unclear how exactly developers may change these options again in future Core releases, which leaves the door open to further discussion and debate on the efficacy of filtering transactions through datacarriersize.

However, in the current discussion on this matter, Core developers have already made it abundantly clear that the limitations introduced by these options are not effective and conflict with the economic incentives of the network.

Knowing this, it is difficult to see any future where developers meaningfully facilitate the use or maintenance of datacarriersize options. In doing so, they would be directly contradicting their own technical reasons for changing the default settings for these options in the first place.

It is unlikely that Core developers would revive the material use of datacarriersize options in their software to appease proponents who adamantly believe in the efficacy of these options.

Thus, there is little to no benefit in a PR that makes no changes to Core’s views on this issue, and only clarifies that their expected timeline and detailed approach to full deprecation remain to be determined.

🗞️Other News

Bitcoin contributor Toby Sharp is working on creating minimal, executable specifications for the Bitcoin protocol. One of the core motivations for this project, called Hornet, is to encourage client diversity in Bitcoin through “a formal specification that can be robustly implemented, tested, and ideally formally proven by a client [implementation].” (Bitcoin Development Mailing List)
Bitcoin contributor “Guardian” is requesting feedback on two draft BIPs that create a new protocol and wallet implementation designed to protect user funds in the event of a physical, also known as a “wrench” attack. (Delving Bitcoin)
Bitcoin Lightning developer Matt Morehouse posted a disclosure about a critical vulnerability that allows attackers to steal node funds in the Eclair Lightning implementation. Users should immediately upgrade to Eclair 0.12.0 or later to protect their funds. (Matt Morehouse Github)
A community discussion about the benefits and timeline for Utreexo, a project from MIT’s Digital Currency Initiative that could significantly reduce storage and memory requirements for Bitcoin nodes. (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 leaving a comment.

Discussion about this post

Ready for more?