Issue 09: September 17, 2025

Attempts to calm community fears about the v30 release and defenses of Bitcoin Core's integrity

Sep 17, 2025

Good morning,

The final stages of testing for the Bitcoin Core v30 major release are underway. On Thursday, Bitcoin Core developers briefly discussed the addition of three pull requests (PRs) to help calm community fears over the potential negative consequences of the v30 release.

The controversy of the v30 release is the main topic of discussion, overtaking seemingly all public forums where the Bitcoin community gathers.

Below is my write-up on the Bitcoin Core developers meeting that took place on Thursday, September 11, 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 (NEW)

Release Date: September 5, 2025

Upcoming Major Release: Bitcoin Core 30.0

Target Release Date: Early October 2025
Open issues: 11
Closed issues: 96
Milestone progress: 89%

(Previous week’s snapshot showed 6 open issues, 93 closed, and a milestone progress of 93%.)

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.)

🗒️Calming community fears about the V30 release

Discussion: During last Thursday’s Bitcoin Core developers meeting, Bitcoin Core developer “l0rinc” proposed three additional code changes, also called pull requests (PRs), for inclusion in the Bitcoin Core v30 release.

These include:

PR #33336 (log: always print initial signature verification state): Creates a clear log line that tells node operators whether signature verification is enabled at node startup and why. This makes it easier to understand when nodes may be doing more CPU-intensive work, which can feel like slower performance.
PR #33333 (coins: warn on oversized -dbcache): The -dbcache option in Bitcoin Core nodes allows node operators to set a value for the amount of computer RAM or memory that can be used for reading blockchain data, rather than from permanent disk storage. If node operators set this -dbcache option to a value that is too large, the computer’s operating system will run out of RAM and start swapping (using disk as pretend RAM), which is much slower than just using a smaller cache. This PR creates a warning message at node startup to warn against setting an oversized -dbcache value, which may lead to slow node performance.
PR #33324 (RFC: blocks: add -reobfuscate-blocks arg to xor existing blk/rev on startup): Since 2016, Core introduced a simple method for obfuscating block contents downloaded by a node for added privacy. This was specifically for node operators running Bitcoin Core software through a cloud service provider that may be conducting automatic scans of hosted activities for any illicit content. The obfuscation method does not encrypt any data, but rather, it simply makes it non-trivial for third parties to view block contents downloaded by a node. This PR creates a tool that allows long-time node operators who haven't utilized this default setting to do so without needing to resync their node from scratch and obfuscate all block content files stored by their node.

About his motivation for proposing these three PRs, L0rinc said:

People are scared for V30 and I think we could make a few changes that might help in calming the spirits.

The first two PRs address user complaints that new Core versions are slower or less performant than previous versions.

The last PR tries to address concerns that the uncapping of the OP_RETURN data carrier size limit will result in the storage of illicit content on the Bitcoin blockchain. PR #33324 simplifies the process for node operators concerned that hosting such content in their nodes might lead to their operations being banned on cloud services by allowing them to easily obfuscate this data.

Bitcoin Core developer “achow101” said about L0rinc’s proposals:

I think it might be a bit late to be adding draft PRs during the [release candidates], #33324 seems to have a number of open questions.

About PR #33324, Bitcoin Core developer “sipa” said:

Seems like a nice feature, but I don't think it's related to v30 or deserves special treatment.

Takeaway: Though the desire to try and address community fears about the forthcoming v30 release is commendable, the PRs themselves are not likely to be effective in addressing outspoken concerns and criticisms about the v30 release. In fact, anything short of reinstating the cap on the data carrier size is not likely to help bridge the growing rift between Core and Knots supporters.

These PRs are minor improvements to Bitcoin Core that will give marginal benefits to Core node operators, and do nothing for swaying the views of Knots proponents. Further, as mentioned by Achow101 and Sipa, the inclusion of these PRs comes extremely late in the Bitcoin software release cycle, as the release candidate for v30 is already in the process of testing and hardening.

🗒️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” highlighted an interesting discussion in the comments of PR #32317 (kernel: Separate UTXO set access from validation functions). About the nature of the discussion, TheCharlatan said, “The conversation there binds into the larger discussion of how many changes to the kernel motivated by external users the project can stomach.” They added that no resolution has been reached yet about the PR.

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.

Sipa has reviewed PR #28676 (Cluster mempool implementation). The author of the PR, “sdaftuar,” is currently working on addressing Sipa’s review comments.

QML GUI WG: An initiative to create a new modern graphical user interface (GUI) for Bitcoin Core using Qt Quick / QML (Qt Modeling Language).

Bitcoin Core developer “johnny9dev” gave a brief update, saying, “Working on adding QML testing on top of the unit test I added to get coverage on the views.”

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

PR #29675 (wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys) has gotten some review, but Achow101 highlighted that more review is still needed.

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.

🖥️ Delving Bitcoin Thread

Subject line: Addressing community concerns and objections regarding my recent proposal to relax Bitcoin Core’s standardness limits on OP_RETURN outputs

Date(s): May 14 - September 16, 2025

Discussion: As the weeks draw closer to Bitcoin Core’s finalized v30 release, contention is growing in the Bitcoin community over the issue of OP_RETURN data limits.

Old discussion threads about OP_RETURN, as well as new ones, are rising in popularity on several social media and Bitcoin discourse forums, such as X, Twitch, Delving Bitcoin, and Bitcoin Talk.

Bitcoin Core developers, who normally don’t engage with critics on social media, are actively responding on all platforms to defend their rationale and reputation, which continues to face fierce questioning and opposition from proponents who support an alternative implementation of Core called Bitcoin Knots.

On a recently resurrected Delving Bitcoin thread about the OP_RETURN data limit, Bitcoin Core developer “AntoineP” summarized Core’s stance on their decision to remove the data limit cap in v30, explaining that this decision does not materially change the types of data that can be stored on Bitcoin.

AntoineP wrote:

The legality of stored data does not depend of its encoding. Even if it did, it is trivial to get a large OP_RETURN output mined today regardless of the Bitcoin Core policy change. Assuming an attacker cannot pay a couple dollars premium or is unable to simply use a website is an uninteresting threat model. This risk is fundamental to Bitcoin, the proposed Bitcoin Core policy change does not materially affect this concern. What does make a difference and could put node runners at risk is fear mongerers trying to draw more public attention to this already existing issue.

In response to AntoineP, Bitcoin contributor “FernandoTheKoala” wrote that the technical motivation for the OP_RETURN policy changes in v30 is a narrow way to address concerns from users about the larger issue of Bitcoin’s changing use cases.

I don’t think it’s a realistic expectation to consider only technical merits and not take into account from whom the proposal is coming from, their potential interest/sitation, and how the whole proposal was managed. This constant attempt to force the whole conversation into the “technical box” only, and refusal to acknowledge any other aspect (social/economic/personal interest) prevents the conversation from being adressed from an holistic perspective and is not a realistic manner in which humans make decision. Continual refusal to not-acknowledge any non-technical aspect is what is creating the most damage to core my opinion.

Takeaway: The Bitcoin Core v30 release does not materially change the technical properties of the Bitcoin protocol to support (or discourage) non-financial use cases on Bitcoin.

Knowing this, it would stand to reason that the Bitcoin community should then focus on debating features and policies that do impact the protocol’s programmability for general-purpose use cases.

However, the persistence of discourse on the v30 release highlights that rather than disgruntlement regarding the technical features of Bitcoin Core, the core source of disagreement of this discourse is actually about the group of developers that build and maintain Core, their methods of governance, and ideologies.

In nearly every discussion thread about v30, the conversation, in some way or another, attacks Bitcoin Core for its integrity in stewarding the evolution of the Bitcoin protocol. Thus, defenses of v30 have now become one and the same with defenses of the institution that is Bitcoin Core.

🗞️Other News

Bitcoin contributor “/dev /fd0” shares the meeting transcript from a workshop on BIP 348, CHECKSIGFROMSTACK (OP_CSFS), held last Thursday. The next workshop in the series will take place this Thursday, September 18, and discuss different types of mining pool designs enabled by OP_CTV and OP_CSFS. (Bitcoin Development Mailing List)
Bitcoin contributor “Keyser Söze” shares two early draft BIPs aimed at improving wallet interoperability through the creation of two new standards for wallet backups and transfers. (Bitcoin Development Mailing List)
Bitcoin contributor “ZmnSCPxj” describes how Bitcoin’s Lightning Network could be used as a more reliable, high-availability payment system through the enabling of multi-party payment channels and parallelized transaction routing. (Delving Bitcoin)

🟠 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.