Issue 08: September 10, 2025

Bitcoin v30.0rc1, BIP 119 Workshop #1, and stealth BGP interception attacks

Sep 10, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from three working groups: MuSig2, Script Validation, and Kernel. They also discussed progress on the v30 release, for which developers created a standalone release candidate (RC) yesterday. More details on the significance of the RC below.

Additionally, on the Bitcoin Developers Mailing List, the meeting log for a new workshop series on OP_CHECKTEMPLATEVERIFY (OP_CTV) was shared. There was also a discussion on Delving Bitcoin about a new type of attack on Bitcoin nodes that could happen in stealth and disrupt node connectivity.

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

Release Date: September 5, 2025

Upcoming Major Release: Bitcoin Core 30.0

Target Release Date: Early October 2025
Open issues: 6
Closed issues: 93
Milestone progress: 93%

(Previous week’s snapshot showed 14 open issues, 71 closed, and a milestone progress of 83%.)

Meeting Minutes

Editor’s note: Some quotes featured in this section and the next have been edited slightly for grammar and clarity.

🗒️Bitcoin v30.0rc1 is out

Discussion: On Tuesday, September 9, Bitcoin Core developers created the first release candidate for the next major Bitcoin Core release, v30.

With the release candidate (RC) for Bitcoin Core v30 now out, the code for v30 will enter a final testing phase lasting roughly a month. The broader Bitcoin community is encouraged to help test v30 by running the RC in staging environments and on Bitcoin testnets.

Bitcoin Core developer “achow101” said during Thursday’s meeting:

Please review the things in the [v30] milestone.

Bitcoin Core developer “janb84” offered to work on the testing guide for the RC, which outlines the features of the v30 release and provides steps for outside contributors to help test them.

Bitcoin Core developer “stickies-v” said to janb84:

Thanks for taking on the testing guide again!

If there are no critical issues discovered over the next few weeks, developers will proceed to cut the final release for v30 sometime in early October.

Takeaway: The RC is the final stress test in the Bitcoin Core software release cycle. It opens up testing of release features to the broader Bitcoin community and signals to the community that developers are near-ready to publish the release as final, feature-complete, and safe for all node operators to upgrade their machines to.

Barring any unexpected bugs, the v30 release is expected to land next month. As the final countdown to the v30 release begins, tensions in the Bitcoin community are rising over the default feature that uncaps the OP_RETURN data carrier size. Over the weekend, proponents of Bitcoin Core went head-to-head with proponents of an alternative implementation to Core, called Knots, debating the rationale for changes in v30.

For background on the OP_RETURN debate, read this BTC Before Light issue on the rise of Knots.

🗒️Other Topics

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) is currently under review.

Script Validation WG: This group is focused on improving the performance, security, and flexibility of Bitcoin’s script execution and signature validation system.

The focus is on shipping PR #1134 (add support for batch verifying Schnorr signatures and tweaked x-only public key checks) in the Bitcoin Core secp256k1 Github repository.

Kernel WG: This group is working on modularizing the Bitcoin Core implementation by cleanly separating consensus-critical logic from non-consensus-critical components.

Recent changes have been made to PR #30595 (kernel: Introduce initial C header API), reworking the PR’s approach to data ownership.

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 Bitcoin discussion forums:

📧 Mailing List Thread

Subject line: IRC logs, BIP 119 Workshop

Date(s): September 5, 2025

Discussion: On Thursday, September 4, a developer by the pseudonym “bytes1440000” hosted a public workshop on Bitcoin Improvement Proposal (BIP) 119.

As background, BIP 119 is a proposal for the creation of a new operation, also called an opcode, that will enable users to enforce spending conditions on their coins in such a way that coins can only be spent to a pre-specified address or amount.

Bytes1440000 explained during the workshop:

BIP 119 or CTV is a proposed soft fork which would allow the users to restrict UTXOs in a way that they can only be spent to committed address, amount etc.

They went on to highlight how the opcode, OP_CHECKTEMPLATEVERIFY (OP_CTV), works and the use cases motivating its design.

One workshop participant, by the pseudonym “monlovesmango” asked:

Is it fair to say all functionality enabled by presigned txs is also enabled by ctv?

Bytes1440000 responded saying that OP_CTV does indeed enable the same functionality as pre-signed transactions on Bitcoin, but through a better user experience and improved security.

Bitcoin Core developer “kevkevin” asked:

Is there any opinion on OP_TEMPLATEHASH? It seems to be similar/inspired by OP_CTV, but restricted to tapscript. … Bytes1440000, are there reasons for not wanting it to be only restricted to taproot? I think the rationale for restriction is to reduce the surface area by leaving legacy scripts alone.

For background on the OP_TEMPLATEHASH proposal, read this BTC Before Light issue.

Bytes1440000 responded:

I think we should allow covenants in all scripts and let users decide.

The meeting ended with Bytes1440000 sharing additional resources for workshop participants to learn more about OP_CTV.

Takeaway: Of the BIPs that are actively under discussion and review by the Bitcoin development community, BIP 119 is one of the longest running and most widely supported. Though the pathway for activation remains unclear, especially since the Bitcoin Core developer community put forth a competing proposal to OP_CTV, efforts to raise awareness and support for the soft fork have not abated. Community members like Bytes1440000 are continuing to drive OP_CTV discussions forward.

🖥️ Delving Bitcoin Thread

Subject line: Eclipsing Bitcoin Nodes with BGP Interception Attacks

Date(s): September 4 - September 6, 2025

Discussion: On Thursday, September 4, a user by the pseudonym “Cedarctic” posted a study on a new type of BGP interception attack on Bitcoin nodes. BGP stands for “Border Gateway Protocol,” which is the routing system that network operators like AT&T, Verizon, and others use to route internet traffic.

Cedarctic explains that because BGP lacks requirements for user authentication, attackers can sometimes trick the system into rerouting certain traffic. The ultimate goal of the attack described in their study is to intercept the communications of a Bitcoin node with its peers. They wrote:

The goal of the attacker is to control all incoming and outgoing connections to a node. This allows the attacker to waste mining power, do selfish mining, double-spend, attack Lightning, etc.

Cedarctic goes on in the post to describe the attack’s feasibility, a proof-of-concept experiment producing the attack, and potential mitigations for it.

In general, BGP interception attacks are not a new type of risk to Bitcoin nodes. However, the particular version of these attacks that Cedarctic describes is stealthy and difficult to detect on a network level.

Responses to Cedarctic’s study focused on best practices to identify these attacks.

Bitcoin Core developer “0xB10C” asked:

I was wondering if you have a suggestion of how an attack like this can be detected through monitoring and what metrics would be useful to keep track of. I run a couple of “honeypot“ monitoring nodes as part of my peer-observer: A tool and infrastructure for monitoring the Bitcoin P2P network for attacks and anomalies, and while I don’t suspect they’ll be attacked with a BGP attack, it could be useful to use some Bitcoin Core external monitoring tool.

Former Bitcoin Core developer “gmaxwell” wrote:

“If/when countersign is ever implement[ed into Bitcoin Core] such attacks should be readily detectable from even a small number of nodes using authentication, particularly because the attacker wouldn’t be able to simply distinguish auth[entication] using and auth-not-using connections in order to successfully avoid MITM the authenticated ones. Absent that, if you do know some of your peers, you can manually compare session IDs today.”

Takeaway: The most concerning types of network attacks on Bitcoin are the ones that are difficult to detect. Studies like the ones shared by Cedarctic highlight a continued need for work on hardening the Bitcoin protocol and securing it against potential adversaries, such as the ones that could fly under the radar and hijack the connectivity of Bitcoin nodes.

🗞️Other News

Bitcoin Knots developer Luke Dash Jr. announces a new minor release version of Knots, v29.1.knots20250903. (Bitcoin Development Mailing List)
Christopher Allen, Founder of Blockchain Commons, announces new demos of FROST, an off-chain threshold-signature protocol that gives multisig-level security to Bitcoin transactions with single-signature fees and privacy guarantees. (Bitcoin Development Mailing List)
Blockstream engineer Russell O’Connor publishes Part 3 of his series explaining Simplicity—a smart contract language designed for Bitcoin-like blockchains that recently launched on the Liquid sidechain. (Delving Bitcoin)
Blockstream developer Jonas Nick shares a workbook for hosting interactive workshops on Bitcoin cryptography. This workbook contains definitions, propositions, lemmas, theorems, and exercises, along with a complete “solution book.” (Delving Bitcoin)
A discussion thread about how to best encrypt Bitcoin Core wallets for added security and privacy. (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.