Bitcoin (BTC) Developers Remove Data Size Limit From OP_Return Operation Code to Enable Inscription and Ordinal Pumping

Exhausted after years of ineffective attempts to prevent non-financial (“arbitrary”) storage on Bitcoin’s blockchain, developers are asking Bitcoin Core maintainers to pull a code change into production that would remove a data size limit.

Bitcoin (BTC) developers are discussing a code change to remove a data size limit, following years of ineffective attempts to prevent non-financial (“arbitrary”) storage on the blockchain.

Peter Todd created a pull request (PR) no 32359 that would lift arbitrary limits on datacarrier outputs via Bitcoin’s “OP_Return” operation code, acknowledging two years of failed attempts.

If Core maintainers pull the change into production via the main repository, Bitcoin node operators like miners would be able to publish more bytes of data via OP_Return outputs.

According to Todd’s formalization of the proposal by Chaincode Labs’ Antoine Poinsot, for any developers who think the 83-byte limit on OP_Return’s scriptPubKey is silly, they should test the code changes and consider whether they agree with lifting the limit.

Although the attempt to disincentivize datacarrier data use was mildly effective, many developers note that people can still store media, spam, and otherwise arbitrary data via non-OP-Return places like scriptsigs and unspendable outputs.

Moreover, some users were simply bypassing scriptPubKey’s 83-byte limit altogether by privately broadcasting transactions to miner mempools like MARA Slipstream or non-mainstream nodes like Libre Relay, whose operators never even bothered enforcing that limit.

Poinsot cited users storing data on unspendable Taproot outputs as another example of the many workarounds to store arbitrary data on Bitcoin’s blockchain.

Reactions

Overall, developers posted mixed reactions to Bitcoin Core’s mailing list. Some developers sympathized with the ineffectiveness of limiting OP_Return when alternative data storage options were plentiful.

On the other hand, Luke Dashjr, a staunch critic of OP_Return arbitrary data storage and its uses — such as Inscriptions and Ordinals — criticized the idea as “utter insanity.” Others joined him with upvotes and supportive comments.

“The bugs should be fixed, not the abuse embraced,” he exclaimed in his typical style. A fervent defender of Bitcoin’s limited blockspace for financial purposes, he noted over two years of “attacks” by arbitrary data “spammers,” claiming that “the damage it has already done should be more than enough to prove the hands-off attitude is not viable. Am I the only one left on this list who actually cares about Bitcoin’s survival?”

Many agreed with him. Others saw the limitation as pointless.

OP_RETURN WARSEPISODE IV: NIXTHEFILTERShttps://t.co/IJxyZc87dI

New reviews by developers were arriving by the hour via the mailing list thread and GitHub.

Some upvoted with a simple “concept ACK,” supportive lingo for ‘concept acknowledged,’ while falling short of a full technical test. Others posted “concept NACK” in non-acknowledgement of its conceptual merits.Got a tip? Send us an email securely via Protos Leaks.

For more informed news, follow us on X, Bluesky, and Google News, or subscribe to our YouTube channel.