Issue 21: December 10, 2025

Bitcoin Core software release stages, "The Cat" proposal, and long-term considerations for the Great Consensus Cleanup

Dec 17, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from the Kernel, Benchmarking, Cluster, and Net Split working groups (WGs).

They also briefly discussed a proposal to remove the “End of Maintenance” (EOM) label from Bitcoin Core’s release status descriptions, noting that the designation is rarely used in practice and does not accurately reflect how Bitcoin Core releases are actually maintained.

Also in today’s issue: a discussion on how a leading soft fork proposal, BIP-54, could narrow the range of options available to developers for addressing a long-known protocol issue—the nTime overflow problem—which Bitcoin will need to resolve by the year 2106.

As 2025 comes to a close, I want to thank all of my BTC Before Light readers for subscribing and supporting my work covering Bitcoin protocol development. This will be the final issue of the year, but there is still much more to come from me in this series in 2026!

Yours truly,

Christine D. Kim

🔔Programming note: There will be no new BTC Before Light issues for the next two weeks. Publishing will resume on Wednesday, January 7. Happy holidays, everyone!

⏱️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: 13
Closed issues: 18
Milestone progress: 58%

The previous week’s issue showed 12 open issues, 17 closed, and a milestone progress of 58%.

🗒️Meeting Minutes

(Quotes featured in this section and the next may be edited slightly for grammar and clarity. For more information on the people involved in Bitcoin development, 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.

“stringintech” is working on the language binding test suite for the kernel C-header API.
“stickies-v” is working on separating node and kernel logging.

Benchmarking WG: Efforts to measure and improve the performance of Bitcoin Core software through benchmarking, that is, analyzing how long certain processes take.

PR #30442 (precalculate SipHash constant salt XORs) and PR #33602 ([IBD] coins: reduce lookups in dbcache layer propagation) have been merged.
“l0rinc” reported that PR #33657 (rest: allow reading partial block data from storage #33657) is under review. Since Thursday’s meeting, the PR has also been merged.
A prototype is available for SwiftSync, an experimental idea to speed up how a new Bitcoin node syncs with the network. Feedback on the prototype is welcome on PR #34004 (Implementation of SwiftSync).
L0rinc reported a few counterintuitive benchmarking test results where nodes ran out of memory despite having plenty of RAM. L0rinc discussed a few reasons for these results and said that investigations are still ongoing to determine the root cause.

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.

“sipa” has split out a section of PR #32545 (Replace cluster linearization algorithm with SFL) into its own separate PR for more granular review. The secondary PR, PR #34023 (Optimized SFL cluster linearization), is currently in draft mode.
PR #33335 (txgraph: randomize order of same-feerate distinct-cluster transactions) is ready for review.

Net Split WG: An initiative to separate Bitcoin’s networking layer from its peer-processing layer for improved networking upgradeability and testability. More information about this WG’s primary goals can be found in this meta PR.

Developers discussed competing approaches to introducing greater modularity to Bitcoin’s networking layer. One approach relies on shared memory to manage peer connections and process messages from these peers. Another relies on internal references to node data, rather than shared data, to more cleanly separate networking logic. Though cleaner, the latter may introduce a small performance cost. Developers agreed to continue discussing the trade-offs between these approaches and potentially schedule a dedicated breakout meeting on this topic.

Bitcoin Core Release Lifecycle Update: Removes the “End of Maintenance” status of Bitcoin Core releases and updates language on the Bitcoin Core website detailing the Bitcoin Core software release process.

Developers discussed PR #1200 (Update the release lifecycle page to reflect current practices). They largely agreed on the simplified language for the Bitcoin Core software release.

BIP-3: This Bitcoin Improvement Proposal (BIP) provides information about the preparation of BIPs and policies relating to the publication of BIPs. It replaces BIP 2 and introduces amendments that reflect the evolving needs of the BIP process.

“Murch” said that they recently submitted a patch to BIP-3 and requested review on the latest version of the proposal. This PR summarizes recent changes to BIP-3.

Meeting Highlights

Discussion: On Thursday, Bitcoin Core developers leaned toward finalizing a minor but clarifying update to the documentation describing the project’s software release process.

The Bitcoin Core website currently distinguishes between three release states, including an intermediate “End of Maintenance” (EOM) phase:

We maintain the major versions until their “Maintenance End”. We generally maintain the current and previous major releases. For example, if the current release is 23.0, then 22.0 is also considered maintained. Once 24.0 is released, then 22.0 would be considered at its “Maintenance End”.

As noted by Darosior in PR #1200, this EOM designation is not reflected in practice. In reality, the project only distinguishes between versions that are actively maintained and those that are no longer supported:

We only make a distinction between maintained and [End of Life] versions. The EOM status adds unnecessary complexity and is misleading, so remove it.

To align the documentation with actual development practice, Darosior proposed revised language that collapses the three-state model into two categories: maintained and end of life (EOL). The proposed text reads:

We always maintain the past three major versions released. Once a major version falls outside that window, it becomes “End of Life”. The threshold for backporting a change to a past major version increases as it ages. For example, if the last major release is 30.0, then 29.x and 28.x are also considered maintained. Once 31.0 is released, then 28.x becomes “End of Life”.

About the simplification in process, Bitcoin Core developers Murch and “fanquake” expressed their support for the changes.

Takeaway: Although minor, the updates discussed on Thursday to the software release process underscore an important characteristic of Bitcoin Core development: written process often lags behind actual practice. Consensus on release maintenance has already been formed through day-to-day and week-to-week development work, and now the documentation is catching up to formalize it. In Bitcoin, as well as Ethereum, process often affirms and codifies consensus, but rarely is it responsible for shaping and creating consensus.

📧 You’ve Got Mail! (& Other News)

(For a comprehensive overview of all major Bitcoin development meetings and discussion forums, refer to this post in the BTC Toolkit.)

An overview of other notable discussions and news that happened over the past two weeks, sourced from the Bitcoin Development Mailing List and other public forums:

BIP-54, consensus cleanup, may inadvertently preclude the possibility of a soft fork to handle Bitcoin’s timestamp overflow issue. Bitcoin block timestamps use a 32-bit counter, which will eventually overflow in the year 2106. Since a solution to this issue remains under discussion, Bitcoin developer Josh Doman asks whether BIP-54 should be updated to leave the possibility of a soft-fork solution open in the future. (Bitcoin Development Mailing List)
Mikhail Kudinov and Jonas Nick from Blockstream Research share analysis on post-quantum options for securing Bitcoin, focusing specifically on hash-based schemes. They highlight the benefits and drawbacks of hash-based post-quantum signatures and offer solutions to reduce signature size. (Bitcoin Development Mailing List)
“The Cat” is a proposed Bitcoin soft fork that would invalidate and drop dust-sized unspent transaction outputs (UTXOs)—primarily associated with Ordinals, Stamps, and similar data-embedding schemes—from the UTXO set. The proposal has been closed on Github due to its controversial nature, but conversation about this proposal is ongoing on Bitcoin Talk. (Bitcoin Talk)

Discussion Spotlight

Subject line: Does GCC preclude a soft fork to handle timestamp overflow?

Date(s): December 14 - December 15, 2025

Discussion: On Sunday, Doman raised a concern about BIP-54, a leading soft fork proposal that has recently been activated on the Bitcoin Inquisition testnet.

As background, BIP-54—often referred to as part of the “Great Consensus Cleanup”—is a bundle of changes aimed at tightening long-standing edge cases in Bitcoin’s consensus rules that date back to the protocol’s launch in 2009.

One of the issues BIP-54 addresses is the timewarp attack, a scenario in which a majority of miners can manipulate block timestamps to artificially lower mining difficulty. BIP-54 mitigates this risk by constraining how far back in time miners are allowed to set block timestamps, preventing timestamp manipulation from affecting difficulty adjustments.

Doman’s concern is that the specific way BIP-54 fixes the timewarp attack may unintentionally limit future options for addressing another, much longer-term issue: the nTime overflow problem.

The nTime overflow problem stems from the fact that Bitcoin block timestamps use a 32-bit counter, which is expected to overflow in the year 2106. Before then, developers will need to transition to a larger timestamp representation—either by expanding the existing counter (e.g., to 64 bits) or by introducing an additional field that allows blocks to be timestamped safely beyond year 2106.

Doman notes that while the simplest solution to the nTime overflow would be a hard fork that changes the timestamp representation directly, there is also a potential soft fork approach that could introduce a larger counter alongside the existing 32-bit field. However, he argues that BIP-54’s current approach to fixing the timewarp attack may eliminate this soft-fork optionality altogether.

In this Delving Bitcoin post, Doman asked:

Generally speaking, we should always avoid a hard fork, if we can. We don’t need to decide now, but if we can modify BIP54 at little cost so that a soft fork remains in the cards, shouldn’t we?

This question sparked broader discussion about how Bitcoin developers expect to handle the nTime overflow and whether that future problem should materially influence the design of BIP-54 today.

Several developers pushed back on the idea of using a soft-fork to address the nTime overflow problem. Responding to Doman through the Bitcoin Development Mailing List, Blockstream engineer Russell O’Connor said:

Any soft-fork mechanism that messes with [Median Time Past] will destroy existing transactions’ timelock semantics. Now, I think [it’s] best is to have a hardfork.

Bitcoin Core developer AJ Towns echoed this view, describing a hard-fork solution as an easy solution:

The “obvious” fix to the nTime overflow issue is to calculate a 64 bit nTime64 from the 32 bit nTime … That’s a hard fork (but only compared to the chain stopping entirely), and means that a 64 bit replacement for timestamp-based nLockTime would be needed for that feature to still be usable, but otherwise seems pretty straightforward and non-intrusive.

In response, Doman emphasized that current preferences should not be assumed to reflect future consensus, arguing that developers decades from now may weigh tradeoffs differently:

I think it’s presumptive to assume which option a future generation would prefer, in the year 2070, 2080, 2090, 2100, etc, given the tradeoffs involved. I’m not suggesting we decide today, but I am suggesting that BIP54 may be unnecessarily restrictive.

Takeaway: Alongside post-quantum signatures, the nTime overflow fix is one of Bitcoin’s unavoidable future protocol upgrades. For both upgrades, developers are presented with both hard-fork and soft-fork design paths. Further, because these upgrades are still years away, there is little time pressure to settle on a specific design path today, which is why no clear consensus has formed for either upgrade yet.

(As an aside, efforts to accelerate agreement around post-quantum signature migration are growing in the Bitcoin community.)

Doman’s question highlights how development decisions made today can meaningfully shape Bitcoin’s upgrade options decades into the future. Seemingly narrow consensus changes can quietly constrain—or preserve—the set of tools available to future developers when addressing long-horizon protocol risks. Framing these tradeoffs early helps ensure that future upgrades are the result of deliberate design choices, rather than reactive fixes forced by past decisions.

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

Discussion about this post

Ready for more?