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.
Acknowledging two years of failed attempts to limit arbitrary data storage that some consider spam, Peter Todd created a pull request (PR) number 32359 that would lift arbitrary limits on datacarrier outputs via Bitcoin’s “OP_Return” operation code.
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.
Spam workarounds for years
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.
Read more: Bitcoin ordinals pump and dump using stolen images and copyright
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.
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.
