Issue 15: October 29, 2025
New soft fork proposal to limit arbitrary data on Bitcoin, 4 security disclosures following the v30 release, and the beta release of Bisq Easy v0.1.1
Good morning,
I’m back with your weekly update on the state of Bitcoin Core development.
Last week, there was no Bitcoin Core developers meeting. I’m not sure why the meeting was skipped, but I am trying to find out.
Even without a formal meeting, there was a lot of discussion happening in the Bitcoin development community over the past week. This was primarily due to a new soft fork proposal by Bitcoin contributor Dathon Ohm.
Below, I give the full context for the proposal and how this impacts Bitcoin holders.
I also share takeaways on the latest round of security vulnerability disclosures made by Core developers in the aftermath of their v30 major release.
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: 9
Closed issues: 1
Milestone progress: 10%
The previous week’s snapshot showed 8 open issues, 1 closed, and a milestone progress of 11%.
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.)
A round-up of the 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] Reduced Data Temporary Softfork
Date(s): October 26 - October 28, 2025
Discussion: The Bitcoin community is debating a new soft fork proposal that would temporarily restrict arbitrary data storage on Bitcoin.
The initial idea came from Bitcoin Improvement Proposal (BIP) Editor Luke Dash Jr., who wrote in a separate email thread on the Bitcoin Development Mailing List that, if developers are considering limiting ScriptPubkey size, they should go the extra mile by limiting all other forms of arbitrary data storage.
Dash Jr. wrote:
If we’re going this route, we should just close all the gaps for the immediate future ... We can do these all together in a temporary soft fork that self-expires after a year or two. This would buy time to come up with longer-term solutions and observe how it impacts the real world.
For context on the discussion about limiting ScriptPubkey size and why it is not an outright ban on arbitrary data storage, refer to BTC Before Light issues #12 and #14.
On Sunday, a Bitcoin contributor named “Dathon Ohm” followed up on Dash Jr.’s comment by opening a pull request (PR) on Github to formalize the temporary soft fork idea into a BIP.
In an email to the Bitcoin Development Mailing List, Ohm explained:
Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on luke-jr’s ML proposal to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections … The idea is to strongly re-affirm in consensus that bitcoin is money, not data storage. It is implemented as a temporary softfork that can activate in one of two different ways: proactive, or reactive.
Proactive activation refers to a flag day activation, which offers a window of opportunity for node operators to vote on the soft fork and choose to activate the new consensus rules at a predetermined block height. Reactive activation refers to a retroactive activation of soft fork rules in the event of an “offending block.” This presumably refers to a Bitcoin block containing Child Sexual Abuse Material (CSAM) that would negatively impact the legality of Bitcoin node operations.
For more information about soft fork activation paths in Bitcoin’s governance history, refer to this BTC Toolkit resource.
Ohm is currently working on addressing the technical flaws in his original PR. The PR has been assigned a number, BIP 444, by Dash Jr..
BIP 444 is a contentious proposal that is deepening the rift in the Bitcoin community, which began with the controversy over the Bitcoin Core v30 release.
Since the v30 release, well-known Bitcoin thought leaders have spoken out against its features. Nick Szabo, an American cryptographer and computer scientist who was previously rumored to be the pseudonymous creator of Bitcoin, stated that he opposed the v30 major release and supported running alternative implementations, such as Knots.
Szabo wrote on X:
Arbitrary content on blockchains makes them far more risky, legally and morally, to operate, than with blockchains confined to financial transactions. Running a node where one cannot selectively delete unacceptable content without wider functional disruption is also far riskier than running data services where one can selectively delete unacceptable content without causing wider functional disruption.
One side of the Bitcoin community is strongly in favor of BIP 444, as it would effectively separate nodes that follow v30 release changes from those that do not by rejecting valid blocks from v30 nodes.
The other side of the community opposes BIP 444, arguing that the contention over v30 features is unwarranted and technically unsound.
Arguing against BIP 444, Jameson Lopp, Co-founder and Chief Security Officer of Casa, wrote in the email thread:
Even aside from all of the technical concerns, the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks makes it a non-starter in my opinion.
For community members who do not fall in either camp of the debate about BIP 444, there is a great deal of confusion about how this soft fork proposal would impact the security of the Bitcoin protocol.
One of the primary technical concerns raised about the proposal is the financial incentive it may create for miners to double-spend.
A Bitcoin contributor named “Mike Kelly” published a note on Tuesday explaining why miners would purposefully create blocks containing CSAM to create a temporary chain split in Bitcoin and profit from duplicated coins that could be spent before the protocol reaches consensus on the correct fork head.
Kelly wrote:
Because the BIP 444 policy branch and the legacy branch follow different transaction acceptance rules after activation height, holders can create pairs of conflicting transactions: one that violates the BIP 444 policy (containing oversized OP_RETURN) but is valid under base consensus, and one that complies with the policy. Each branch will confirm a different spend of the same UTXOs, enabling duplicated spendability. The weaker policy branch can be liquidated on exchanges that list the BIP 444 token, allowing holders to extract value before (or unless) the policy branch gains majority support—which is economically unlikely given the miner revenue disadvantage.
It is unclear how Ohm and other BIP 444 supporters intend to address the above concerns of the soft fork proposal, and other technical concerns, such as confiscated coins. However, as mentioned, a new version of the proposal is in the works.
Takeaway: What matters most is Bitcoin’s security and stability. Without these, Bitcoin —both as a technology and as a global asset —loses value.
All network stakeholders lose if a soft fork proposal that destabilizes Bitcoin is adopted. Thus, to the extent that BIP 444 undermines Bitcoin’s security, it is unlikely to be adopted.
Indeed, it would not be rational for stakeholders in either camp of the debate about v30 to adopt a soft fork proposal like BIP 444 that encourages double-spending.
However, the persistence of BIP 444’s supporters suggests a degree of dogmatism that prioritizes ideological purity about Bitcoin’s “moneyness” over the practical need for network stability.
When push comes to shove, will rational actors prevail over irrational actors? Bitcoin’s value hinges on the answer to this question, as does the value of every single open-source technology governed by a decentralized collective.
📧 Email Thread #2
Subject line: Public disclosure of 4 Bitcoin Core security advisories
Date(s): October 24, 2025
Discussion: On Friday, Antoine Poinsot, a Bitcoin Core developer at Chaincode Labs, disclosed four low-severity bugs that have since been patched in the latest major release of Bitcoin Core.
The bugs were:
CVE‑2025‑54604 – Disk filling from spoofed self-connections. An attacker could impersonate a node’s own connection (“self-connection”) and cause the victim to gradually run out of disk space. Fix: A log rate limiting, so self-connection logs are throttled and nodes can check for exploits in their own connections.
CVE‑2025‑54605 – Disk filling from invalid blocks. An attacker could send a node a large number of invalid blocks (i.e., blocks that don’t conform to protocol rules), which again results in disk space consumption and degraded performance. Fix: A change to invalid-block handling to ensure storage/logging is bounded and prevents unbounded disk usage.
CVE‑2025‑46597 – Highly unlikely remote crash on 32-bit systems. On older or less common 32-bit computer systems, a specially crafted block could crash the node software. Fix: Guard code paths on 32-bit builds to avoid the crash condition.
CVE‑2025‑46598 – CPU DoS from unconfirmed transaction processing. An attacker could continuously send a node specially crafted junk transactions that are unconfirmed (i.e., not yet part of a block), which the node attempts to validate, causing it to use excessive CPU time. Although the node eventually rejects the transactions, the repeated effort delays other processing (like block propagation). Fix: Developers implemented multiple mitigations for this bug that, collectively, reduce the validation time spent by a node per transaction.
Takeaway: As per the Bitcoin Core development protocol, two weeks after the v30 major release, Core developers released details about four low-severity vulnerabilities in their code that were fixed in the latest major release.
There is a one medium-severity vulnerability that Core developers have announced will be disclosed two weeks after the last affected release is considered fully deprecated, or “end of life.” Developers generally stop supporting releases roughly 1.5 years after their release.
So, assuming the medium-severity vulnerability affected all releases prior to v30, the disclosure of the fifth vulnerability is likely to be released sometime after the final release of v33, expected in early 2027.
The recent security disclosures are an important reminder that Bitcoin is not a static protocol. It requires continual maintenance and review to ensure the technology’s robustness and proper functioning.
🗞️Other News
A discussion about the motivations for why an individual would operate their own Bitcoin full node from home. (Delving Bitcoin)
A discussion about sourcing historical Bitcoin network data from 2012. (Bitcoin Talk)
An experimental version of Bisq Easy, v0.1.1, is now available on the Google Play Store. Bisq Easy is a decentralized exchange that enables Android users to trade bitcoin directly on-chain via the Tor network. (Bitcoin Talk)
There are three days left in the Bitcoin Talk Annual Pumpkin Carving Contest! To be included in the competition, participants must carve a Bitcoin-themed pumpkin and submit a photo of their work, along with a sheet of paper featuring their username and date of submission, in the discussion thread. (Bitcoin Talk)
Happy Halloween, everyone! 🎃
🟠 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.
🌟 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 fellow readers. The invite link to join is posted here:
Newsletter credits:
Special thanks to Shinhye Kim for the illustrations in this newsletter.
