The script, published to GitHub on May 24, enacts a year-long setban
on all /Satoshi:Knots/
user agents.
Its share of reachable nodes doubled over several weeks in May and has continued climbing through June, coinciding with vocal criticism of the change from its lead maintainer, Luke Dashjr, who described the removal of the cap as “utter insanity.”
While OP_RETURN is not consensus-critical, node-level policy decisions shape transaction propagation and mempool filtering, which in turn influence what miners include in blocks and which data-bearing transactions reach the network at all.
The dispute’s origins date back to Bitcoin Core’s original enforcement of an 80-byte OP_RETURN limit in 2014. Initially, a tool to enable data inscriptions like notary hashes or token metadata, the OP_RETURN field became a spam vector during peak usage periods.
Because the OP_RETURN cap is enforced at the policy level, node operators can adopt or reject the change individually. This dynamic has elevated the role of miners and relay infrastructure operators, who ultimately decide which transactions make it into candidate blocks.
If a critical mass of top pools sides with Knots, blocks filled with larger OP_RETURN data may fail to propagate efficiently, creating a de facto veto. Conversely, if Core’s defaults dominate, alternative policies could become siloed and economically irrelevant.
The broader implications may extend to Bitcoin’s ability to accommodate divergent policy views without splintering its operational cohesion.
Unlike 2017’s block size debates, the OP_RETURN split does not require incompatible consensus rules. Still, the threat of a partitioned network looms, especially if coordinated peer bans become widespread. While block propagation across the two camps may remain functional, transaction relay pathways could fracture, impacting fee markets, data services, and blockchain analytics.
Since May, the number of Bitcoin Knots nodes has continued to climb, reaching 2,938 as of June 24, the highest on record and accounting for just over 13 percent of reachable peers. The original ban script remains live, and at least one new tool, btc-magic-guard, has emerged offering iptables-based filtering to isolate nodes running policy-divergent clients.
Meanwhile, a follow-up proposal to allow multiple OP_RETURN outputs per transaction was recently withdrawn after pushback, suggesting Core maintainers are unlikely to revisit or narrow the merged policy before v30 ships.
For now, the network remains unified under shared consensus rules, but the unresolved divergence in relay behavior, peer connectivity, and node policy has made soft partitioning a tangible scenario ahead of the October release.