Issue 01: July 23, 2025
NAT hole punching, the perceived threat of quantum computers, and the open-sourcing of Augur
Good morning,
Last Thursday, Bitcoin Core developers discussed updates from three different working groups: Erlay, QML GUI, and Orphan Resolution.
Also, on the Bitcoin Development Mailing List, there has been more discussion on Jameson Lopp’s quantum migration proposal. While the details of the exact migration strategy remain unclear, consensus is forming on the need for a strategy, at the very least.
Below is my write-up on the Bitcoin Core developers meeting that took place on Thursday, July 17, 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: 12
Closed issues: 35
Milestone progress: 74% of issues are resolved
(Previous week’s snapshot showed 10 open issues, 32 closed, and a milestone progress of 76%.)
Meeting Minutes
Editor’s note: Some quotes featured in this section and the next have been edited slightly for grammar and clarity.
🗒️Enabling NAT hole punching by default
Discussion: After the usual working group updates, Antoine Poinsot (“darosior”), a Bitcoin Core developer sponsored by Chaincode Labs, raised the topic of enabling a new feature in the next major Bitcoin Core release, v30.0.
Poinsot said:
Very early on, Bitcoin Core started shipping with NAT hole punching enabled by default with UPnP. This was disabled in 2015 following a discovery of an RCE in miniupnpc … Because NAT hole punching is not really useful unless enabled by default, and because I think our implementation is now vetted enough, I propose that we enable it by default in 30.0.
Network Address Translation (NAT) is a process that enables multiple devices to share one public IP (Internet Protocol) address. It’s how most home internet setups protect and hide individual IP addresses.
This can be a problem, however, if a user is trying to run a public Bitcoin node that other nodes can identify and connect to.
NAT hole punching is a process that allows a user’s Bitcoin node to be publicly reachable without requiring manual configuration of the user’s home router.
In the past, Bitcoin Core supported NAT hole punching using a protocol called Universal Plug and Play (UPnP). However, due to security concerns, this functionality was disabled by default.
Now, Poinsot points out that there are alternative well-tested protocols, such as PCP and NAT-PMP, that can safely be enabled by default. This would allow more home Bitcoin node operators to become automatically reachable by other nodes in the Bitcoin network, thereby improving network decentralization and resilience.
Bitcoin Core developer Mara van der Laan (“laanwj”) said:
It's very possible to delay this by another version, if there's a good reason, but I think we have enough confidence in it now.
Poinsot agreed:
I think the benefits outweigh the risk now.
Developers agreed to open a pull request (PR) for this and continue the discussion on GitHub.
Takeaway: Bitcoin developers are considering re-enabling a powerful feature in the next major Bitcoin Core release, which will make more home-operated nodes public by default, thereby strengthening network decentralization.
🗒️The next minor Bitcoin Core release 29.1
Discussion: Bitcoin Core developer Michael Ford (“fanquake”) noted that it is time for developers to push a minor release to v29.0, now that it has been roughly three months since v29.0 was first published.
Ford mentioned several backports, which are fixes or features from the master branch of Bitcoin Core, that developers want to add to a previously released version of the software.
Ford said the following backports will go into the forthcoming v29.1 release:
Poinsot said he would like to see the following backport added:
PR #32521 (make pathological transactions packed with legacy sigops non-standard)
Developers agreed to review it for the v29.1 release.
Takeaway: Bitcoin Core developers aim to release a new major version of software every six months. In between the major version releases, they release a minor version midway through containing backports. Backports bring important changes from newer code into older versions—mainly bug fixes and security updates. This development cycle of Bitcoin Core ensures continual improvement and maintenance of the technology powering bitcoin, the world’s most valuable crypto asset.
🗒️Other Topics
Erlay WG: 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.
PR #30116 (Fill reconciliation sets attempt 2) newly opened to make it easier to track transaction propagation times.
QML GUI WG: An initiative to create a new modern graphical user interface (GUI) for Bitcoin Core using Qt Quick / QML (Qt Modeling Language).
As discussed last week, the QML GUI code is being rebased on the latest version of Bitcoin Core and worked on in a new development branch called “Qt6.”
Notably, this branch includes Bitcoin Core as a “git submodule,” rather than a forked version of Bitcoin Core, which should be a better organizational model for QML GUI development that prevents conflicts with new Bitcoin Core release versions.
The rebasing work is not complete. Next steps for the project are documented here.
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
Subject line: A Post Quantum Migration Proposal
Date(s): July 12 - July 20, 2025
Discussion: The discussion on Bitcoin’s migration to a quantum-resistant digital signature scheme has intensified over the past week.
For background on the proposed migration plan by Jameson Lopp, Co-founder and Chief Security Officer of Casa, read BTC Before Light Issue #00.
The latest emails in the thread about Lopp’s proposal discuss whether access to non-quantum-secure coins can be temporarily, rather than permanently, disabled, and whether taking any action on this matter is too hasty.
An independent Bitcoin developer, using the pseudonym “Conduition,” was supportive of the idea proposed by Boris Nagaev, an engineer at Lightning Labs, to temporarily lock access to vulnerable coins held in non-quantum-secure addresses whilst secure recovery mechanisms for these coins are researched.
However, Conduition asked if this idea should then be applied earlier in Lopp’s proposal, in “Phase A,” when transfers of bitcoin to non-quantum-secure addresses are prohibited and only transfers to quantum-secure addresses are allowed.
If we do that, should we apply the same logic to phase A though, and eventually permit sending to pre-quantum addresses at height X? Because as described, once phase A is locked in, we can never again permit sending to pre-quantum addresses (without a hard fork).
Nagaev responded on Wednesday, July 16, affirming this would be the case.
If the proposal gets traction, it is better to replace permanent blocking with temporary restrictions in case of both sending to and spending from vulnerable addresses. That way, we leave the door open for future recovery schemes without needing a hard fork.
Bitcoin Core developer Peter Todd then raised concerns that these changes to Bitcoin may be too hasty, saying that in his view, quantum computing remains a distant prospect.
For all the claims of progress on quantum computing hardware, the fact still remains that no one is even close to demonstrating cryptographic-relevant quantum computing capabilities and the actual cryptographic-relevant capabilities of real hardware are laughable.
Conduition replied to Todd, emphasizing that while the danger of quantum computing may be far off, the Bitcoin community needs a plan in place to react when the threat becomes real.
Marin Ivezic, founder of the AppliedQuantum research firm, also responded to Todd’s concerns, saying that the question of being too early to respond to the threat of quantum computing is “irrelevant,” as general public awareness and concern about the technology is growing rapidly.
The world is acting like CRQCs are coming, so we should act like it too. … Rightly or wrongly, users will soon expect to see some assurances or plans on how bitcoin will resist the quantum threat. And if our response is that a few on the list think [cryptographically-relevant quantum computers] are laughable, the confidence will take a big hit.
Lopp gave a talk about his proposal last Thursday at the Quantum Bitcoin Summit hosted by Presidio Bitcoin in San Francisco. He also drafted a formal Bitcoin Improvement Proposal (BIP) for deprecating elliptic curve digital signatures and migrating to quantum-secure signatures.
Discussion about the proposal has expanded beyond the Bitcoin Development Mailing List to other popular Bitcoin forums such as Delving Bitcoin and BitcoinTalk.
Takeaway: While discussions about how exactly to migrate to a quantum-secure signature scheme are ongoing, the Bitcoin community is becoming increasingly aligned on the need to have a concrete plan to address the threat of quantum computers in advance of that threat becoming real or imminent.
🗞️Other News
There is a new release version of “libsecp256k1,” v0.7.0. Libsecp256k1 is the cryptographic library used by Bitcoin Core to handle elliptic curve operations, which are the operations that enable Bitcoin’s digital signatures and public/private key system. (Bitcoin Development Mailing List)
Developers are discussing ways to extend relative timelocks, which are mechanisms that restrict the spending of coins for a predetermined period on-chain from roughly one year to ten. (Delving Bitcoin)
A denial-of-service vulnerability exists in an older version of the Lightning Network Daemon (LND) software, a popular client implementation of the Bitcoin Lightning Network. Users are strongly encouraged to upgrade to LND v0.18.3 or higher. (Delving Bitcoin)
Jack Dorsey’s financial service conglomerate, Block, has open-sourced Augur, a new mempool-based Bitcoin fee estimator. It is estimated to reduce overpayment of transaction fees by as much as 75% compared to other fee estimators. (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 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 and Ethereum with other fellow readers. The invite link to join is posted here:
Newsletter credits:
Special thanks to Shinhye Kim for the graphics in this newsletter.
