Good morning,
After one week of in-person meetings, Bitcoin Core developers are back to their regular online Thursday meetings.
Last Thursday, they discussed updates from the following working groups: Kernel, Cluster Mempool, Script Validation, Benchmarking, and QML GUI. They also discussed a few housekeeping items regarding the format of the Thursday meetings.
Yesterday, Bitcoin Core developers finalized a major feature introducing Bitcoin’s first public interface for interacting with the protocol’s consensus code. I explain the significance of this feature in more detail below.
I also share takeaways on ongoing discussions about Bitcoin upgrades for the post-quantum future.
Let’s get into it.
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, a quick overview of Bitcoin Core’s software release schedule and the status of the next major release:
Latest Stable Major Release: Bitcoin Core 30.0
Release Date: October 13, 2025
Latest Stable Minor Release: Bitcoin Core 28.3
Release Date: October 17, 2025
Upcoming Major Release: Bitcoin Core 31.0
Target Release Date: April 10, 2026
Open issues: 6
Closed issues: 4
Milestone progress: 40%
The previous week’s snapshot showed 9 open issues, 1 closed, and a milestone progress of 10%.
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.)
Kernel WG: The Kernel WG aims to modularize Bitcoin Core by isolating consensus-critical logic from wallet code, user interfaces, and other non-consensus-critical components.
Bitcoin Core developer “TheCharlatan” is still seeking more review of PR #30595 (kernel: Introduce C header API). Since last Thursday’s meeting, this PR has been merged.
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 “Instagibbs” said review is needed on PR #33629 (cluster mempool).
Script Validation WG: This group focuses on improving the performance, security, and flexibility of Bitcoin’s script execution and signature validation systems.
Bitcoin Core developer “Fjahr” requested feedback on PR #33740 (RFC: bench: Add multi thread benchmarking).
Benchmarking WG: Efforts to measure and improve the performance of Bitcoin Core software through benchmarking, that is, analyzing how long certain processes take.
Bitcoin Core developer “L0rinc” said he has been discussing parallelizing block input operations with Andrew Toth, a developer at Bitcoin wallet company Exodus. Initial benchmarks show a 25% increase in block reindexing speeds on resource-constrained devices such as a Raspberry Pi. L0rinc said investigations for this are ongoing.
L0rinc also raised two ideas that they have been discussing with Bitcoin Core developer “Sipa.” The first would shrink the on-disk UTXO set size by 1% and slightly speed up initial block download (IBD) sync times. The second idea involves using a simpler hash function for temporary data that could result in 4% faster IBD syncs.
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” is working on the build system for the new GUI. They said they will soon share their work using one build system (“depends”) as a PR.
🗒️Meeting Highlights
Discussion: After the working group updates, the meeting chair, Bitcoin Core maintainer “Achow101,” raised the topic of rotating meeting chairs. They said:
As was mentioned last week, we should have more than one person doing [Internet Relay Chat] meetings. Since we have previously fallen into the trap of the tragedy of the commons when there wasn’t anyone who was specifically supposed to do it, I think we should set up a rotation of 3 or 4 people.
Fjahr, Bitcoin Core developer “stickies-v,” and Bitcoin Core developer Abubakar Sadiq volunteered for the role.
Bitcoin Core developer “dergoegge” asked whether a bot could run the meetings. They asked:
I can prototype a bot, and we can test it out?
There was no opposition to testing out the idea.
Developers also discussed automatically deprecating working groups that do not have representatives to share updates on their group’s progress after a certain number of consecutive missed Internet Relay Chat (IRC) meetings.
Stickies-v, Sadiq, and others were in favor of the idea. Developers agreed to set the number to two consecutive missed IRC meetings, without prior notice, to start.
Takeaway: At face value, these are minor, housekeeping changes to the Bitcoin Core development process. They do not affect the ongoing development work in Bitcoin Core.
However, they do affect the communication and coordination of Bitcoin development. The rotating chairs of the IRC meetings are a way to share the responsibility of keeping weekly development meetings going between multiple Bitcoin developers, instead of one. Rotating chairs also helps decentralize the power of this role, so that one person is not in charge of an important touchpoint for Bitcoin developers indefinitely.
Though minor, these adjustments to the Bitcoin development process are indicators of an active governance protocol working behind the scenes through norms and formalized rules to oversee the evolution of the Bitcoin technology.
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.)
A round-up of the core discussions that happened this past week from the Bitcoin Development Mailing List and other Bitcoin discussion forums:
📧 Email Thread #1
Subject line: [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
Date(s): October 31 - November 2, 2025
Discussion: On Friday, October 31, a Bitcoin investor and developer by the name Juan Aleman proposed a reorganization of the Bitcoin Core Github repository. The reorganization is warranted, as Aleman wrote, due to the changes included in the Bitcoin Core v30 release.
However, the v30 release itself may have caused a point of no return, where “globally agreed standardness” is no longer a realistic expectation. Bitcoin’s hidden limits are being revealed. … To address humans’ flaws, I suggest reorganizing the repository structure to better safeguard against unwarranted political (policy) influence.
To remove Bitcoin Core as a centralized point of failure in Bitcoin, Aleman suggested renaming the Core repository from bitcoin/bitcoin to bitcoin/bitcoin-core.
(As a side note, there is already a separate project called Bitcoin Core, which hosts ancillary repositories related to bitcoin/bitcoin. For more information about the Github structure of the Bitcoin project, refer to this resource in the BTC Toolkit.)
Aleman also suggested creating separate repositories under the bitcoin/bitcoin repo to host full-featured client implementations of the Bitcoin protocol.
Speaking to the goal of his proposal, Aleman wrote:
This proposal attempts to find a compromise where no side feels “forced to comply” and represents a more neutral position from the “Official Reference Implementation” repository in this new era.
Bitcoin Core developer encouraged Aleman to review the Kernel project, which seeks to extricate Bitcoin’s core consensus logic from the rest of the node software (i.e., networking, wallet, policy, GUI, etc.).
Recently, PR #30595 (kernel: Introduce C header API) was merged, introducing the first public interface (API) that lets other software interact directly with Bitcoin’s core validation logic — the rules that check whether blocks and transactions are valid — without needing to run the entire Bitcoin Core node.
To suggestions that he review the Kernel project, Aleman responded:
The main issue here is with the bitcoin/bitcoin repo itself. A single authority with too much influence, now escalating to the point of a fork over defaults. The power of defaults. I don’t know how you feel about this whole situation, but for me, it’s quite uncomfortable to be in deep conflicts with peers, and even friends. But “CoreDevs” seem way too invested to remain unbiased, clearly missing the forest for the trees.
Bitcoin Core developer Antoine Riard pushed back on the sentiment that Bitcoin Core is corrupt. Riard wrote:
In my view, the root of the problem is not that “Core” is “corrupted” or
“compromised”. It’s a human institution, so of course there are things that
can be improved, and things are constantly improved. The real problem is that most of the time, the dissatisfied of the Core process don’t have the cold
determination to go for real in developing their own alternative bitcoin
clients, with its own set of features, its own culture of development and
in patiently growing its user base.
Takeaway: A change in the Github repository structure for Bitcoin Core is a surface-level change that only impacts the optics of Bitcoin Core. As many Core developers point out in the email thread, it is also a change anyone can make by forking the current repository and renaming it with a new structure.
What matters is giving developers the practical tools to verify, validate, and build their own Bitcoin clients. To this end, the merging of PR #30595 is a big deal. This PR was merged on Tuesday, November 4, and marks the first major milestone in the Kernel project.
For most of Bitcoin’s history, the Bitcoin Core repository has defined how the Bitcoin protocol works, its rules of consensus, and a bunch of other ancillary features and operations in Bitcoin nodes.
Without a clear distinction between Core code and Bitcoin consensus code, which, again, has been one and the same for most of the protocol’s history, it is difficult for non-Core developers to develop alternative Bitcoin implementations.
Thus, extricating Bitcoin’s consensus logic from Bitcoin Core is essential to promoting client diversity and greater levels of neutrality in the Bitcoin protocol. PR #30595 represents a major step forward in these efforts.
📧 Email Thread #2
Subject line: OP_CIV - Post-Quantum Signature Aggregation
Date(s): November 1 - November 2, 2025
Discussion: On Saturday, Lightning network developer Tadge Dryja shared an idea for a Bitcoin feature called OP_CIV (“Check Input Verify”). It’s designed to make post-quantum (PQ) Bitcoin transactions smaller and cheaper.
Dryja presented it at the Bitcoin TAB Conference last month.
Explaining the motivation for the idea, Dryja wrote in the email thread:
One place where the size of signatures *is* a problem is with post-quantum signatures. The two most discussed PQ signature schemes, SPHINCS+ and CRYSTALS-Dilithium, both have pubkey+signature sizes in the kilobytes range. This would be a great opportunity for [cross-input signature aggregation], since even with a 75% witness discount, signatures would cost over 90% of the vBytes in a transaction.
Cross-input signature aggregation (CISA) combines multiple Bitcoin signatures into a single signature, reducing transaction size and lowering fees.
OP_CIV would enable CISA by proving the linkage between signatures within the same transaction. Dryja wrote:
The basic idea is that a transaction input can prove a linkage to another input within the same transaction, and by pointing to another input say “that’s the signature I’m using”, without providing one of its own. Take for example a transaction with 2 inputs: input 0 and input 1. Input 0 has a normal (perhaps PQ) SIGHASH_ALL signature. Input 1 has a proof pointing to input 0. Since input 0 exists within the transaction, input 1 is valid.
Bitcoin researcher “Conduition” responded in the email thread that OP_CIV may not be feasible with the current Bitcoin wallet set-ups. However, it may work if addresses, rather than transaction inputs, can be linked together.
Conduition suggested:
Consider a more conservative (but also very common) use case: Aggregating inputs controlled by the same owner. In this context, what the sender is really trying to prove here isn’t whether UTXO A committed to UTXO B. For signature aggregation across commonly-owned inputs, they just need to be able to prove that UTXO A and UTXO B are spendable under the same pubkey, and that they, the pubkey owner, authorized both of them via a single signature.
Lightning Labs Infrastructure Engineer Boris Nagaev expanded on Conduition’s idea, suggesting a numbered index system for wallet addresses that could make linkages deterministic and recoverable with a user’s seed phrase.
Dryja responded, saying that he would look into these suggestions further.
Thanks for the feedback on this & I will also keep looking at it.
Takeaway: The future of Bitcoin in a post-quantum era remains uncertain. When I started this newsletter in July, the main topic of discussion among Bitcoin developers was securing Bitcoin against PQ attacks.
Now, the main topic of discussion is the controversy of Bitcoin Core v30 and soft fork proposals that limit on-chain data storage. Though the recent concerns from both sides of the controversy are pressing, they are detracting from the still ongoing, but less discussed, topic of Bitcoin’s PQ future.
Since July, Bitcoin developers have not agreed on a plan for making Bitcoin quantum-resistant. Bitcoin will need an upgrade—likely a few— to continue operating in a PQ world. Proposals like the one described above are not as timely as those on transaction relay policies, but they are equally important to Bitcoin’s long-term future.
🗞️Other News
An analysis of Bitcoin node performance over the past decade, since Bitcoin Core switched its cryptography library for signature validation from OpenSSL to libsecp256k1. (Delving Bitcoin)
A new tool that lets users write, visualize, and analyze Bitcoin spending policies, with live compilation, Taproot support, descriptor handling, and cost analysis, created for developers exploring advanced Bitcoin scripting. (Delving Bitcoin)
Blockstream engineer Russell O’Connor publishes his fourth post in a series explaining Simplicity—a smart contract language designed for Bitcoin-like blockchains or sidechains. (Delving Bitcoin)
Bitcoin Core contributor “0xB10C” shares updated statistics on compact block reconstruction, a technique used by nodes to make block propagation across the network faster and more bandwidth-efficient. (Delving Bitcoin)
The annual Bitcoin Talk Pumpkin Carving competition ended over the past weekend. There were 116 submissions! The winners have not yet been announced. (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.
🌟 Finally, if you’re a premium subscriber, don’t forget to join the subscriber channel on Telegram. It’s an exclusive space to discuss the evolution of Bitcoin Core and Ethereum with fellow readers. The invite link to join is posted here:
Newsletter credits:
Special thanks to Shinhye Kim for the illustrations in this newsletter.
