Issue 11: October 1, 2025

Bitcoin Core v30 RC 2, the last rallying cry against v30 before its final release, and Bitcoin Inquisition v29.1

Oct 01, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from the MuSig2 working group. They also discussed the creation of a new working group focused on architectural changes to node networking.

On the Bitcoin Developers Mailing List, opponents of Bitcoin Core made one last attempt to assert their views on transaction filtering policies and the dire consequences that may befall Bitcoin if their views are not adopted.

Finally, a new Bitcoin Inquisition release, featuring the activation of two new opcodes, is now available for Bitcoin developers to test on Signet. If you don’t know what Bitcoin Inquisition releases or Signet are, don’t worry. I give more context on these below.

But first, here’s a quick overview of Bitcoin Core’s software release schedule and the status of the next major release, v30, which is expected to be finalized this Friday, October 3.

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

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: October 3, 2025
Open issues: 9
Closed issues: 108
Milestone progress: 92%

(Previous week’s snapshot showed 8 open issues, 106 closed, and a milestone progress of 92%.)

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

🗒️New Working Group Alert: New Net Architecture

Discussion: Bitcoin Core developer “cfields” shared an update on his ongoing work to separate the Bitcoin code that manages network connections from the code that processes network messages. Cfields said:

I’ve had my head down for a few months now working on a logical separation between net and net_processing. I now have a quick/dirty branch that illustrates what needs to be done for that to happen. I intend to start cleaning that up and putting together a writeup of my proposed architectural changes and the reasons behind them next week...

This separation makes the architecture cleaner: one part of the software focuses purely on connecting to peers, while another part decides what to do with the data received from peers.

Cfields added:

With that done, I realized that I was 90% of the way to being able to split p2p out of bitcoin[daemon] completely, so I went ahead and did that too :) Using the (really cool, btw) multiprocess stuff, I’ve been able to hack up a fully-functional multiprocess bitcoin-p2p, which isolates all p2p/network activity to a separate process.

Using the libmultiprocess framework, which allows different parts of Bitcoin Core software to run independently and exchange messages, Cfields has isolated node networking activity into its own process. This separation improves node modularity and makes Bitcoin Core software easier and more secure to run, as network-facing code is isolated from the core logic that validates transactions and blocks.

Regarding next steps, Cfields said that he intends to demo his work at the next in-person Bitcoin Core developers event:

I intend to demo/discuss at coredev, but if anyone is interested in discussing before then, I’d be happy to. I think it’d probably be useful to start a working group for very high level discussion/debate.

Bitcoin Core maintainer “achow101” said new working groups to Bitcoin Core can be added to this Github page. Bitcoin Core maintainer “hebasto” asked to be added to Cfields’ network architecture working group.

Takeaway: Efforts to revamp Bitcoin node networking architecture may be formalized into a working group now that Cfields’ work on this project is ready for broader peer review and feedback.

Working groups in Bitcoin Core development are ad-hoc, self-organized teams that focus on specific protocol development initiatives. They are one of the primary ways that Bitcoin Core developers coordinate and sustain efforts to improve specific areas of the Bitcoin codebase without reliance on centralized leadership or project managers.

🗒️Other Topics

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

Developers created the second release candidate (RC) for Bitcoin Core v30 on Tuesday, September 23. No major issues were reported for the first v30 RC.
Cfields said they are working on a “quick fix” for v30 to Bitcoin Core’s libmultiprocess repository.

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.

📧 Email Thread

Subject line: [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts

Date(s): September 24 - September 29, 2025

Discussion: Aiden McClelland, the CTO of Start9 Labs, introduced a draft Bitcoin Improvement Proposal (BIP) that would enable node operators to program custom mempool validation and relay policies.

Rather than relying only on fixed command-line options like adjusting the datacarriersize for OP_RETURN, this BIP would significantly expand the flexibility of node operators to define their own mempool policies and decide what types of transactions their node will relay and keep in its database of pending transactions.

Former Bitcoin Core developer Gregory Maxwell responded, saying that the proposal undermines the utility of the Bitcoin mempool. Maxwell wrote:

This appears to substantially misunderstands the purpose of the mempool broadly in the network-- it’s purpose is to model what will get mined. If you’re not doing that you might as well set blocks only. Significant discrepancies are harmful to the system and promote centralization, and fail to achieve a useful purpose in any case. What marginal benefits might be provided do not justify building and deploying the technological infrastructure for massive censorship.

Chris Guida, a Bitcoin contributor who staunchly opposes the Bitcoin Core v30 release, supported McClelland’s proposal, saying he was “optimistic” that it could ease tensions in the Bitcoin community over transaction filtering policy changes in v30.

This is a very interesting proposal! It certainly has the potential to reduce tension over mempool policy by removing decisions over mempool policy from bitcoin core’s maintainers, who, if I understand correctly, are not very interested in being the arbiters of policy over the bitcoin network anyway. This seems like an excellent way to let users decide which transactions they will relay and which ones they won’t, which core maintainers have no control over anyway. I’m cautiously optimistic that this proposal can help break the logjam.

Other prominent developers in the Bitcoin community from both sides of the v30 debate chimed in on the thread. Knots maintainer Luke Dash Jr. encouraged the creation of a proof of concept for BIP.

Blockstream Director of Research Andrew Poelstra reiterated Maxwell’s arguments, writing:

The purpose of the mempool is to approximate the contents of blocks … Any sort of filtering beyond that done by miners is contrary to this purpose of the mempool.

Custodia Bank Co-Founder Bryan Bishop added that node operators don’t need advanced scripts to customize their mempool and relay policies. Operators can already do this. Bishop wrote:

Yes, even with a Core release, still developers around the world cannot dictate what software or rules the protocol users choose to run themselves, nor the contents of their mempools. For those purposes, it is clear that your filters do not work. They don’t achieve those goals, in answer to your question. If you want to run a mempool with filters, then you have not been unable to do that. If you want to run a node that does not gossip transactions or run a mempool, then you are again, not restricted from doing so.

In response to Maxwell, McClelland suggested that the Bitcoin community may feel compelled to initiate a “user-activated soft fork” (UASF), which could result in a chain split if Bitcoin Core developers choose not to support transaction filtering policies.

Wouldn’t it then be worse if these 80% of users went and ran an alternative implementation, most likely written by its most radical supporters? Or even worse still, felt compelled to coordinate a UASF to block these transactions entirely?

Takeaway: The outcry against Bitcoin Core developers is reaching a feverish pitch as the final v30 release is now only days away, targeted for Friday, October 3.

Critics of Bitcoin Core, such as McClelland, are warning of the risks of permanent chain splits unless Bitcoin Core developers reconsider their stance on transaction filtering policies.

This is the last chance for opponents of Bitcoin Core to sway the narrative about Bitcoin using their words before the reality of who uses Bitcoin Core software and how they use it takes over.

Once the final version of v30 is released, the threats of soft forks, illegal content overwhelming the blockchain, and alternative Bitcoin protocol implementations overtaking Core’s 80% node share will need to materialize; otherwise, the movement opposing Core will lose steam and credibility due to empty threats and non-existent emergencies.

Either the world is ending after v30, or it isn’t.

🖥️ Delving Bitcoin Thread

Subject line: Bitcoin Inquisition 29.1

Date(s): September 30, 2025

Discussion: Bitcoin Inquisition is a testbed version of Bitcoin Core that lets developers and researchers experiment with proposed soft forks and new opcodes.

Bitcoin Inquisition Version 29.1 is now out, based on Bitcoin Core release v29.1. The latest Bitcoin Inquisition release enables several BIPs, including:

BIP 118 – ANYPREVOUT
BIP 119 – CHECKTEMPLATEVERIFY (CTV)
BIP 347 – OP_CAT
BIP 348 – OP_CHECKSIGFROMSTACK
BIP 349 – OP_INTERNALKEY

Some of these, such as BIP 118, 119, and 347, have already been activated on Signet, a permissioned, developer-focused Bitcoin test network.

The newest ones, BIPs 348 and 349, will be activated soon on Signet within the week.

To test new features, node operators must connect directly to other Inquisition nodes on Signet. This behavior can be specified using strings such as “addnode=inquisition.bitcoin-signet.net.”

Bitcoin Core developer “ajtowns” added that the Bitcoin Inquisition Version 29.1 release also adds support for the send side of BIP 153 template sharing (a compact block relay optimization). That means even nodes that don’t support Inquisition code changes can still benefit from faster block reconstruction if connected to an Inquisition node.

Takeaway: The last Bitcoin Inquisition release, v28.1, was created earlier this year, in February. It notably enabled BIPs 118, 119, and 347, but not BIPs 348 and 349. Their inclusion in v29.1 highlights ongoing debate about how best to extend Bitcoin’s scripting capabilities and the multiple paths forward for greater levels of programmability for businesses and developers building on Bitcoin.

🗞️Other News

Rusty Russell, a Bitcoin Lightning developer at Blockstream, has shared a four-part proposal to enhance the flexibility and programmability of Bitcoin’s scripting language. (Bitcoin Development Mailing List)
A discussion thread about a new Bitcoin implementation called Bitcoin Knobs. Knobs is a fork (i.e., cloned from) Bitcoin Knots, which was forked from Bitcoin Core. (Bitcoin Talk)
A discussion thread about the historical precedent for the minimum transaction relay fee in nodes that will soon be lowered by default in Bitcoin Core v30. (Bitcoin Talk)
A technical explanation for why accurate and precise block timestamps are difficult to enforce through the Bitcoin protocol. (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.