Bitcoin’s Secret Civil War of 2025: Core vs Knots

How a Tiny Note Field Triggered the OP_RETURN War of 2025 — And Why It Still Shapes Bitcoin’s Future

Most Bitcoin users had no idea a quiet civil war was unfolding in 2025 — one that nearly split the network in two. While wallets kept working and price tickers stayed green, behind the scenes, two visions for Bitcoin were clashing: Bitcoin Core, the long-standing dominant software, vs. Bitcoin Knots, the purist alternative fighting to keep Bitcoin “money only.” At the heart of this battle? A few lines of code that removed an old limit on OP_RETURN — Bitcoin’s “tiny note” field — opening the door to memes, JPEGs, tokens, and a flood of debate. What started as a minor policy change spiraled into accusations of spam, censorship, and even illegal content — with one camp accusing the other of turning Bitcoin into a garbage dump, and the other firing back with cries of gatekeeping and authoritarianism. This is the story of how a low-key software update — Bitcoin Core v30 — ignited the OP_RETURN War of 2025, and how it may have forever reshaped the politics of Bitcoin upgrades.

OP_RETURN in Plain English: Bitcoin’s Tiny “Note” Field

Imagine a Bitcoin transaction as a piggy bank. Normally you just put coins (BTC) into it. OP_RETURN is like taping a little note onto that piggy bank. The coins are the money; the note is just extra data.

Technically, OP_RETURN is a special part of Bitcoin’s scripting language that lets you embed arbitrary bytes — any message or data — into the blockchain. Outputs using OP_RETURN are deliberately made unspendable, meaning nobody can ever use them as money. That’s by design: it prevents this “note space” from cluttering the set of actual spendable coins.

When OP_RETURN was first introduced in 2014, the note had to be tiny. Initially it was capped at 40 bytes, later increased to 80 bytes — enough for a short message or a tiny chunk of metadata, but nowhere near enough for an image or a file. The philosophy was: small bits of data are fine, but Bitcoin is not supposed to be a general-purpose data warehouse. Keep the notes small so people don’t abuse the piggy bank with giant posters.

That all changed in 2025.

What Changed in 2025: From Post-It Notes to Full Books

In October 2025, the maintainers of Bitcoin’s main reference implementation, Bitcoin Core, released version 30.0 (v30). One of the most controversial changes in that release was the removal of the 80-byte OP_RETURN limit. Instead of only being able to tape a tiny Post-it note to your piggy bank, the software now allowed you to tape on an entire book, photo album, or whatever you could fit into a block — roughly four megabytes’ worth of data — as long as you paid the transaction fees.

This was not just a technical tweak; it was a philosophical shift. For years, OP_RETURN had been intentionally constrained to discourage large-scale data storage. But by 2023–2024, users had discovered other ways to embed large amounts of data using SegWit and Taproot, especially in the witness field. Techniques like Ordinals inscriptions used those mechanisms to write images and other data onto the chain. The old OP_RETURN cap was being sidestepped in practice.

Some developers, notably Peter Todd, argued that it made more sense to allow larger data in a dedicated, unspendable field like OP_RETURN than to let people stuff it into places that were worse for performance and harder to manage. In other words, if big data was going to come anyway, better to channel it through a “proper” door rather than via hacks. Removing the limit in v30 was, in this view, just aligning the policy with reality.

But opening that door triggered a storm over “spam.”

Why People Started Yelling Spam

Once v30 effectively uncapped OP_RETURN, many Bitcoiners became alarmed. They started calling large, non-financial data “spam.” In this context, spam meant transactions that used Bitcoin’s block space to store data unrelated to ordinary payments: NFTs, images, videos, random files, memes, and so on. Critics worried that if you gave people the freedom to upload entire books and images onto Bitcoin, they would do exactly that, and blocks would fill up with what they saw as garbage, making it more expensive and harder for normal users to send simple payments.

There was a more serious concern too: illegal content. In theory nothing stops someone from encoding truly horrific or illegal material into an OP_RETURN field. If that data is committed to the blockchain, every full node operator is forced to store it and relay it. That raises uncomfortable legal and ethical questions. Some node operators might feel compelled to shut down their nodes rather than host such content, which would undermine decentralization and shift power toward big institutions with legal teams and data centers.

On the other side, many argued that spam is subjective. Bitcoin is permissionless; if you pay the fee and your transaction is valid under the rules, the protocol should not care what your data represents. One person’s spam is another person’s art or proof-of-ownership or timestamped record. The genesis block itself famously contains a newspaper headline. Over the years people have used Bitcoin to store digital art, token metadata, and various small records. To this camp, calling these uses “spam” was just a value judgment.

For miners, large data transactions often meant more fees, not less. From their point of view, any valid transaction that pays enough to be included is fine. So while parts of the community fumed about spam, miners largely saw an opportunity: new demand for block space and a stronger fee market.

This fundamental disagreement — whether non-financial data is a legitimate use of Bitcoin — set the stage for the next big escalation: BIP-444.

BIP-444: A “Diet Plan” for the Blockchain

BIP-444, published in late October 2025 under the pseudonym “Dathon Ohm,” proposed a drastic remedy for the perceived spam problem. It suggested a temporary soft fork — a backward-compatible rule change — that would essentially put Bitcoin on a one-year data diet.

The idea was to reimpose a small limit on OP_RETURN data (around 83 bytes) and to add new restrictions on other parts of transactions so that people couldn’t sneak in large blobs of data through clever scripting. It also explicitly targeted the script tricks used by Ordinals-style inscriptions, such as certain uses of OP_IF in Taproot scripts. In practice, BIP-444 would have shut down or severely crippled most on-chain NFTs and inscription protocols for about a year.

Supporters billed BIP-444 as an emergency brake. They argued that uncapped or lightly restricted data posed real risks, especially around illegal content and blockchain bloat. Allowing anyone to write anything forever into the blockchain, they said, could force node operators into untenable legal positions and discourage ordinary users from running nodes. In their view, this threatened Bitcoin’s decentralization and long-term security more than a temporary restriction on data-stuffing.

The proposal also had a prominent champion: Luke Dashjr (Luke-Jr), a long-time Bitcoin developer and maintainer of the alternative node software Bitcoin Knots. Luke is known for a “Bitcoin as sound money” purist stance and has been a vocal opponent of Ordinals and other non-monetary uses. He did not claim authorship of BIP-444 but quickly endorsed it and argued it had no technical show-stoppers, which led many to see the proposal as an expression of his camp’s agenda.

However, as soon as BIP-444 surfaced, it faced immediate and intense backlash.

The Censorship Debate: Neutrality vs Protection

Critics of BIP-444 saw it as a dangerous step toward protocol-level censorship. Bitcoin’s ethos has long been that the network does not care about the content or purpose of your transaction; it only cares if the transaction is valid according to consensus rules and if you pay the required fee. BIP-444, by design, attempted to make certain content — large inscriptions, NFTs, and non-financial data — effectively impossible on-chain for a period of time.

This raised several objections. First, a soft fork that invalidates some previously valid transactions, even temporarily, is a big deal. Bitcoin changes are supposed to be extremely conservative, and invalidating previously acceptable transaction patterns feels like rewriting the social contract after the fact. Second, there is the slippery slope problem: if the protocol starts filtering content once, where does it end? Today you ban big JPEGs and inscriptions; tomorrow someone proposes banning certain addresses, gambling, or politically sensitive payments. Once you accept the idea of content-based restrictions at the protocol level, it becomes much easier to justify more.

There were also more practical criticisms. Defining “non-financial” data is far from trivial. Many transactions embed various kinds of metadata for legitimate reasons, and people can encode data arbitrarily into script or signatures in ways that are hard to detect. Any set of rules that tries to distinguish good from bad content risks both missing things it’s supposed to block and blocking things it shouldn’t. Bitcoin is not built to be an on-chain content scanner.

Prominent voices like Jameson Lopp pointed out that the proposal’s treatment of content was vague and moralistic rather than technical. Others argued that running a full node has always involved holding whatever is in the blockchain, and that if someone is uncomfortable with that, the correct response is simply not to run a node, not to change the rules of Bitcoin for everyone else.

The battle lines were drawn: BIP-444 supporters saw it as a temporary protective measure against catastrophic legal and scaling risks; opponents saw it as a dangerous precedent that violated Bitcoin’s neutrality and attacked legitimate, fee-paying uses.

Core vs Knots: Two Policies, One Chain

Even before v30 officially rolled out, the conflict was playing out in the form of two widely used node implementations with differing policies: Bitcoin Core and Bitcoin Knots.

Bitcoin Core, the dominant implementation, adopted the new, more permissive OP_RETURN policy. By default, Core 30.0 nodes would accept and relay transactions with multiple, potentially large OP_RETURN outputs, as long as they were valid and paid enough fees. Core maintainers and many developers saw this as a rational policy adjustment that aligned relay behavior with what users were already doing in other parts of the protocol.

Bitcoin Knots, maintained by Luke Dashjr, took a much stricter approach. Knots nodes refused to relay transactions with large OP_RETURN data and maintained more aggressive filters on what they considered spam. In network terms, Knots acted like a strict librarian who rejects what they see as junk mail at the door rather than letting it into the public reading room.

By mid-2025, this had real network impact. Thousands of nodes — roughly 7–12% of the network — were running Knots, up from almost none before. That meant a non-trivial slice of the network was intentionally refusing to carry certain kinds of transactions. Core supporters accused Knots of harming network connectivity and blocking valid transactions, while Knots supporters insisted that they were simply protecting Bitcoin from abuse and that node operators had every right to enforce stricter policies.

At one point, an anonymous Core developer, frustrated with this situation, published a “ban list”: a set of instructions for Core users on how to disconnect from all Knots nodes. This escalated tensions even further. Some in the Core camp supported the idea, arguing that nodes which refused to relay valid transactions were effectively freeloading on the rest of the network. Others, however, thought the ban list was an overreaction and “objectively more stupid” than what Knots was doing. It was a clear sign that the conflict had moved from technical disagreements into more personal and political territory.

Despite this, the blockchain itself remained unified. The differences between Core and Knots were at the policy level — what transactions they relayed and accepted into their mempools — not at the consensus rule level of what blocks were considered valid. There was still only one Bitcoin chain.

The Climax: v30 Release and BIP-444 Drop

Around October 10, 2025, Bitcoin Core v30.0 was officially released. From that point on, if you installed Core with default settings, your node would happily relay and accept transactions with much larger OP_RETURN data. Node operators could still configure stricter limits manually, but the “vanilla” behavior was permissive.

Shortly afterwards, on October 24, 2025, BIP-444 was published. The coincidence of timing turned an already tense situation into what many people began calling the “OP_RETURN war” or “spam war,” inviting comparisons to the 2017 Blocksize War.

On one side was a camp that saw Bitcoin first and foremost as digital gold and sound money. They argued that the network’s block space should be reserved for financial transactions and that turning Bitcoin into a decentralized Dropbox for arbitrary content was a perversion of its purpose. For them, protocols like Ordinals and Runes were at best a distraction and at worst an attack on Bitcoin’s integrity. BIP-444 was their way of trying to put the genie back in the bottle.

On the other side was a camp that saw Bitcoin’s neutrality and openness as central virtues. They argued that if people wanted to use Bitcoin’s limited block space to store art, tokens, or other data, and were willing to pay the fees, that was a legitimate use. From this perspective, attempts to enshrine content-based restrictions at the protocol level looked like censorship. They worried about the precedent: if developers and miners started deciding which uses were “valid” or “spam,” it opened the door to all kinds of future interventions.

Most miners, meanwhile, were conspicuously unenthusiastic about BIP-444. Many of them benefited from the fee revenue generated by inscription and token-related activity, and they were understandably wary of any change that would reduce that revenue without compelling technical necessity. A few mining pools publicly criticized BIP-444 as poorly thought out or simply “a bad idea,” while at least one smaller pool voiced support for stricter filters. Overall, however, hashpower signaling remained weak to nonexistent for any BIP-444-style fork, making it highly unlikely to activate.

By November 2025 it had become clear that there was nowhere near the level of consensus required for a contentious soft fork. BIP-444 remained a proposal on paper, not an active upgrade path. The OP_RETURN war, for all its drama, looked increasingly like a social conflict rather than the prelude to an actual chain split.

A Simple Timeline of the OP_RETURN War (Key Events)

To understand how this conflict unfolded, let’s break down the major players in the OP_RETURN war of 2025 in a simplified timeline:

• 2014–2018: OP_RETURN was introduced in 2014 (with a 40-byte limit, later 80 bytes) to give people a small outlet to embed data without harming the system. Early on, projects like Omni (Mastercoin) used OP_RETURN to issue tokens. The 80-byte limit kept things fairly quiet; big data didn’t really live in Bitcoin yet, aside from some rare stunts.
• 2017–2021: SegWit and Taproot upgrades inadvertently opened other avenues for storing data. These upgrades weren’t meant for data storage, but clever users discovered they could use the witness field and Taproot scripts to embed large chunks of data at lower cost. In 2023, a protocol called Ordinals became popular, allowing people to insert images and art (called “inscriptions”) in Bitcoin by using these tricks. This triggered the first big flare-up of the debate: some loved the new fun use-case, others hated that blocks were being filled with “JPEGs” and even meme tokens.
• Mid 2023: Developer Peter Todd suggested a change: instead of letting people use sneaky ways to stuff data, why not remove the small limit on OP_RETURN? His logic was that people were already putting data in anyway, better they use OP_RETURN which doesn’t bloat the UTXO set. The initial attempt didn’t pass, but it planted a seed.
• April — June 2025: Non-financial uses kept growing. Another protocol called Runes (launched April 2024 by the creator of Ordinals) used OP_RETURN to create a new token system. OP_RETURN usage shot through the roof in 2024. In April 2025, Peter Todd and others renewed the push to remove the OP_RETURN cap. After intense discussion, Bitcoin Core maintainers agreed to merge the change in June 2025. Luke Dashjr and allies strongly opposed this in discussion, but the change was set to go live in the next release.
• Throughout 2025: Even before the v30 software was officially released, the community was arguing fiercely. On one side, developers and users aligned with Bitcoin Core supported the change. On the other, Luke Dashjr’s Bitcoin Knots refused to relay large OP_RETURNs and kept stricter filters. By mid-2025, thousands of nodes were running Bitcoin Knots — about 3,000 nodes, roughly 7–12% of the network. These Knots nodes acted like strict librarians, not accepting the “junk mail” transactions, whereas Bitcoin Core v30 nodes were ready to accept them.

What Actually Changed by the End of 2025?

By the end of 2025, the situation looked roughly like this.

First, there was no protocol-level rollback. The OP_RETURN limit removal in Bitcoin Core v30 remained in effect. Bitcoin’s consensus rules did not change, and large OP_RETURN data stayed technically valid. BIP-444, pitched as a temporary emergency measure, did not move forward toward activation.

Second, the community had clearly been strained, but the system proved resilient. There were ugly episodes, including calls to ban nodes and emotional declarations about “losing faith” in certain developers, but no chain split materialized. Miners largely stayed neutral or fee-driven, and the social temperature never quite reached the fever pitch of the 2017 Blocksize War.

Third, the war did raise broader awareness of the legal and ethical risks around on-chain content. While academic papers had discussed the possibility of illegal material being embedded in the blockchain years earlier, the OP_RETURN debate pulled those concerns into mainstream discussion. Consultations with legal experts suggested that node operators were unlikely to be held liable merely for incidental storage of blockchain data, which calmed some fears, but the issue did not disappear. It remains a lingering worry: what happens if someone maliciously uses Bitcoin to plant truly unacceptable content?

Fourth, the market for node software became slightly more diverse. Bitcoin Core’s share of nodes dropped as Bitcoin Knots and other implementations gained ground, driven largely by people who wanted stricter filters. This was a clear signal that if a significant minority dislikes policy changes, they will run alternative software. Future Core changes will likely be weighed against the risk of further fragmentation in the node ecosystem.

Finally, the episode reinforced the reality that block space is scarce and contested. New demand from inscriptions, NFTs, and token protocols tightened the fee market. This is good for miners and long-term security but can mean higher transaction costs for everyday users. Some see this as a natural and healthy evolution; others see it as a distraction from Bitcoin’s role as peer-to-peer money.

Perhaps the most important intangible outcome is that the community still did not converge on a shared definition of “spam.” The protocol itself continues to treat all valid transactions equally, without trying to judge their economic purpose. “Spam” remains a social label that people attach to uses they personally dislike.

What This Means for Future Upgrades Like OP_CAT

The OP_RETURN war was not just about data storage. It also shaped the social landscape for future Bitcoin upgrades, especially those that expand Bitcoin’s programmability, such as OP_CAT.

OP_CAT is an opcode — a script operation — that simply concatenates two pieces of data. That sounds trivial, but in Bitcoin Script, concatenation is a powerful building block. Re-enabling OP_CAT (it existed in early Bitcoin but was disabled) could unlock more expressive smart contracts and covenant-like constructions, allowing people to build vaults, more sophisticated multi-step spending conditions, and even more advanced protocols on top of Bitcoin.

The same ideological split that underpinned the OP_RETURN war is highly relevant to OP_CAT. The “money-only” camp sees Bitcoin’s value in its simplicity, predictability, and tight focus on being sound money. They are wary of adding new opcodes and complexity that might broaden Bitcoin’s use beyond straightforward payments and store-of-value functions. For them, features that resemble Ethereum-style flexibility are viewed with suspicion, as potential avenues for bloat, vulnerabilities, or mission drift.

The more “builder-friendly” camp, on the other hand, sees Bitcoin’s long-term strength in its ability to support richer functionality while preserving its core properties. They view OP_CAT and related proposals as ways to make Bitcoin more useful for advanced custody, trust-minimized trading, and other financial applications that actually reinforce its role as money. To them, smart-contract-like features on Bitcoin are not a distraction; they are a way to pull activity and value back onto the main chain or tightly coupled layers.

The OP_RETURN war also highlighted how important process and communication are. If removing an 80-byte relay limit — a policy change, not a consensus rule change — can trigger such intense backlash, then any proposal that actually changes consensus rules (like adding OP_CAT via a soft fork) will need to be handled with great care. The OP_CAT BIP (BIP-347) may be technically sound, but its success depends on broad social consensus, not just code correctness.

Proponents of OP_CAT now know they must frame it carefully. They will need to emphasize how it strengthens Bitcoin’s monetary use — for example, by enabling safer vault constructions that make self-custody less risky, or by allowing more efficient and trust-minimized financial contracts that keep users closer to BTC rather than pushing them to other chains. They will also need to reassure skeptics that OP_CAT is not a backdoor to more spam, nor a step toward turning Bitcoin into a general-purpose computation platform.

In short, the OP_RETURN war was a reminder that Bitcoin moves slowly and that changes are as much about human consensus as they are about technical merit. It showed that Bitcoin can absorb new uses like inscriptions and OP_RETURN data without collapsing, but it also made clear that a vocal part of the community will fiercely resist anything they see as threatening Bitcoin’s ethos.

For OP_CAT and future upgrades, the lesson is clear: expect thorough, sometimes painful debate; expect strong resistance from those who fear complexity or misuse; and expect that any successful proposal will need to convincingly prove its value to Bitcoin’s core mission as sound, censorship-resistant money. The “war” of 2025 underlined that keeping the community aligned is every bit as important as writing good code — and that may be the most important upgrade path of all.