Issue 00: July 16, 2025
Erlay simulation results, the counterproposal to OP_CTV, & Lopp's post-quantum action plan
Good morning,
Last Thursday, Bitcoin Core developers discussed updates from six different working groups: Erlay, Kernel, Cluster Mempool, MuSig2, QML GUI, and Orphan Resolution.
Also, on the Bitcoin Development Mailing List, they discussed a new competing proposal to OP_CTV authored by three Bitcoin Core developers and a proposal by Casa Co-Founder and Chief Security Officer Jameson Lopp to sunset Bitcoin’s legacy cryptographic signatures in anticipation of future quantum computing threats.
Below is my write-up on the Bitcoin Core developers meeting that took place on Thursday, July 10, 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: 32
Milestone progress: 76% of issues are resolved
Meeting Minutes
Editor’s note: Some quotes featured in this section and the next have been edited slightly for grammar and clarity.
🗒️Erlay simulation results
Discussion: Sergi Delgado, a Bitcoin Core developer at Chaincode Labs, reported new simulation results for Erlay. As background, Erlay (short for Efficient Transaction Relay for Bitcoin) is a proposed upgrade to Bitcoin's peer-to-peer (p2p) layer that aims to reduce node bandwidth consumption by changing how nodes announce and relay unconfirmed transactions across the network.
Delgado reported:
I've been running sims in networks up to 200 nodes on Warnet, and what I’ve observed is that, for these sizes, we can achieve ~24% savings in INV messages for ~35% more latency. This is slightly better than what I saw when simulating in the actual network event simulator (the prospected was 40% more time for 21% savings), but pretty much in line.
He added that the tradeoff between bandwidth savings and increased latency improves as the network grows. However, testing Erlay on larger Bitcoin testnets has proved difficult:
I haven’t been able to run reliable simulations for bigger networks, since I have been struggling with limitation in the current approach for capturing results.
Delgado said he is exploring alternative approaches and working on making his simulations easily reproducible by other developers.
Takeaway: Bitcoin developers have been working on Erlay for over six years, steadily advancing the idea from a 2019 research paper to simulations and implementations as of 2025. It’s one of the longest-running efforts to improve Bitcoin’s peer-to-peer layer. Though it still appears a long way from finalization, developers are making progress.
🗒️C header API for Bitcoin kernel
Discussion: “TheCharlatan,” a Bitcoin Core developer sponsored by Spiral, resurfaced a pull request for the creation of a new minimal API written in C for Bitcoin kernel.
As background, kernel refers to a software library under development by TheCharlatan and others that encapsulates Bitcoin's core validation logic—everything needed to determine whether a block or transaction is valid and extends the current best chain—without including networking, RPC, wallet, or GUI code. It is a long-term project that seeks to modularize Bitcoin Core by cleanly separating consensus-critical logic from non-essential components.
In the latest meeting, TheCharlatan said:
Looking for some comments again on the approach in #30595 regarding having a C or a C++ API as a first class citizen for the library. … We've had the debate for over a year now, and I implemented both variants, but people either stopped weighing in or still seem undecided. [It] would be good to get this rolling again, especially since more people seem to be getting interested.
Takeaway: A minimal C interface for the Bitcoin kernel could unlock a more portable, embeddable version of Bitcoin’s core protocol logic, benefiting GUI developers, wallets, and new integrations. However, with the bulk of Bitcoin Core’s code being written in C++, there are concerns that the API may become a burden on developers to maintain and introduce added complexity to the kernel.
🗒️Other Topics
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.
MuSig2 WG: An initiative to modernize the cryptographic scheme that combines multiple signatures authorizing a Bitcoin transaction into a single, compact signature.
PR #31244 awaits review.
QML GUI WG: An initiative to create a new modern graphical user interface (GUI) for Bitcoin Core using Qt Quick / QML (Qt Modeling Language).
Developers discussed different approaches to organize the project going forward.
“Johnny9dev” suggested a submodule approach with Bitcoin Core as a submodule to the QML GUI GitHub repository, aiming to avoid the WG having to repeatedly copy Bitcoin Core code into the QML GUI GitHub repository.
They agreed to try this submodule approach for now.
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.
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 #1
Subject line: "A Taproot-native (re-)bindable transaction bundle proposal"
Date(s): July 9 - July 15, 2025
Discussion: Greg Sanders, a Bitcoin Core developer sponsored by Spiral, along with Antoine Poinsot, a Bitcoin Core developer sponsored by Chaincode Labs, and Steven Roose, CEO of Bitcoin payments platform Second Tech, have introduced a new proposal that updates and simplifies a previously discussed feature known as OP_CHECKTEMPLATEVERIFY (CTV).
As background, OP_CTV is a proposal from 2019 that lets Bitcoin users pre-approve exactly how their coins can be spent, adding new safety and automation options to Bitcoin transactions. Last month, James O’Beirne, Senior Software Engineer at New York Digital Investment Group (NYDIG), spearheaded efforts to revive the discussion on OP_CTV and rally support for the opcode in the Bitcoin community.
The new proposal, called OP_TEMPLATEHASH, is designed to be better aligned with Bitcoin’s modern Taproot system, which was activated on Bitcoin in 2021 and introduced a new address type, as well as a modernized scripting system for creating spending conditions on coins. OP_TEMPLATEHASH builds on Taproot directly and avoids interactions with legacy parts of Bitcoin’s scripting system, like scriptSigs.
O’Beirne commented on Thursday about the “counterproposal” to OP_CTV and raised a few concerns. One of them was the fact that OP_TEMPLATEHASH can only work in the context of Taproot, and many large Bitcoin users still rely on older address types. He wrote:
I think the lack of TEMPLATEHASH's availability in a witness v0 script context will significantly limit its deployability for at least the next few years and possibly permanently for some users. Right now, two separate estimates put Taproot usage (by value) at 0.1% or 0.75% as of May 2025. … This is nearly four years after its
activation.
Poinsot refuted O’Beirne’s concerns about a lack of Taproot usage, saying that usage has quadrupled since the beginning of 2024 and reiterated that developers should not provide new features “for an outdated scripting context unless we have a strong reason to.”
Poinsot later added:
We all wish Bitcoin users adopted the latest technology faster than they do, but this is probably only going to get slower as Bitcoin matures. And the trend from the past year gives some reason to be optimistic. In any case, none of this is a reason to incentivize users to stay on older versions of the scripting context by going out of our way to also enable new features there. If anything the slight nudge to upgrade to Taproot should be seen as a good thing.
Takeaway: The new proposal signals a willingness from Bitcoin Core developers to engage with the goals of OP_CTV, but to do so in a more forward-compatible, Taproot-native way. As highlighted in a signed letter last month, the OP_CTV community is sizable and committed. Therefore, their support is critical for this newer approach to gain traction. At this stage, neither proposal has achieved broad consensus, and meaningful progress for either will likely require compromise from both camps.
📧 Email Thread #2
Subject line: New BIP Editors, 1 Year Later
Date(s): July 14, 2025
Discussion: Ava Chow, a Bitcoin Core developer employed by Blockstream, shared a review of the Bitcoin Improvement Proposal (BIP) process since the addition of five new BIP editors last April. She noted that since the expansion in the number of BIP editors, BIP-related activity on GitHub has skyrocketed:
She wrote:
In the 15 months prior to adding the new BIP Editors, the BIP Editors had left 80 comments, merged 44 [pull requests], closed 6 PRs, [and] assigned 4 BIP numbers. In the 15 months since adding the new BIP Editors, the BIP Editors have left 1272 comments, merged 261 PRs, closed 122 PRs, [and] assigned 22 BIP numbers.
That said, Chow also noted that there is high variance in contributions and activity between BIP editors. She wrote:
This raises the question of whether all of the current BIP Editors want to dedicate their time to serving the community in this role, and whether there are others who could take their place as well.
Takeaway: In 2024, Bitcoin Core developers decided to expand the group of BIP editors from one person to six in direct response to concerns about the extremely slow review of BIPs. These decisions have proven to be highly effective. The BIP process has gone from sluggish to highly active in just over a year — a clear win for Bitcoin development. However, there’s still room for improvement, as Chow notes, and a continued need for periodic review of this critical role in Bitcoin Core development to proactively address bottlenecks in the BIP process.
📧 Email Thread #3
Subject line: A Post Quantum Migration Proposal
Date(s): July 12 - July 15, 2025
Discussion: In follow-up to his earlier thread about the philosophical and technical considerations of a quantum-resistance upgrade on Bitcoin, Jameson Lopp, Co-founder and Chief Security Officer of Casa, has formalized a proposal for the introduction of BIP 360, pay-to-quantum-resistant-hash (P2QRH) address types, and deprecation of legacy address types that rely on non-quantum secure cryptography ECDSA and Schnorr signatures.
His proposal has three stages:
Phase A: Disallow sending to quantum-vulnerable addresses, nudging adoption of P2QRH outputs.
Phase B: Declare a future “flag day” when all ECDSA/Schnorr spends are invalidated — rendering any un-upgraded funds permanently unspendable.
Phase C (optional): Explore recovery of legacy coins through zero-knowledge (ZK) proofs of a user's seed phrase.
Lopp’s proposal is mostly soft-fork compatible, meaning these changes would all be backwards-compatible. However, Phase C may require a hard fork, or backwards-incompatible code change, if completed later and independently from the other phases.
The proposal has triggered strong reactions in the Bitcoin community.
Tadge Dryja, a Bitcoin developer who works at Lightspark, called the plan “not viable,” arguing that tying new upgrades to disabling old features could backfire by freezing legitimate user funds too early without clear evidence of a quantum threat. Dryja said:
Sure, there can be risks from [cryptographically relevant quantum computers]. But this proposal would go the other direction, disabling important functionality and even destroying coins preemptively, in anticipation of something that may never happen.
Independent Bitcoin developer Antoine Riard expressed concerns about the broader implications of Lopp’s proposal and the precedent it would set for future Bitcoin upgrades. He said:
I'm worried this is opening a Pandora box, where we would introduce a precedent
that it is legitimate as a community to technicaly confiscate some coins of users,
without their _consents_, for extra-ordinary reasons. ... There is no guarantee that this precedent won't be leveraged in the future by any group of entities to justify future upgrades eroding one of the "fundamental property" you're yourself deeming as valuable.
Ethan Heilman, researcher at Cloudflare and a research fellow at the MIT Digital Currency Initiative, weighed in with his views on why a soft fork to freeze quantum-vulnerable coins is inevitable from an economic perspective.
He explained that in the event of a quantum attack, where a malicious actor starts to steal vulnerable coins and the USD value of bitcoin plummets, rational miners will have no choice but to freeze vulnerable coins to save the value of the chain to avoid mining at a “massive loss.”
Heilman added:
Note that such a death spiral and the incentives for a soft fork are possible prior to quantum attacks on Bitcoin. Merely the threat of quantum attacks and the widespread belief that Bitcoin will not freeze unspendable coins and thereby inflate the supply of spendable bitcoin.
Takeaway: As Lopp notes himself, his proposal is radically different from other Bitcoin proposals because it enforces a strict deadline by which users must migrate funds to quantum-secure addresses or risk permanently losing access to those funds.
As a community of stakeholders that strongly believes in the values of immutability and property rights at all costs, Bitcoiners are grappling with whether the unprecedented threat of quantum computing necessitates equally unprecedented measures that may contradict core community values.
🗞️Other News
Jurvis Tan, a software engineer at Block, and Jesse Posner, co-founder of Vora, a Bitcoin self-custody platform, unveil a new approach to collaborative custody called “chain code delegation” that aims to improve privacy, security, and access control of bitcoin managed by multiple parties. (Delving Bitcoin)
The RGB team, which has been developing a smart contract protocol on top of Bitcoin and the Lightning Network, announces the final production-ready version of their software. (Delving Bitcoin)
A community member is giving away excess testnet coins on Bitcoin Testnet 3 to interested developers and network stakeholders. (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.
🌟 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 with me and other fellow readers. The invite link to join is posted in my Substack subscriber chatroom:
Newsletter credits:
Special thanks to Shinhye Kim for the graphics in this newsletter.
