Issue 17: November 12, 2025

Versioning schemes for the Kernel C-header API, updates to Dathan Ohm's soft fork proposal, and BIP-3

Nov 12, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from the following working groups: Kernel, Benchmarking, Cluster Mempool, Silent Payments, and Stratum V2.

They also discussed a few housekeeping items regarding dormant working groups and five miscellaneous pull requests (PRs) ready for merge.

In today’s newsletter, I discuss the updated Bitcoin Improvement Proposal (BIP) process as defined by BIP-3. BIP Editor “Murch” recently proposed the formal adoption of BIP-3 as a replacement for BIP-2.

Though the changes from BIP-2 to BIP-3 are not that significant, the stewardship of the new BIP process will look markedly different from before. I explain why below.

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: 8
Closed issues: 4
Milestone progress: 33%

The previous week’s snapshot showed 6 open issues, 4 closed, and a milestone progress of 40%.

🗒️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.

Bitcoin Core developer “The Charlatan” raised questions about how to surface documentation and where to host bindings for the newly finalized C-header API. Bindings are the adapters that allow code written in languages other than C to interact with the API.
- Bitcoin Core developer “Laanwj” suggested creating a Github repository for API-related bindings under bitcoin-core.
- Bitcoin Core developer “stickies-v” emphasized the importance of documenting how to implement language bindings to encourage engagement with the API.
- The Charlatan said people have reached out to him about hosting bindings under their own respective organization’s Github projects.
The Charlatan also asked about the API’s versioning scheme.
- Bitcoin Core developer Abubakar Sadiq recommended opening an issue for feedback on this from the broader Bitcoin development community.
The Charlatan raised the need for more testing on the API and test vectors for the bindings.
A pseudonymous developer named “purpleKarrot” said developers should discuss the naming convention for API functions, as all function names are lowercase, and it is difficult to distinguish data types from API method names.
- Laanwj warned that a discussion about naming conventions may detract from the project’s momentum, but suggested creating a GitHub issue to discuss it further, nonetheless.
- The Charlatan asked PurpleKarrot to formalize his suggestions for naming changes into a pull request (PR).
The Charlatan said his working group is focused on a beta release of Rust bindings for the API. They have also started a repository of fuzz tests, which are basically stress tests with randomized inputs.

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 PR #31132 (fetch block inputs on parallel threads >20% faster IBD) has resulted in 30% faster “reindex-chainstate” speeds in certain nodes.
They also said they are investigating potential memory leaks in code, as described in PR #33806 (malloc: Failed to allocate segment from range group - out of space).
Finally, the Benchmarking WG is writing an article for Bitcoin Magazine about their work.

Silent Payments WG: Implementation of BIP 352, a way to improve on-chain privacy by enabling users to create a single reusable address that can automatically generate one-time addresses for incoming payments that only the recipient can identify.

Developers in this working group are focused on the following four PRs:
- PR #1765 (Add “silentpayments” module implementing BIP352 to the cryptography library, “libsecp256k1,” maintained by Bitcoin Core)
- PR #28122 (Silent Payments: implement BIP352)
- PR #28201 (Silent Payments: sending)
- PR #32966 (Silent Payments: receiving)

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 maintainer “Glozow” said reviews on PR #33629 (cluster mempool) are still needed. The group plans on doing a review “sprint” for the PR this week. Glozow has created a list of items to review about the PR.

Stratum V2 WG: An initiative to modularize and refactor Bitcoin Core components to support a next-generation mining protocol known as Stratum V2.

Sadiq said there is a new tracking issue for the initiative.
PR #33676 (interfaces: enable cancelling running waitNext calls) has been merged.
PR #33745 (mining: check witness commitment in submitBlock) is ready for review.

Dormant WGs

Stickies-v proposed removing the Erlay and Multiprocess WGs from the meeting agendas moving forward, as there have not been updates from these groups lately.

Miscellaneous PRs:

L0rinc said the following five PRs are ready for merge:
- PR #30442 (precalculate SipHash constant salt XORs). This PR remains open at the time of writing.
- PR #33042 (refactor: inline constant return values from dbwrapper write methods). This PR has since been merged.
- PR #33443 (log: reduce excessive “rolling back/forward” messages during block replay). This PR has since been merged.
- PR #33768 (refactor: remove dead branches in SingletonClusterImpl). This PR has since been merged.
- PR #33786 (script: remove dead code in CountWitnessSigOps). This PR has since been merged.

Meeting Highlights

Discussion: An important topic raised at last Thursday’s Bitcoin Core developers meeting was the versioning of the Bitcoin kernel C-header API.

For background on the C-header API, refer to last week’s newsletter or this Ready for Merge podcast episode.

As the first major feature for users to build software that relates exclusively to the consensus rules of Bitcoin, and not to other aspects of the protocol as defined by the Bitcoin Core client, there is a question about how the API should be versioned.

The Charlatan said:

A suggestion was to treat our internal version as a “product name” and then have a specific versioning scheme for the header.

This would separate the development of the kernel itself, which defines protocol consensus rules, from the public interface that exposes the kernel to the public.

Both are developed and maintained by Bitcoin Core developers, but could be versioned separately so that any optimizations or changes to the public API unrelated to consensus changes can be differentiated.

The Charlatan said that this approach may be confusing for users.

This versioning approach seemed a bit confusing to some, and would still practically tie Bitcoin Core versioning with the kernel library. Maybe, for now, the best action is to just not bother with it for a while still.

Laanwj acknowledged the complications of separating kernel versioning from API versioning and agreed that the entire project is still “experimental,” and setting a versioning scheme for either may be premature.

Developers agreed to continue discussing the matter in an issue on Github.

Takeaway: The kernel API’s release is a milestone in Bitcoin Core’s modularization, but the discussion about its versioning highlights how experimental the kernel project remains. Consensus code is still deeply intertwined with the Bitcoin Core client. Developers are cautious about how changes to Bitcoin’s consensus may affect the C-header API, and vice versa. For now, the focus is on testing, documenting, and gathering user feedback on the API, which may inform how developers should eventually delineate kernel development from the rest of Bitcoin Core’s work.

📧 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 core discussions that happened this past week from the Bitcoin Development Mailing List and other Bitcoin discussion forums:

There is a new draft for a temporary soft fork to limit arbitrary data storage on Bitcoin. It still appears to have major issues, including the risk of fund confiscation. For background on the initial draft, refer to this prior newsletter. (Bitcoin Development Mailing List)
MergeSync is a proposal to accelerate node syncing speeds using an “assumevalid” trust model and parallel processing. (Delving Bitcoin)
P2share is a proposal for a distributed Bitcoin mining pool with transferable rewards without any protocol-level changes needed to Bitcoin. (Delving Bitcoin)
“Julian” demonstrates how a variable operations (varops) budget can allow developers to safely re-introduce previously deprecated opcodes considered to have denial of service risks. (Delving Bitcoin)
Voting is officially open for your favorite submission in the Bitcoin Talk Pumpkin Carving competition. Voting closes next Tuesday, November 18! (Bitcoin Talk)

Discussion Spotlight

Subject line: Motion to Activate BIP 3

Date(s): November 4, 2025

Discussion: Last Tuesday, “Murch,” who is one of the six Bitcoin Improvement Proposal (BIP) editors, proposed activating BIP-3, an updated document detailing the BIP process.

For a detailed overview of the BIP process, refer to this Toolkit post. BIP-3 introduces minor changes to the BIP process, including but not limited to:

Reducing the judgment calls assigned to the BIP Editor role, such that editors can only make changes to BIP formatting and metadata, not BIP content.
Delineates the BIP types more clearly into Specification, Informational, and Process BIPs.
Generalizes the BIP process to fit the community’s use of the repository. For example, the BIPs repository will no longer track “Other Implementations” lists as these frequently become stale. Also, the comment feature for BIPs has been removed as it saw little adoption.

BIP editor Ruben Somsen replied to Murch, supporting the changes to the BIP process included in BIP-3.

Murch, you did an excellent job writing this and taking everyone’s feedback into account. I think it’s a crystal clear step up and should be adopted.

Takeaway: The changes from BIP-3 to BIP-2 are mainly for clarification. They clarify the various stages of the BIP process, the BIP types, and the roles of stakeholders.

It does not deviate in material ways from the spirit of BIP-2, which was authored by BIP editor Luke Dash Jr and formally adopted in 2016 as the new BIP process document.

The most impactful change to the BIP process occurred last year, when the Bitcoin community appointed five new BIP editors. Prior to this, there was only one, Dash Jr.

Should BIP-3 be formally adopted, many of its rules will be carried out by the editors themselves. BIP-3 will be the first BIP process document to rely on the stewardship of a team of BIP editors rather than a single one.

Now, that’s what I call progress in decentralized governance.

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