Issue 14: October 22, 2025

2 new merged PRs in Bitcoin Core, pushback on limiting ScriptPubkey size, and a status update on the great consensus cleanup

Oct 22, 2025

Good morning,

I have lots of updates on Bitcoin Core development to share with you in this newsletter.

Two new code changes were recently finalized in the Bitcoin Core codebase. Also, there is growing agreement among developers to delay changes to scriptPubKey size, possibly due to other proposals like Bitcoin Improvement Proposal (BIP) 54. BIP 54 seeks to address similar issues as the proposal to limit the use of scriptPubKey and is notably further along in the Bitcoin governance process.

Below is my full summary and takeaways on the state of Bitcoin development, including the minutes from the Bitcoin Core developers meeting held last Thursday, October 16, 2025.

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, 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  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: 1
Milestone progress: 11%

Previous week’s snapshot showed 6 open issues, 1 closed, and a milestone progress of 14%.

Meeting Minutes

(Quotes featured in this section and the next may be edited slightly for grammar and clarity. For more information on the people quoted in this section, 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 “TheCharlatan” is still seeking further review of PR #30595 (kernel: Introduce C header API).

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 developer “sipa” said PR #33157 (cluster mempool: control/optimize TxGraph memory usage) was merged.
Sipa said he is now focusing his attention on PR #33629 (cluster mempool), a rebased and revised version of an older PR, PR #28676 (cluster mempool implementation).
Sipa also said he will be pushing a new updated version of PR #32545 (Replace cluster linearization algorithm with SFL).
Given the progress on this initiative, Sipa recommended updating Bitcoin Improvement Proposal (BIP) 125 (Opt-in Full Replace-by-Fee Signaling) to reflect the new changes to the Bitcoin mempool.

MuSig2 WG: An initiative to modernize the cryptographic scheme that combines multiple signatures authorizing a Bitcoin transaction into a single, compact signature.

Bitcoin Core maintainer Achow101 said PR #29675 (wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys) was merged. With that, Achow101 said, “I think this working group is done :D.”

🗒️Meeting Highlights

Discussion: During last Thursday’s meeting, Bitcoin Core developers celebrated two new merged pull requests (PRs). Hooray!

As background, merging refers to incorporating code changes detailed in a PR into the main branch or version of a codebase. Bitcoin Core developers bundle changes made to the main branch of their software into formal releases roughly every six months. These releases are then announced to end-users, who can choose to download and run the updated software on their computers to connect to the Bitcoin blockchain.

Let’s dive into the newest features merged into Bitcoin Core, which should be included for the next major Bitcoin Core release, v31.

The first is PR #33157 (cluster mempool: control/optimize TxGraph memory usage). This PR is one of a long list of PRs that seek to introduce new polices and logic for Bitcoin nodes when handling unconfirmed transactions. Instead of treating each transaction individually, nodes will be able to group dependent transactions into “clusters” and perform cluster-level operations on these transactions. These operations include relaying them to other nodes as a package of dependent transactions and reasoning about their aggregate fee and size.

PR #33157 specifically adds a few optimizations to the data structure, also called the “TxGraph,” that tracks transaction dependencies. The PR states:

This [PR] adds a few optimizations to reduce TxGraph‘s memory usage, and makes sure that dynamic memory it uses doesn’t linger after shrinking clusters. Finally, it exposes a function GetMainMemoryUsage() to compute TxGraph‘s approximate memory usage.

In non-technical terms, the PR introduces various optimizations to help nodes reduce memory usage and more accurately measure resources used for handling clusters of transactions.

The second merged PR, PR #29675 (wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys), is the final PR to be merged as part of the MuSig2 working group (WG) project.

This change gives Bitcoin Core’s wallet the ability to recognize, receive, and spend coins that use MuSig2, an advanced type of multisignature scheme.

Normally, when multiple people jointly control a Bitcoin address (for example, a company or a shared custody setup), their multisig transactions are large and easy to identify on-chain. They show that multiple signatures were used to sign off on the transaction.

MuSig2 is a modern cryptographic upgrade that lets multiple participants combine their individual keys and signatures into one single, compact signature. This makes their joint transaction look identical to a normal single-user transaction, improving both privacy and efficiency.

Takeaway: Compared to the rapid “headliner” feature rollouts happening on Ethereum, the two PRs merged into Bitcoin Core last week might not look especially exciting. They’re quiet, incremental upgrades — the kind of improvements most end-users will likely not even notice. But they’re also the product of years of steady work. The Cluster Mempool project began in 2023 and remains ongoing, while the MuSig2 wallet integration (PR #29675) dates back to early 2024.

For developers used to Ethereum’s tempo, where major EIPs can move from proposal to testnet in a matter of months, Bitcoin’s slower rhythm can seem almost glacial. Yet that pace is intentional: progress in Bitcoin is measured not by how quickly code ships, but by how confidently it can endure.

Bitcoin’s development culture treats code as infrastructure that must survive decades; Ethereum’s development culture treats code as experimentation that evolves through live iteration.

You’ve Got Mail! (& Other News)

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

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.

📧 Email Thread #1

Subject line: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus

Date(s): October 2 - October 20, 2025

Discussion: There is growing discussion on the proposal to introduce a consensus change to Bitcoin that restricts the scriptPubKey size to 520 bytes.

For context on this proposal, refer to BTC Before Light Issue #12:

BTC Before Light

Issue 12: October 8, 2025

Christine D. Kim

Oct 8

Good morning,

Read full story

In short, a scriptPubKey or “script public key” is the part of a Bitcoin transaction output that defines the conditions under which that output can be spent. It is designed to enable limited programmability on Bitcoin, allowing users to create simple rules for spending BTC on-chain. It is nowhere near as flexible as the smart contract rules users can code on Ethereum.

Earlier this month, Bitcoin contributor “PortlandHODL” proposed a soft fork, or backwards-compatible network-wide upgrade, that would invalidate transactions with outputs greater than 520 bytes in the ScriptPubkey, as these types of transactions are extremely rare and an outright ban would ensure no malicious actors can use such transactions to overwhelm the network in a denial-of-service (DoS) attack.

The initial response to the idea was largely positive. However, more recently, there has been opposition to the proposal.

Lightning Labs Engineer Keagan McClelland responded in the email thread:

Hard [negative acknowledgement] on capping the witness size as that would effectively ban large scripts even in the P2SH wrapper, which undermines Bitcoin’s ability to be an effectively programmable money.

Casey Rodarmor, the creator of Bitcoin inscriptions and ordinals, wrote:

I think that “Bitcoin could need it in the future?” might be a good enough
reason not to do this.

As next steps, PortlandHODL said that he would follow up with individuals in the thread for further discussion and write an implementation for his proposal for review.

Former Bitcoin Core Developer Greg Maxwell stressed that PortlandHODL’s proposal may introduce “a very real confiscation risk,” meaning it could accidentally make some existing, legitimate coins unspendable. Thus, he recommended amending the limit to only apply to newer Bitcoin transactions, or simply not enforce this limit at all. Maxwell wrote:

Some of the confiscatory concerns could be greatly mitigated … if the rule was only applied to transactions which either have no post-activation active nLocktime or have at least one input with a post activation height. … I’d generally say I still think the proposal has little value relative to the inherent costs of any consensus rule change and potentially has an unacceptable confiscation risk.

Takeaway: Consensus within the Bitcoin developer community is now leaning toward deferring any scriptPubKey-size limit. That said, there are other proposals, like BIP 54, that are further along in the Bitcoin governance process and also seek to mitigate DoS vulnerabilities in Bitcoin.

📧 Email Thread #2

Subject line: BIP54 implementation and test vectors

Date(s): October 21, 2025

Discussion: Antoine Poinsot, a Bitcoin Core developer at Chaincode Labs, shared an update on his ongoing “consensus cleanup” work, which is formalized as BIP 54.

BIP 54 introduces several consensus-level safeguards for making the protocol’s transaction validation rules more predictable and resistant to denial-of-service (DoS) attacks.

Poinsot announced he has opened a PR to implement the latest version of BIP 54 in Bitcoin Inquisition v29.1, a testbed version of Bitcoin Core. The latest version features a detailed set of test vectors and dedicated test suites for the four main features of the proposal.

The four main features or “proposed mitigations,” as Poinsot writes, of BIP 54 are:

Limit on Signature Operations (“sigops”) per transaction
- Every transaction can contain operations that check digital signatures (CHECKSIG, CHECKMULTISIG, etc.). Some edge cases let a malicious block pack thousands of these checks into a few transactions, forcing full nodes to spend seconds verifying them. BIP-54 adds a clear cap on how many signature checks are allowed per transaction.
- Result: Worst-case block validation time becomes predictable, and nodes can’t be stalled by computation-heavy signature operations.

Witness-stripped transaction size limit
- SegWit separates a transaction’s signatures (the “witness”) from its main body, which includes data on transaction inputs and outputs. Attackers may make transactions that have a disproportionately large body and a tiny witness. This imbalance can cause excessive bandwidth consumption in nodes, making blocks slower to relay. BIP-54 introduces a limit on the base size of a transaction after signatures are removed.
- Result: The limit aims to keep transactions proportionate, ensuring that all transactions have transaction input and output data of a reasonable size to witness data.

Timestamp sanity checks
- Bitcoin blocks include timestamps that affect difficulty adjustments (how mining difficulty changes every two weeks). BIP-54 defines tighter rules on allowable timestamps, so that no miner can manipulate block times to slow down or speed up difficulty changes beyond intended limits.
- Result: This ensures the blockchain’s “sense of time” stays consistent, preventing subtle bugs or timing tricks that could destabilize mining difficulty.

Coinbase maturity / timelock enforcement
- The “coinbase” transaction in each block (which creates new bitcoins) must wait 100 blocks before being spendable. There are subtle timing and ordering issues related to this rule that allow blocks bypassing it to be valid. BIP-54 explicitly enforces timelock rules for coinbase outputs to prevent such inconsistencies and clarify how blocks are validated.
- Result: The rule makes sure those new coins can only move after the waiting period in a way that’s verifiable by all nodes in the same way.

Poinsot invited feedback on the working implementation of BIP 54, particularly from developers working on alternative Bitcoin implementations, such as Bitcoin Knots, to verify that the code changes in the BIP align across different codebases, not just Bitcoin Core. Poinsot wrote:

I’m seeking feedback on these test vectors from everybody, but in particular developers of alternative Bitcoin clients, as compatibility with other Bitcoin implementations than Bitcoin Core was a design goal.

Takeaway: BIP 54 is a proposal that addresses issues in Bitcoin’s consensus rules dating back to the original version released in 2009 and has been in the works by Bitcoin Core developers since as early as 2019.

BIP 54 is currently in the implementation-and-testing phase, now with full test vectors covering every proposed mitigation. It is closer than ever to mainnet activation, though the final steps for review and activation are usually the most drawn-out and difficult to advance through in the Bitcoin governance process.

🗞️Other News

A demo version of Peer Observer, a monitoring tool for the Bitcoin networking layer, is now available to the public. The website, created by Bitcoin Core developer “0xB10C” and sponsored by LocalHost Research, features real-time visualizations of node peering activity on Bitcoin. (Demo.Peer.Observer)
Francesco Madonna, CEO of BitVault, presents Bitcoin Secure Signing Layer (B-SSL), a new design for self-custody of BTC that eliminates permanent key-loss risk and uses only existing protocol primitives like Taproot. (Delving Bitcoin)
Lightning developers share early results from simulations testing the effects of a new reputation algorithm meant to stop channel-jamming attacks without penalizing honest nodes. (Delving Bitcoin)
“Floppy,” a pseudonymous Bitcoin contributor, shares preliminary analysis on how diverging mempool policies in nodes are impacting their ability to efficiently reconstruct blocks. Spoiler alert: The impact is not major. (Floppy’s Substack)

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