After Taproot: Bitcoin’s Core vs Knots Data War in 2026

On 14 November 2021, at block 709,632, Bitcoin activated Taproot and almost nobody argued. It was the network’s first consensus upgrade since SegWit, it locked in with more than 90% of miners signaling, and it shipped the quiet machinery (Schnorr signatures, Merkelized scripts, and a new bc1p address format) that a generation of builders has leaned on ever since. Now, with the fifth anniversary approaching in Q4 2026, Taproot is back on the front page. Not for anything it added, but for a war it helped start.

Bitcoin in October 2026 is a network at odds with itself. Bitcoin Core, the dominant node software, tore the decade-old cap off arbitrary data in transactions; in response, something like a fifth to a quarter of reachable nodes switched to a rival client, Bitcoin Knots, that refuses to carry it. At the same time, the only serious attempt to add a new capability since Taproot, the OP_CTV covenant proposal, sits at exactly zero percent miner support. The coin itself is fine (BTC trades around $83,700, a market value near $1.68 trillion, according to CoinGecko). But the people who run Bitcoin can agree on neither adding new capabilities nor rolling back the data economy that Taproot’s own design made cheap. This is how the quietest upgrade in Bitcoin’s history became the loudest fault line in it.

Taproot was the last thing Bitcoin agreed on

Taproot activated through a process called Speedy Trial, a three-month window in which miners signaled readiness; it crossed the threshold quickly and switched on at block 709,632 in November 2021, as CoinDesk reported at the time. The package bundled three Bitcoin Improvement Proposals: BIP 340 (Schnorr signatures), BIP 341 (Taproot and MAST, the technique that hides unused spending conditions), and BIP 342 (Tapscript). Together they made complex spending conditions look like ordinary single-key payments on-chain, which is better for privacy and, for many transactions, cheaper.

What matters for the 2026 story is the date, and the silence around it. Taproot was Bitcoin’s first and, so far, last successful soft fork since SegWit in 2017. In the nearly five years since, not a single consensus change has activated. That is not for lack of ideas; the proposals have piled up. It is because the social machinery that once said yes has stopped producing agreement. The upgrade engine stalled, and in 2026 the stall became visible on two fronts at once: a fight over data in blocks that is being waged node by node, and a parallel paralysis over whether Bitcoin should ever gain new abilities again.

How Taproot turned Bitcoin blocks into contested real estate

To understand the war, start with the economics of a Bitcoin block. SegWit introduced the idea of block weight and gave witness data (signatures and scripts) a discount: a byte of witness data counts for roughly a quarter of a byte of ordinary transaction data toward the block limit. The intent was to fix transaction malleability and raise capacity. The side effect, unlocked more fully once Taproot made script-path spends routine, was that the cheapest place to put bytes on Bitcoin became the witness.

In January 2023 a developer named Casey Rodarmor shipped Ordinals, which exploited exactly this. An inscription embeds arbitrary data (an image, a block of text, a token record) inside a Taproot script-path witness, paying the discounted rate for the privilege. The result was a boom: for stretches of 2023 and 2024, inscriptions and the token protocols built around them dominated block space, and fees spiked to levels Bitcoin had not seen outside its biggest bull runs. Runes, which Rodarmor launched in April 2024, took a different route and wrote its data into OP_RETURN rather than the witness, a distinction that will matter in a moment.

Set aside whether you think inscriptions are art, spam, or a monetary distraction. The structural point is that Taproot, together with the witness discount it leaned on, turned Bitcoin blocks from a market for payments into a market for data. Once that happened, two questions became unavoidable: how should people be allowed to store data on Bitcoin, and who gets to decide? Those are the questions that detonated in 2025.

The 80-byte wall, and why Core tore it down

For more than a decade, Bitcoin Core shipped with a relay convention that quietly shaped all of this. Transactions could carry a small, provably unspendable output called OP_RETURN, and the default limit on it (the -datacarriersize setting) was 83 bytes, enough for roughly 80 bytes of usable data. The idea was a compromise: give people a tidy, prune-friendly place to anchor a hash or a timestamp, while discouraging anyone from treating the chain as a hard drive.

By 2025 the compromise had stopped working, and a group of Core developers decided to say so. On 27 April 2025, Peter Todd filed pull request #32359, proposing to drop the OP_RETURN size limit. The reasoning, laid out at length by Chaincode Labs developer Antoine Poinsot, was not that data storage is good; it was that the limit had become counterproductive. Because 80 bytes was not enough for some protocols, builders routed around it in ways that were strictly worse for the network. The limits, Poinsot wrote, “incentivize more harmful ways of storing data.”

The concrete mechanism is where Taproot comes back into the frame. When a project could not fit its data in a single OP_RETURN, it had two bad options. It could stuff the data into the witness, where, as Poinsot noted, “one can store ~5000 times as much data in a standard transaction by stuffing its witness.” Or it could bury the data inside fake, unspendable Taproot outputs, which is worse still, because those outputs never get spent and therefore sit in the UTXO set, the live database of coins that every full node must track, forever. Poinsot pointed to Citrea’s Clementine bridge as a real example: unable to use multiple standard OP_RETURN outputs, it resorted to unspendable Taproot outputs, permanently bloating every node’s state. The 80-byte wall, in other words, was pushing data out of the one place designed to hold it and into the places that hurt the network most.

On 10 October 2025, after months of argument, the change shipped in Bitcoin Core v30.0. The default -datacarriersize jumped from 83 bytes to 100,000 bytes, measured across all OP_RETURN outputs in a transaction, and nodes would now relay transactions carrying more than one such output. The old -datacarrier and -datacarriersize knobs were marked deprecated. Core’s maintainers stressed that this was a relay-policy change, a decision about which unconfirmed transactions a node forwards, and not a change to Bitcoin’s consensus rules. That distinction is technically correct, and politically beside the point to the people who were furious about it.

Enter Knots, the nodes that said no

If Core would relay the data, operators who hated it had an alternative: run different software. Bitcoin Knots, a long-standing fork of Core maintained by developer Luke Dashjr (who also helped launch the OCEAN mining pool, backed by Jack Dorsey), keeps the old tight filters and then some. By default it holds OP_RETURN to a far smaller size (reported at around 42 bytes, a single output) and refuses to propagate the inscription-style data it treats as spam, as node-software comparisons from Oak Research and others document.

What had been a rounding error became a movement. Knots ran on roughly 1% of nodes in early 2024 and only a few hundred machines in early 2025; after the v30 fight it surged past a fifth of the reachable network, with trackers such as Coin Dance showing it in the low-to-mid twenties by 2026. For a project with no marketing budget and essentially one principal maintainer, climbing from near zero to a quarter of visible nodes in under two years is a remarkable protest vote.

Dashjr has been the loudest voice against the change, and his objection is as much legal as technical. His central fear is that an operator who relays and stores arbitrary data could be exposed to liability if that data turns out to be illegal, a risk he argues Core imposed on everyone without consent. He has also disputed that re-tightening the knob even helps: in a widely shared post he warned that the setting now behaves differently, so that “datacarriersize=83 now (as of Core 30) allows for 83 outputs totalling 830 bytes of spam” (in his words), rather than the small allowance it once implied. Dashjr has gone further elsewhere, calling the release malicious and warning it could kill Bitcoin if it reached significant adoption. Core’s maintainers see the same facts and shrug: nothing stops an operator from configuring their own node, and no one is forced to run v30 defaults.

Core versus Knots: the same chain, two rulebooks

Here is the fact that keeps the data war from becoming a chain split: Core and Knots enforce identical consensus rules. They agree, byte for byte, on what makes a block valid. They differ only on relay policy, the local rules each node applies to decide which unconfirmed transactions it will accept into its mempool and pass to peers. A transaction Knots refuses to relay is still perfectly valid; if any miner includes it in a block, every Knots node accepts that block without complaint. The disagreement shapes how transactions travel before they are mined, not which chain exists afterward.

That is why no one’s coins are at risk from the fight, and why comparisons to the 2017 block-size war are only half right. In 2017 the dispute was over consensus, so it could and did split the network into two coins. The 2026 dispute is over policy, so as long as both clients keep the same consensus rules there is one Bitcoin and one ledger. What filtering actually buys the Knots camp is friction: if enough of the network refuses to relay data-heavy transactions, they propagate more slowly and are a little harder to get mined. Whether a fifth of nodes is enough friction to matter is exactly the question nobody can answer cleanly.

Is a quarter of the nodes even real?

The headline number deserves a caveat. Reachable-node counts are not a vote, and they are cheap to game. Spinning up hundreds of listening nodes on rented cloud servers costs very little, and Core-aligned developers have argued that part of the Knots surge is inflated, in the sharpest framing, one actor posing as thousands, as CryptoSlate reported. Even taken at face value, a node’s presence on the network is not the same as economic weight; exchanges, custodians, payment processors and miners move far more coin than a hobbyist’s single machine, and most of them run Core.

Still, discount the figure however you like and it remains the most visible dissent Bitcoin has seen in years. The deeper point is cultural: choosing which client to run has become a political act, a statement about what you think Bitcoin is for. That is a new kind of pressure for a project whose entire security model assumes that running your own node is normal, cheap, and ideologically neutral. The same sovereignty that lets an Ethereum solo staker or a Bitcoin full-node operator opt out of trusting anyone also lets them opt into a faction.

When the fight turned personal: DNS seeds and BIP editors

Through late 2025 and into 2026, the dispute stopped being about bytes and started being about institutions. On 4 December 2025, Bitcoin Core merged a change removing a long-running DNS seed operated by Dashjr, one of a handful of hardcoded servers that new nodes query to find their first peers. The stated reason, documented in Blockspace’s writeup and GitHub issue #33734, was a neutrality violation: the seed was not returning a representative sample of the network and reportedly withheld nodes running Core versions newer than 28.1, effectively steering new users away from recent Core releases. The change was backported to the v30.x branch.

Dashjr pushed back hard, defending the seed on social media: “My DNS seed has always had a policy to lag eligible node versions a bit,” he wrote, arguing that seeds were never meant to be uniform, only fair. The symbolism was hard to miss: the maintainer of the dissenting client was being unplugged from plumbing the dominant client controls. Months later, after a related soft-fork effort failed, Dashjr was also removed from the Bitcoin Improvement Proposals editor team. Whatever the merits of each decision, the social layer that shipped Taproot by broad consensus is visibly coming apart, and that erosion is the real story beneath the node-share chart.

The counter-attack: trying to put the limit back

Running Knots is a defensive move; it only changes what your own node relays. The restriction camp also went on offense, trying to write the old limits back into the rules themselves. Two proposals appeared in October 2025, within days of the v30 release, and both aimed to restore caps at the consensus layer rather than leave them to policy.

BIP-444 proposed a temporary soft fork, roughly a year long, that would reinstate an 83-byte OP_RETURN limit, cap OP_PUSHDATA at 256 bytes, and limit scriptPubKeys to 34 bytes, pitched as a way to curb spam and reduce node-operator legal exposure. It drew immediate skepticism: it was published anonymously, outside the usual review channels, and Peter Todd quickly showed it could be trivially bypassed by embedding the text of the proposal itself into a transaction. Critics called the exercise a slippery slope toward censorship; CryptoSlate and others warned it could trigger a chain split if forced through.

BIP-110, the “Reduced Data Temporary Softfork,” went further on process. Alongside restoring data caps aimed squarely at Ordinals, BRC-20 tokens and Runes, it proposed lowering the miner activation threshold from the customary 95% to 55%, a shortcut meant to get a contested change over the line. The experiment failed in public. When BIP-110 went to miner signaling in mid-2026, support peaked at about 2.53%, according to The Cryptonomist; the splinter chain that tried to enforce it produced two blocks and stopped. Its backers have since floated user-activated and proof-of-work-change threats, the nuclear options of Bitcoin governance, which tells you how stuck the restriction effort really is. (HOGE Wire has covered the BIP-110 fight in depth separately.)

Why restricting the data will not make it go away

The restriction camp has a demand problem that no soft fork solves. The appetite for putting data on Bitcoin is not a 2023 fad that cooled; it is structural, and it comes from paying customers. Ordinals never died: the speculative frenzy faded, but a durable base of inscriptions, a Runes market, and BRC-20 activity carried into 2026, and the people doing it are willing to outbid ordinary payments for block space. When demand is that persistent, a policy filter is a speed bump, not a wall.

This is the uncomfortable core of Peter Todd’s position, and it is why his bypass of BIP-444 landed so hard. If you cap OP_RETURN, data migrates to the witness, where it is roughly five thousand times cheaper by weight. If you try to cap the witness, you break legitimate Taproot scripts and Lightning. If you cap script sizes, builders encode data in output addresses or spread it across many transactions. Every restriction has a detour, and most detours are worse for the network than the thing being banned, which was Antoine Poinsot’s argument for lifting the limit in the first place.

It is worth being clear-eyed about who the data actually serves in 2026, because not all of it is monkey pictures. The same OP_RETURN capacity that carries a meme also carries bridge proofs and rollup commitments; Citrea’s design and other Bitcoin Layer 2s anchor their state to the base chain, and they need somewhere efficient to put it. That is the irony at the center of the war: the loudest fight is over whether to permit the very primitive that the most ambitious Bitcoin scaling projects depend on. Welding the pipe shut would not just inconvenience inscribers; it would push the serious builders back into abusing Taproot outputs, the exact behavior everyone agrees is worst for the network.

None of this means the data is harmless or that the critics are wrong to worry; permanent, unfilterable storage on a global ledger raises real questions about node costs and legal exposure. It means only that the lever the restriction camp keeps reaching for, consensus-level limits, is the one least likely to work, which is why the fight keeps collapsing back onto relay policy and the node-share chart.

The other frozen front: covenants nobody will signal

While one camp fought to restrict data, another spent 2026 trying to expand what Bitcoin can do, and got exactly as far. The flagship is OP_CTV (CheckTemplateVerify, BIP-119), a modest covenant opcode that lets a transaction commit in advance to how its coins may later be spent. That one primitive would enable vaults (so a theft attempt can be caught and reversed), congestion control, and more efficient payment pools; its supporters have argued for years that it is the single highest-leverage thing Bitcoin could add.

An activation client shipped with a signaling window running from 30 March 2026 to 30 March 2027 and a 90% miner threshold (1,815 of 2,016 blocks per period). As of early October 2026, deep into that window, the signal reads 0.00%. Not a single block has signaled support in any tracked difficulty period, according to the BIP-119 monitor. CSFS (CheckSigFromStack) and the wider covenant toolkit sit in the same holding pattern. So Bitcoin in 2026 can move neither forward (0% for CTV) nor backward (2.53% for BIP-110). It is frozen in both directions, and the thing it is frozen around is the data economy that Taproot’s witness discount made cheap.

Why Bitcoin’s miners are sitting on their hands

Both deadlocks run through the same chokepoint: miners hold the signaling pen, and they have every reason to leave it on the desk. Signaling for a contested change is risky. In the worst case it can orphan their blocks or split the chain they are paid in, and even in the ordinary case it invites a public backlash from whichever faction loses.

The incentives point at inaction from both sides. On the restriction front, miners earn fees from exactly the data BIP-110 would ban, so voting to shrink their own revenue is a hard sell, especially now that the block subsidy has halved to 3.125 BTC and fees remain a thin, volatile slice of the total. The economics of that squeeze, and the shrinking hashrate map it has produced, are a story in their own right, but the upshot for governance is simple: miners will not volunteer to earn less. On the expansion front, no covenant proposal commands anything like the lopsided support Taproot had, and miners have absorbed the lesson that activating something contentious is how you start a civil war.

The result is a rational stalemate. With the community split and block production itself an increasingly industrial, margin-driven business, the safest move for any individual miner is to signal for nothing and keep collecting fees. That is why 0.00% is not an accident or an oversight; it is the equilibrium.

How the data war unfolded

The escalation from a routine code review to an institutional rupture took about eighteen months. Laid out in order, the sequence shows how a relay-policy tweak metastasized into a fight over who governs Bitcoin.

What it means if you run a node, hold BTC, or build on Bitcoin

For node operators, the practical takeaway is that your client is now a statement, but not a risk to your money. Core relays large data by default (and you can still tighten the knobs, at least until the deprecated settings are removed); Knots filters aggressively out of the box. Either way you validate the same chain, so the choice is about which transactions you help propagate, not which ledger you follow. If you have strong feelings about inscriptions, you finally have a lever; if you do not, the defaults are fine.

For holders, the reassuring news is that a relay-policy disagreement cannot split your coins the way the 2017 consensus war threatened to. There is one Bitcoin, trading around $83,700, and nothing in this fight changes that. The uncomfortable news is what the fight exposes about the long run: if blocks fill with cheap data today but fee revenue still cannot replace the shrinking subsidy tomorrow, the security-budget question only gets sharper, and the community cannot even agree on whether that data is the problem or the solution. That is not an abstract worry: the subsidy keeps halving toward zero over the coming decade, and if a thin, data-driven fee market is all that stands between Bitcoin and a shrinking security budget, the question of what blocks are for stops being cultural and becomes existential.

For builders, the data primitives are the product. The roomier OP_RETURN in v30 genuinely helps honest designs, Runes, bridge proofs, and rollup commitments like Citrea’s, that previously had to abuse Taproot outputs. But policy that can flip between releases, and clients that filter differently, make Bitcoin a moving target compared with chains that ship upgrades on a schedule; Ethereum spent the same period rolling out account-abstraction changes like EIP-7702 while Bitcoin argued over 80 bytes. On the regulatory question, it is worth being precise: no regulator approves or blocks Bitcoin’s relay policy. The SEC oversees securities and intermediaries, not which bytes a node forwards, and the legal exposure Dashjr worries about belongs to a separate, unsettled area of content law. For the broader compliance backdrop heading into year-end, see our Q3 regulatory scorecard.

Taproot’s real legacy is the last consensus

Taproot shipped the tools, Schnorr signatures, Tapscript, and the witness discount it inherited from SegWit, that made Bitcoin more private, more efficient, and (nobody planned this part) a desirable place to park data. That data economy is now the thing the network cannot agree on. Is it legitimate use or parasitic abuse? Should the pipe be widened, as Core did, or welded shut, as BIP-110 wanted? Five years of accumulated disagreement have hardened into two camps that no longer trust each other’s clients, maintainers, or motives.

The crucial thing to understand is that the deadlock is not really technical. The clients interoperate. The chain is healthy. Blocks are full, the price is holding, and the lights are on. The paralysis is social, and social problems do not have a pull request. Code can be merged; trust, once spent between factions, has to be rebuilt the slow way. What would break it is a force strong enough to manufacture consensus again: a proposal with Taproot-level, uncontested support (none is close), a killer application that makes one side’s case undeniable, or an external shock such as a credible quantum-computing threat that leaves no room left to argue.

Until one of those arrives, the most important number in Bitcoin may not be the price. It is 0.00%, the share of blocks willing to vote for anything at all. Taproot was the last time Bitcoin said yes. In 2026, five years on, its real legacy is the argument it left behind, and a network strong enough to run indefinitely on rules it can no longer change.

Frequently Asked Questions

What did Bitcoin Core v30 change about OP_RETURN?

Bitcoin Core v30, released on 10 October 2025, raised the default -datacarriersize from 83 bytes to 100,000 bytes and allowed multiple OP_RETURN outputs in a single transaction, which effectively uncapped how much arbitrary data a standard transaction can carry. The old -datacarrier and -datacarriersize settings were marked deprecated. Importantly, this was a relay-policy change, not a change to Bitcoin’s consensus rules.

What is the difference between Bitcoin Core and Bitcoin Knots?

Both enforce identical consensus rules and follow the same blockchain, so they never disagree about which blocks are valid. They differ on relay policy: Core v30 forwards large-data transactions by default, while Bitcoin Knots, maintained by Luke Dashjr, keeps a tight OP_RETURN limit and refuses to relay data it treats as spam. By 2026, Knots ran on roughly a fifth to a quarter of reachable nodes.

Does running Bitcoin Knots create a separate blockchain?

No. Because Core and Knots share the same consensus rules, they stay on one chain. A transaction Knots will not relay can still be mined, and once it is in a block both clients accept it. The disagreement affects how transactions spread before confirmation, not which chain exists, so holders face no split-coin risk from it.

What does the OP_RETURN war have to do with Taproot?

Taproot’s witness discount and script path made it cheap to embed data in transactions, which fueled the Ordinals inscription boom. The main argument for lifting the OP_RETURN limit was that the old 80-byte cap pushed data into worse places, including fake, unspendable Taproot outputs that bloat the set of coins every node must track. The fight is largely about cleaning up the data economy Taproot enabled.

Why has Bitcoin not activated a soft fork since Taproot?

Every attempt has stalled on consensus. The OP_CTV covenant proposal (BIP-119) opened a signaling window in 2026 but has drawn 0% miner support, while restriction proposals such as BIP-110 peaked near 2.53%. Miners avoid signaling for contested changes that could split the chain, so with the community divided, nothing reaches the threshold to activate.

By Nathan Reiss, senior Bitcoin correspondent at HOGE Wire, covering the base layer and the politics of its protocol.