Bitcoin core developers have merged a proposal to remove the default 83-byte limit on OP_RETURN data in the v30 version planned for release in October, increasing the new limit to 100,000 bytes. This move will relax the restrictions on embedding data within transactions, with actual constraints coming from transaction size and block size limits. The change aims to simplify on-chain data embedding, promote more decentralized data publishing, and reduce incentives for directly submitting transactions to miners. Although this policy adjustment has sparked intense debate and governance disputes within the community, it is only an adjustment to the mempool relay policy and not a consensus-layer change; users can choose other implementations. Supporters argue this aligns with miners' actual behavior, while opponents worry it may lead to an increase in junk data and network burden. Thirty-one core developers publicly support not filtering non-standard transactions, emphasizing Bitcoin's nature as a censorship-resistant system. The change was proposed by Greg Sanders and others, and merged by Gloria Zhao. Community reactions are sharply divided, involving discussions on decentralization, network health, and governance transparency.

Bitcoin Core developers have merged a pull request to remove the long-standing 83-byte default limit for OP_RETURN data, with the mempool policy change set to take effect in the implementation's v30 release, scheduled for October.Bitcoin Core is the reference implementation of the Bitcoin protocol, maintained by an open-source community of developers and widely used to run full nodes on the network. The new 100,000-byte limit will effectively uncap the amount of data that can be embedded in a transaction using OP_RETURN, with practical constraints now coming from the standard transaction size limit (approximately 400 KB) or the block size limit (4 MB weight). However, the old limits can still be manually enforced using the "-datacarriersize" option, which remains usable but is now deprecated, with no set timeline for removal.The change simplifies onchain data embedding and could expand inscription-like use cases, though it's distinct from existing Ordinals, which use witness data — a portion of Bitcoin transaction data introduced by the SegWit upgrade in 2017 and later made more flexible with the Taproot upgrade in 2021. The OP_RETURN limit was initially introduced in 2014 to curb spam and bloat. However, critics argue it's now ineffective, as users can bypass it by avoiding the mempool and sending transactions directly to miners — raising centralization concerns. Advocates of the policy change say it simply aligns Bitcoin Core's defaults with actual miner behavior, making data embedding more permissionless by reducing incentives for direct miner dealmaking and promoting more decentralized, mempool-based data publishing.However, the proposal has caused controversy over Bitcoin Core's governance, communication, and moderation practices, with some dissenters being banned for spamming GitHub. Ultimately, it's a mempool relay policy adjustment — not a consensus change — and users can opt for alternative Bitcoin implementations such as Bitcoin Knots if they prefer different rules.The originally proposed changes were authored by Greg Sanders, with contributions from others, including Peter Todd. In May, the plan to remove the OP_RETURN limit sparked fierce debate within the Bitcoin community. Proponents argued the restriction had outlived its usefulness and that lifting the cap would encourage less harmful onchain behavior by shifting users away from unprunable data techniques. Opponents said the proposal lacked consensus and could incentivize spam, with some critics even labeling it "coercive."The developers initially considered three options: keep the cap, raise it, or remove it entirely. The first two were deemed arbitrary and ineffective, while the third option garnered broad — though not unanimous — support, according to the GitHub discussion.Weighing the arguments for and against the change, Bitcoin Core developer and Chaincode Labs software engineer Gloria Zhao, who merged the pull request, said on Monday that the update corrects a misalignment between the cost and standardness of different data storage methods. She noted that the existing cap pushed users toward more harmful, unprunable alternatives or direct miner submission, both of which undermine decentralization and mempool utility. Zhao also addressed concerns about spam and network harm, arguing that OP_RETURN outputs are prunable, relatively costly, and do not burden validation or the UTXO set, making them a less damaging option. The broader aim, she said, is to avoid centralizing trends, support permissionless use of blockspace, and ensure Bitcoin Core policy reflects what miners already accept.Many in the Bitcoin community, including Casa Chief Security Officer Jameson Lopp, Spiral developer Ben Carman, and Galaxy Head of Research Alex Thorn, praised the decision. "Bitcoin Core just sent a message: Personal attacks and Sybil attacks are ineffective. Meritocracy or bust!" Lopp said.However, the change continues to have its detractors, including Bitcoin Core developer, Knots maintainer, and Ocean mining pool CTO Luke Dashjr, who previously argued that allowing more spam is an abuse of the network."OP_RETURN outputs greater than 83 bytes will increase significantly, UTXO bloat will keep getting worse, and there will be more garbage onchain. This is going to age like a bad tattoo," Bitcoin educator and former Core contributor Jimmy Song said. "I would encourage anyone running Bitcoin Core to do their own research on this one before upgrading when released. The horrible precedent it sets and the combined risk of a centralized Core and centralized mining pools create an untenable situation," Bitcoin author Parker Lewis added.Ahead of the merge, in an open letter on Friday, 31 Bitcoin Core developers argued against filtering out non-standard transactions, stating that it would go against Bitcoin's nature as a censorship-resistant system. "This is not endorsing or condoning non-financial data usage, but accepting that as a censorship-resistant system, Bitcoin can and will be used for use cases not everyone agrees on," the developers wrote."Bitcoin Core devs have been changing the network gradually to enable spam, and now seem focused on also removing barriers for spammers. It's disingenuous to just say 'it is what it is now, too bad,'" Jan3 founder Samson Mow replied.

Bitcoin Core Developers Plan to Remove OP_RETURN Data Limit, Sparking Intense Community Debate