583 Bitcoin Nodes Rally Behind Proposal to Temporarily Cap Transaction Data Gains

Bitcoin's governance engine just got a jolt of high-octane debate. A controversial proposal to put temporary brakes on transaction data scaling is gaining serious network traction.

The Node Consensus Shift

Forget abstract whitepaper theory—this is on-chain reality. Support is crystallizing not in forum posts, but in the cold, hard consensus of 583 independent nodes signaling readiness. That's a bloc that commands attention, representing a tangible slice of the network's decentralized will. It's a number that shifts the conversation from 'if' to 'when and how.'

Scaling's Double-Edged Sword

The core tension is classic crypto: growth versus stability. Unchecked transaction data growth supercharges throughput but risks bloating the chain—potentially pricing out the very users decentralization aims to protect. This proposal isn't about stopping progress; it's a tactical pause, a deliberate circuit-breaker to let infrastructure and security audits catch up with innovation's breakneck pace. Think of it as a strategic regroup, not a retreat.

The Governance Litmus Test

This move throws a stark spotlight on Bitcoin's evolutionary mechanics. Can a system famed for its immutability execute a nimble, temporary adjustment? The 583 nodes in favor are betting it can, framing the cap not as a limitation, but as a responsible stewardship tool. The counter-argument, of course, is that any cap smells like the central planning Bitcoin was born to destroy—a familiar ghost of traditional finance wearing a digital mask.

The market's watching, half-expecting the usual circus of think-pieces and influencer hot takes. But beneath the noise, a quieter, more significant process is unfolding: the network itself, node by node, is stress-testing its own upgrade pathways. The final tally will reveal less about a single feature and more about Bitcoin's maturity—its ability to self-correct without a CEO's memo or a regulator's decree. Sometimes, the smartest move in a bull market is knowing when to gently tap the brakes.

BIP-110 Proposes One-Year Cap on Bitcoin Transaction Data

BIP-110 proposes a temporary soft fork that WOULD reintroduce strict limits on transaction data at the consensus level.

Specifically, it caps transaction output sizes at 34 bytes and restricts OP_RETURN data, a script used to embed arbitrary information into transactions, to 83 bytes.

The soft fork is designed to last for one year, after which the limits could be extended, modified or allowed to expire.

The proposal emerged in response to changes introduced in Bitcoin Core version 30, released in October 2025.

That update removed the long-standing 83-byte limit on OP_RETURN data following a pull request first introduced earlier in the year.

The MOVE was controversial and met with widespread criticism from parts of the Bitcoin community, which argued the change was made without sufficient consensus.

OP_RETURN has long been a flashpoint in Bitcoin governance debates. While it enables use cases such as timestamping and metadata anchoring, critics say uncapped data fields encourage blockchain spam and non-financial use of block space.

Larger data payloads increase storage and bandwidth requirements for nodes, raising concerns that running a full node could become cost-prohibitive for everyday users.

BIP-110 RC3pic.twitter.com/5KeoTCyhWV

Critics of the CORE update argue that higher hardware demands risk undermining one of Bitcoin’s defining features, which is the ability for individuals to verify the network using consumer-grade hardware.

As node operation becomes more expensive, they warn, the network could drift toward greater centralization.

Bitcoin educator Matthew Kratter compared unchecked data usage to a parasitic threat. He has argued that excessive spam could overwhelm the network’s underlying structure, weakening Bitcoin’s resilience over time.

BIP-110 Backers Frame Proposal as Temporary Fix

Supporters of BIP-110 see the proposal as a corrective measure rather than a permanent policy shift.

By making the soft fork explicitly temporary, its authors aim to give the network time to assess the impact of restored limits without locking Bitcoin into a long-term rule change.

Others remain unconvinced. Bitcoin Core contributor Jameson Lopp has defended the removal of OP_RETURN limits, arguing that artificial caps do little to deter spam and may instead push unwanted activity into other parts of the protocol.

From this view, market fees should determine how block space is used.