The most important Bitcoin upgrade in four years since Taproot
TechFlow Selected TechFlow Selected
The most important Bitcoin upgrade in four years since Taproot
Removing OP_RETURN Limits: Should a "Wall" That Can Be Circumvented Be Torn Down?
Navigating Web3 tides with focused insightsBy: Jaleel Jia Liu
Recently, there's been a heated debate online about a proposal to remove restrictions on OP_RETURN—a suggestion put forward by Bitcoin Core OG developer Peter Todd.
(Notably, HBO once claimed in its heavily promoted documentary "Money Electric: The Bitcoin Mystery" that Peter Todd was Satoshi Nakamoto, leading him to receive numerous funding requests and threats, forcing him into hiding.)
Although the community has voiced significant skepticism regarding this change to OP_RETURN, according to an announcement made by Bitcoin developer and Blockstream core contributor Greg Sanders (nicknamed "instagibbs") on GitHub on May 5, Bitcoin Core will no longer impose any byte or quantity limits on OP_RETURN in the next network upgrade.
What Exactly Is OP_RETURN?
We all know that Bitcoin is an immutable ledger, where every transaction is like writing a line of record onto it.
OP_RETURN works like attaching a "sticky note" on the edge of a page—you can write dozens of characters or small data segments. This note is marked by the system as "read-only," meaning others cannot spend it as money nor does it affect other monetary records on the ledger.
The reason for having such a "note" function is that sometimes people want to permanently anchor extra information—such as legal proofs, short messages, anniversaries, or even love confessions—onto the chain, without occupying UTXO space reserved for tradable Bitcoin. With OP_RETURN, this information is discarded like scrap paper into a drawer—nodes keep traces but don't store them long-term, keeping the chain’s “available funds” clean and tidy.
In the past, to prevent users from flooding the network with lengthy “notes,” Bitcoin Core defaulted to allowing only one OP_RETURN per transaction, storing up to 80 bytes; transactions exceeding this limit would be rejected by nodes and not relayed or included in blocks.
Now, both the 80-byte cap and single-entry restriction are gone—you can write as much as you want, include multiple notes, and nodes will automatically relay them while miners are willing to include them.
But in reality, people have long been bypassing the 80-byte limit.
Even when OP_RETURN had limitations, methods existed to circumvent the 80-byte cap. No matter how strict filtering and relaying policies became, determined users could still write data onto Bitcoin. Ultimately, only miners and transaction fees decide which transactions make it onto the chain. By offering higher rewards, miners naturally prefer including more transactions—the game doesn’t change based on node policies.
For example, Taproot Wizard NFT project Wizz famously packed a nearly 4MB image into a single block. Similarly, earlier Ordinals inscriptions and Runes used various “workarounds” to bypass restrictions, some even embedding data into spendable outputs, consuming even more resources.
Is This More Aligned With Bitcoin's Spirit?
According to announcements by Bitcoin developer Greg Sanders and supporting opinions from other developers, Bitcoin Core has always maintained a “standardness policy” during transaction relay to serve three purposes before transactions reach miners: first, preventing denial-of-service attacks by rejecting transactions whose computational, memory, or bandwidth costs far exceed their fees; second, guiding wallet developers to construct fee-efficient transactions that avoid creating redundant UTXOs; third, preserving upgrade safety—treating unknown opcodes or version bits as “non-standard” until activated via soft fork.
The OP_RETURN mechanism and its 80-byte limit emerged from this philosophy: providing users with provably unspendable outputs allows storage of small commitments or hashes while ensuring nodes exclude them from UTXO sets, thus avoiding worthless garbage outputs cluttering the chain.
However, this soft limit has now become obsolete. On one hand, private mining pools and centralized services often ignore this rule entirely—anyone wanting to write large amounts of data can bypass it either by directly paying miners or hiding information within bare-multisig, fake public keys, or even spendable scripts, getting their content onto the chain regardless. On the other hand, continuously adding new blacklist filters only leads to a cat-and-mouse game, failing to stop basic data writing while increasing risks of accidentally blocking legitimate user funds.
Supporters argue that completely removing the 80-byte limit brings two practical benefits: first, cleaner UTXO sets, since data is clearly placed into explicitly unspendable OP_RETURN outputs instead of being scattered across complex scripts or multiple transactions; second, greater consistency between what nodes choose to relay and what miners actually include, making wallet fee estimation and compact block relay more reliable.
Bitcoin developers compared three options, with the current “removal” approach gaining the most support in the community. More importantly, they believe eliminating the OP_RETURN limit best embodies Bitcoin’s spirit of “transparency and simplicity.” When a policy no longer serves its purpose yet remains enforced, it merely adds complexity and friction. Removing it makes node software lighter and purer, allowing every transaction’s propagation and inclusion to proceed without detours—miners simply prioritize based on fee rates, letting the fee market naturally regulate competing demands.
And if excessive on-chain writing ever threatens resource consumption, the Bitcoin ecosystem already possesses a proven set of targeted protections: signature operation limits, ancestor/descendant transaction caps, dust rules… These precise tools combat specific abuse cases far more flexibly than a blunt “80-byte” cutoff, effectively safeguarding nodes and users without hindering normal usage.
Will BTC Become a Shitcoin?
The most prominent opponent is likely Luke Dashjr.
As a Bitcoin OG who previously stated “the Ordinals protocol is an attack on Bitcoin” and called inscriptions “spam, a bug, fixable,” Luke Dashjr has long been an outspoken critic of the Ordinals protocol.
This time, he again firmly stands on the “conservative” side, viewing the removal of OP_RETURN limits as extremely reckless—an attack on Bitcoin. He and others fear it will lead to spam floods and higher transaction fees.
Clearly, the current debate centers on whether lifting the 80-byte OP_RETURN restriction increases transparency and simplifies Bitcoin’s data use, or opens the door to abuse, spam, and shifts Bitcoin away from its financial focus.
Jason, VP at Ocean Mining Pool, is among the harshest critics—he lost sleep over it, bluntly stating: “This change will turn Bitcoin into a worthless shitcoin.”
Willem Schroe, founder of Botanix Labs, believes developers should treat Bitcoin as a monetary system, not a data storage platform. Another core Bitcoin developer, Mechanic, shares a similar view: Bitcoin should not be used for arbitrary file storage, and all possible measures should be taken to ensure that remains true.
Some influential industry KOLs, such as Samson Mow, are encouraging node operators not to upgrade their Bitcoin Core versions—or switch to Knots instead.
At the time of writing, according to Clark Mood’s data, Bitcoin Knots nodes have surpassed the latest version of Bitcoin Core in usage.
Once again, Bitcoin faces a test of consensus, just as it has many times before. Yet this also reminds us that although Bitcoin is more conservative than most networks, it isn’t static. After the next upgrade, we may witness even cleaner and more elegant protocol innovations beyond Ordinals, Atomicals, and Runes.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
BlockBeats
