Bitcoin Knots Captures 22.6% of Network as Core Schism Deepens

In October 2025, Gloria Zhao merged a pull request into Bitcoin Core that would have seemed routine to most observers: expanding the OP_RETURN limit from 83 bytes to 100,000 bytes. This is the part where you expect a technical debate and then consensus. Instead, it triggered the fastest adoption surge for alternative Bitcoin node software in the protocol's eleven-year history. By February 2026, nearly one in four publicly reachable Bitcoin nodes ran Bitcoin Knots instead — a fork maintained by a single developer who believes Core has surrendered Bitcoin's identity to become a general-purpose data ledger.

Bitcoin Core is the reference implementation. It runs on the majority of nodes, mines the majority of blocks, and sets the relay policies that define what the network considers a valid transaction worth propagating. Bitcoin Knots is a derivative fork, launched in 2011 by Luke Dashjr, one of the protocol's earliest contributors. Both implementations validate blocks identically — this is not a chain fork, not a consensus split, but a policy fork. The difference is in what they let through the door. Core says yes to OP_RETURN data because the engineering logic is sound: if people will use the blockchain for data anyway, forcing them to use less-efficient methods wastes more block space, not less. Better to be neutral and let the market price it. Knots says no because Bitcoin is money, not a content platform, and every byte of arbitrary data is an attack on the network's lean, defensible character. One maintainer, Luke Dashjr, decides policy for Knots. Fifteen lead maintainers and over six hundred contributors drive the direction of Core. That difference matters far more than the code.

The numbers tell the story. Bitcoin Knots had 69 nodes in January 2024. By September 2025, it had crossed 4,200 — representing 18% of the network. As of February 11, 2026, Knots ran 5,599 public nodes out of 24,747 reachable nodes, or 22.6% of the total. This is a 8,000% increase in fourteen months. That surge did not come from technical merit or better performance; it came from ideology. Dashjr increased the default `datacarriersize` limit in Knots to 83 bytes to preserve backward compatibility with older protocols, acknowledging the strictness is not about technical purity but about resistance to the direction Core is moving. Bitcoin Core v31.0 is now in release candidate 4 as of April 8, 2026. Knots' latest release is version 29.3, dated February 10, 2026 — meaning Knots has not yet integrated the v30 or v31 Core codebase and is falling further behind on technical updates while its node count climbs.

What created the conditions for this schism was not spontaneous. Core's reasoning for raising the OP_RETURN limit was defensible: if you allow arbitrary data embedding, at least make it as efficient as possible. The engineering argument was sound. But the governance process was perceived as tone-deaf. Dashjr and others argued loudly that the change crossed a red line — not for technical reasons but for structural ones. Bitcoin, they argued, had to remain a settlement layer for money, not a platform for applications. The Lightning Network became a focal point because Knots' restrictive policies, particularly around ephemeral anchors, make it harder for Lightning nodes to close channels efficiently. Knots by default filters ephemeral anchor transactions, meaning Lightning implementations would have to route around Knots nodes or pay higher fees to force closure on-chain through out-of-band channels like Marathon's Slipstream service. This is where the policy fork becomes operationally consequential: two nodes can both be validating the same blocks correctly while having fundamentally different ideas about which transactions deserve network propagation.

Knots benefits from ideological clarity and from Core's own contradictions. Dashjr's position is unambiguous: Bitcoin is money, not content. If you want to store data, use a different system. Core's position is harder to articulate because it is fundamentally neutral — we will relay what the consensus rules allow, and we will not impose our preferences on what you do with your transaction space. That neutrality is a virtue in theory and a liability in politics. As soon as Core made a choice about OP_RETURN — choosing efficiency over restriction — it became a target. Knots does not have to defend a complex engineering decision; it just has to say no. The miners and large pools do not particularly benefit from this schism because both implementations validate blocks identically, and miners can always use out-of-band channels to capture transaction flow regardless of what the majority of nodes relay. In fact, miners might slightly benefit from the OP_RETURN expansion because it creates new transaction types with fee-paying demand. The people who lose are node operators who want to run a tight, restrictive policy and Core users who suddenly face a fragmented network where one in four nodes has different relay standards. Lightning network efficiency suffers, though users can route around the problem.

Here is what is actually happening: Bitcoin is developing two mempool networks in practice, even though it has one blockchain in consensus. Knots nodes will reject and not relay certain transactions that Core nodes happily propagate. This is not a technical failure of either implementation — it is the inevitable result of two competing views of what Bitcoin should be. The real question is whether this is a healthy expression of governance through code, or the beginning of the fragmentation that Satoshi Nakamoto was trying to avoid. Dashjr's position has logical force: if Core becomes agnostic about all use cases, it ceases to have a thesis about Bitcoin's purpose. The problem is that Dashjr's position also requires that nearly everyone agrees with him, and 22.6% adoption is not consensus, it is schism. The Lightning Network issue will eventually force a reckoning because you cannot have two major implementations with fundamentally incompatible policies about Layer 2 settlement transactions and claim the network is still unified. Either Knots becomes marginal enough that Lightning can ignore it, or it becomes large enough that Lightning must route around it, or one side capitulates. Right now, the trajectory suggests this is not a temporary protest vote — it is a sustained migration toward a different vision of what Bitcoin infrastructure looks like.

Watch three things over the next six months. First, whether Knots adoption stabilizes at 22-25% or continues climbing past 30%. At 30%, you have genuine consensus fragmentation that miners and exchanges cannot ignore. Second, whether any major Lightning implementation creates explicit workarounds for Knots-incompatible transaction types, which would be a public admission that the network is operating with two different rule sets. Third, whether Luke Dashjr rebases Knots to v31 or continues allowing it to lag behind Core releases — that would signal whether he is maintaining a living alternative or a statement fork. If he rebases quickly, Knots becomes a serious long-term player. If he does not, it suggests the adoption surge is ideological momentum rather than sustainable technical infrastructure. The real test is whether anyone with enough economic leverage cares enough to force a resolution, or whether Bitcoin simply evolves into a protocol where different classes of nodes have different policies and everyone learns to live with it.