op_return.md

Caveat Emptor

I (instagibbs) was asked to draft a statement, I feel this is a fair summation of the project's direction. I might be wrong

Retiring the 80-Byte OP_RETURN Limit

Bitcoin Core’s next release will, by default, relay and mine transactions whose OP_RETURN outputs exceed 80 bytes and allow any number of these outputs. The long-standing cap, originally a gentle signal that block space should be used sparingly for non-payment proof of publication data, has outlived its utility. Readers who want the full policy history should consult Bitcoin Optech’s Waiting for Confirmation mempool series.

---

Why standardness policy exists

Consensus rules decide whether a transaction can ever be included in a block. Standardness rules (aka policy) implemented in Bitcoin Core’s relay code decide whether it is forwarded across the peer-to-peer network before it reaches a miner. Three considerations motivate those extra checks.

1. Denial-of-Service defence. Nodes decline transactions that waste CPU, RAM, or bandwidth disproportionate to their fee. E.g., quadratic hashing from legacy scripts.
2. Incentive alignment. Giving policy nudges towards wallet authors for fee-efficient yet UTXO-friendly constructions.
3. Upgrade safety. Unknown opcodes or version bits remain non-standard until activated by a soft fork, preventing premature use that could hamper future consensus changes.

Standardized OP_RETURN outputs embody that philosophy. Users were already embedding arbitrary data in spendable outputs, leaving toxic, unspendable entries in the UTXO set. OP_RETURN gave them a provably unspendable output that is not added to the UTXO set; the 80-byte ceiling that accompanied it was a soft deterrent: large enough for a hash or short commitment, too small for a photograph.

The 80-byte ceiling is now counter-productive

The modern transaction landscape has rendered the legacy cap ineffective and, in several ways, damaging.

Easily bypassed

A number of private mining accelerators simply do not enforce these limits, and other centralized services use alternative implementations to peer with these miners as well.

Large-data inscriptions are happening regardless and can be done in more or less abusive ways; the cap merely channels them into more opaque forms that cause damage to the network.

Perverse incentives

When the polite avenue is blocked, determined users turn to impolite ones. Some use bare multisig or craft fake output public keys that do enter the UTXO set, exactly the outcome OP_RETURN was invented to avoid.

---

Why not add new filters instead?

Some have proposed an aggressive blacklist against recognised data-embedding tricks. The project declined for both pragmatic and philosophical reasons. It does not stop the most basic forms of data embedding as mentioned before. There is no reliable pattern to detect “bad data”, resulting in a complex game of cat-and-mouse increasing negative externalities, and risks confiscation of user’s funds.

---

Practical impact on operators and wallets

Blocks remain limited to 4 million weight units; dust outputs are still rejected; signature-operation and ancestor/descendant caps still guard mempool growth. The withdrawal of the 80-byte rule yields in at least two tangible benefits:

• Cleaner UTXO set. Data now fits in a single, provably unspendable output rather than being disguised in spendable scripts or spread over multiple transactions.
• Consistent default behaviour. Nodes relay the same transactions miners want to see, making fee estimation and compact-block relay more reliable.

---

How the decision was reached

Three possible paths were considered:

1. Keep the cap. Rejected as ineffective and arbitrary.
2. Raise the cap. Still arbitrary; any figure likely to age poorly.
3. Delete the cap. Aligns default policy with actual network practice, minimises incentives for harmful workarounds, and simplifies the relay path.

Option 3 earned broad, though not perhaps unanimous, support. Dissenting parties remain free to modify software, run stricter policy, or propose new resource limits if empirical harm emerges.

---

Alignment with Bitcoin’s ethos

The change re-affirms that Bitcoin is governed by transparent, minimal rules rather than editorial preference. By retiring a deterrent that no longer deters, Bitcoin Core keeps the policy surface lean and lets the fee market arbitrate competing demands.

Should a future pattern demonstrably exhaust node resources, targeted protections will be considered as they have been for signature-checking limits, ancestor limits, and dust rules.

This is the largest mistake Core can make at this juncture. I want to be on the record saying that.

Might not be the largest, but it's up there.

As noted in my original (now locked from comment/votes) post on one of the PRs, this marks a fundamental shift in the direction of Bitcoin if this change is made and is widely adopted. I highly suggest folks read my original comment.

As the reference implementation, Bitcoin Core should be setting the standard for keeping Bitcoin on track. This change opposes that. Suggesting users make code changes and such to get around a change that the broader community appears to have clearly rejected puts the developers at odds with those users. Most users don't have the technical ability to do so, yet can understand the detrimental effects brought on by such a change.

Ignoring the community on things like this just undermines trust in the work done here.

Yes, alternative implementations exist. Is that the solution? Maybe. While some highly respected implantations exist and are very quickly gaining a ton of traction, like the Knots fork... the overall community dissent is going to open the door to less scrupulous forks claiming to solve this issue for users catfishing them into losing money. They'll want to act because this project lost its way, and end up in an even worse situation.

Anyway, a couple of key things can happen after this change:

Bitcoin continues down the "allow every non-Bitcoin use of Bitcoin" path, and the project inevitably fails like every other project that has attempted similar; or
Users realize this change is bad for the ecosystem and Bitcoin Core loses its status as the reference implementation.

The votes are pouring in for the latter at this point from the stats I'm seeing. I was hoping this project would come to its senses on this topic, but it seems that's just not happening. Motivations unclear.

Bitcoin is a decentralized currency. After this, s/is/was/g.

@murchandamus probably need a better term for it, but it's data that doesn't define the payment structure of the current transaction? It's a bit of one-hand clapping but I'm trying to cover things like the groth16 proof in citrea, 32-bytes of publication for ln-symmetry to reduce interactivity, HTLC-reveals which end up helping enforce transactions somewhere else not connected by the utxos themselves.

For everyone else, I'm going to start deleting comments going forward asserting that the Bitcoin Core project isn't in general accord unless you're an actual contributor at least; this is not attempting to sum up "the Bitcoin community" whatever that entails

Bitcoin is a decentralized currency. After this, s/is/was/g.

This will be the token cataclysmic response here. I will delete if there's more and start blocking.

@instagibbs: Maybe "data transactions", using the blockchain for data availability, or data beyond what’s necessary to facilitate payments? Either way, "consensus" seems a bit overloaded in the context. ;)

Even if maintainers in the repository have already reached consensus, why not let the dust settle before merging?

Pushing this through against substantial objections from so many people, will only erode trust. As an outsider, it looks like devs first unknowingly introduce a vulnerability with witness discounts, and are now playing catch up by ramming more code change as quickly as possible.

I can't stop this PR merging, and I will refrain from doing anything to bait outrage. But I am very concerned. Even if this turns out to be the correct technical path, the way it is being done is counterproductive. Just my 2 sats.

Looks sensible.

@50egtftz This is not a PR, nor is there a to-be-merged PR. Cheers

@wizkid057 I've carefully read your messages as wells as the other messages from your colleagues at ocean and I have failed to find any clear explanation of the harm we could expect to experience from removing this limit.

It's all well and true that NFT/shitcoin stuff is bad, but there is no reason to expect that this should increase that activity: Anything that can be done with op_return can be done just as well (for the data embedder) with 'fake addresses'. And fake addresses are both far worse for Bitcoin due to bloating the utxo set and are essentially impossible to block. Moreover, parties that want to bypass this limit at scale and particularly for abusive purposes have an easy avenue to do so by directly handing large miners the transactions, which is now a reliable method for getting transactions mined that violate policy.

You've argued that people may put illegal data in the blockchain-- but they already can and wouldn't have any additional ability to do so via this change, they'd do so by stuffing it in signatures where it uses up less block capacity and thus costs less fees. Already nodes 'encrypt' the blocks on disk to prevent this stuff turning up in scanning tools (or photorec) and of course bitcoin core doesn't provide any particular tools to access the data. I don't think more is possible, because one can encode the data to look as indistinguishable as they want-- and parties the spend well over two hundred million dollars on transaction fees for inscriptions over the last couple years are more than capable of hiring whatever technical talent they needed. But most importantly, again, none of that has anything to do with op_return outputs.

I've also found no counter to the benefits of removing the behavior: that at least some of the fake address traffic has indicated it will switch, that any discrepancy between what nodes relay and what miners mine hurts block propagation which advantages large miners at the expense of smaller miners, that direct-to-miner relationships also favor large operations over small, that an incomplete mempool reduces your ability to look at it and tell what price may will get your transactions in the next block, and that a fruitless game of wack-a-mole trying to block transactions creates a dangerously muddled message about the ability of Bitcoin participants to blacklist transactions/addresses such as those on state set blacklists. And of course, simpler code with fewer options and thus combinations of options to test.

So what am I missing here? Please do not respond with an offtopic rant about spam. I don't think anyone in this discussion likes NFTs/shitcoins/etc-- but these things are not relevant unless there is a reason that opreturn traffic would meaningfully increase them and I've yet to see one and think it unlikely you can produce one given the existing alternatives and the fact that bypassing is so easy for anyone willing to go direct to any one of several large miners.

@50egtftz news to me, I'm an author of one of them but it has zero review ACKs so I don't think so

@instagibbs Thank you for clarifying.

For the record, I am only commenting because this is not a PR, and I appreciate this summary, as well as GMaxwell's dialogue here, on Reddit and bitcointalks. I find the arguments compelling.

But there are also many other people, much smarter and technically competent than myself, who are loudly disagreeing. To any observer and non-techical noderunner, this should be a cause of concern, and caution.

@wizkid057 I've carefully read your messages
[snip]
So what am I missing here?

@gmaxwell We've both been around here for quite a while, and I've got nothing but a mountain of respect for you. In fact, you came up in conversation a couple of days ago as probably one of only a couple of people in this space I think could convince me I'm wrong on this, if somehow that were the case. I've read your notes as well, and I haven't been able to get there.

Right now, I believe that you (and many others) are simply failing to see the forest for the trees on this one for one reason or another. I'm pretty good at seeing around that particular corner, but I'm certainly NOT the best at articulating it in a resonating way. I hope you still have enough respect for me to not summarily dismiss my comments, despite that failing.

To avoid risk of getting banned from public discourse here further, I'd love to quickly catch up a bit offline (been a while!), and maybe try to clarify this a bit further, away from the pitchforks. Will either of us persuade the other? No idea. But contact info you have for me should still be up-to-date, and I welcome the chat.

@wizkid057: I’ve spent several hours answering over 30 questions about the debate on Stacker News in case you are looking for more food for thought.

This gist is already shared in a coindesk article: https://www.coindesk.com/tech/2025/05/06/bitcoin-developers-plan-op_return-removal-in-next-release

Does anyone have a list of projects that have announced a switch to OP_RETURN outputs if the policy was removed?

As far as I'm aware, the main offender (Stamps protocol) has no intention of updating its mechanisms.

And to my knowledge, Citrea is the only project that may switch to OP_RETURN outputs. But in their own words, occurrences of such transactions per year will be very rare thus it won't make any noticeable difference in practice.

Without more projects willing to switch to this new option, the benefits/risks ratio of this PR seems very low.

KISS: This will be a mistake, not only for end users, but the same end users who generously contribute their hard drive space to run nodes. This would only benefit those looking to profit for their 'Silicon Valley-bro' startups. This decision benefits nobody, it increases costs to the user, and, if it catches wind and becomes a bigger issue, it congests the mempool, pushing back otherwise important financial transactions.

Why not add new filters instead?

The quoted section is underdeveloped in contrast to the other sections. A phrase like "negative externalities" is too generic, while "risks confiscation of user’s funds" is straight to the point but lacks clarity on how confiscation can arise.

Bitcoin OP_RETURN Controversy: Complete Summary

Probably the worst idea ever. By combining the comments from two separate people:

Moreover, parties that want to bypass this limit at scale and particularly for abusive purposes have an easy avenue to do so by directly handing large miners the transactions, which is now a reliable method for getting transactions mined that violate policy.

[...] the option does very little besides increase your bandwidth usage and slow block propagation if you set it lower than the default.

Instead of focusing so much on the abusive users, why not punish the miner (or mining pool) who included the naughty transactions by slowing the propagation of their block and helping them lose the mining competition? They clearly state in their block that they want very much to lose, right?
We still respect the longest chain, but why should we spread around the top block if it's naughty?

Large-data inscriptions are happening regardless and can be done in more or less abusive ways; the cap merely channels them into more opaque forms that cause damage to the network.

I think this sentence is inaccurate.

Technically speaking, "inscriptions" refer specifically to the OP_FALSE OP_IF "ord" … OP_ENDIF envelope construction embedded in a tapscript, and are not a generic term for "big data put anywhere in a transaction". So they can only be made in one way, which is not particularly abusive. Stamps, for example, which embed data in fake outputs, are not inscriptions.

why not punish the miner (or mining pool) who included the naughty transactions by slowing the propagation of their block and helping them lose the mining competition?

Slow propagation of blocks only punishes small miners and helps larger miners, regardless of who created the block.

For small miners, slow block propagation means that the rest of the network will remain on the previous block for longer, giving a bigger change that someone else will find a competing block and cause the small miner's block to become stale. Larger miners have a higher probability of finding the competing block, and in general of finding another block on top of it, which means that the larger miner benefits.

For large miners, the effect is essentially an accidental selfish mining attack. The large miner will be ahead of everyone else while their block propagates slowly. Since they are large, they have a higher chance of finding another block on top of theirs, while the rest of the network needs to find a block that competes and another block on top to make the large miner's block(s) stale. The effect is also that large miners benefit.

@achow101 Thank you for the clarifications. I'd like to follow up on your comment. Maybe you can clarify this, too:

I don't see all outcomes as bad.

The small miners know the propagation filters in advance. If they still choose to produce a block, knowing it will be slowed down, then it's their fault for losing. No one stopped them from following the propagation filters. They lost, so the filter worked as intended.
Any other small miners who respected the filter got a boost in comparison with the ones who did not respect the filter.
In such an event, the forfeited share of bitcoin rewards might move toward the large miners. I'm fine with this outcome. The large miners did nothing wrong, and the rewards were initially heading to a bad actor.

The outcome of large miners producing bad blocks is bad. But it will always be bad (with or without the propagation delay). If large miners see an edge when using slow blocks, they do not need the filter to slow their blocks. They will publish them as slowly as they want.

I don't see all outcomes as bad.

It leads to further miner centralization.

Large mining pools are essentially free to produce "bad" blocks as much as they want. So they can accept nonstandard transactions that pay them fees, but the small pools can't because they'll lose the propagation race. This means that in proportion to the rest of the network, large pools are able to collect more fees and therefore pay out more to the hashers. Since hashers are only motivated by more profits, they will tend to mine with the pool that pays them more. This means that small pools lose hashrate to the large pools as those large pools can pay out more than the small ones. Over time, this leads to further mining centralization around the large pools.

Conversely, if the nonstandard txs were accepted by all pools, then the proportional fee revenue would be about the same for all pools, removing this incentive for the hashrate to switch pools. The small pools would not lose hashrate to the large pools because they are paying their hashers about the same that they would get at a large pool.

It's not really a matter of opinion "I nudge you": nudge is a verb "I give you a nudge": nudge is a noun

…

On Mon, May 5, 2025, 2:26 p.m. Andrew Toth ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ But how do you give a policy-nudge towards a wallet author for something? I think it is still a verb because you give the policy a nudge

Bitcoin is a state machine (Doo-dah!, doo-dah!)

Allowing more data in OP_RETURN opens up huge opportunities for metaprotocols to encode instructions for parsers to consume, and it can be pruned. Everybody wins.

Oh, doo-dah-day!

as much as i like to have data on chain, 1) not at L1 2) why removing option to chose?

the proponents have obviously ulterior motives. removing options is a literal “screw you public”. if BTC was private, absolutely within their rights. but BTC is a public protocol and by virtue of its value, it’s public property.

thankfully there are other nodes like btcd snd knots.

This was the obvious choice.
Blockspace should be allocated by the free market - not a committee choosing which transaction types are "right."

Bitcoin is a state machine (Doo-dah!, doo-dah!)

Allowing more data in OP_RETURN opens up huge opportunities for metaprotocols to encode instructions for parsers to consume, and it can be pruned. Everybody wins.

Oh, doo-dah-day!

Exactly.

It's not really a matter of opinion

"I nudge you": nudge is a verb
"I give you a nudge": nudge is a noun

Of course you are correct, my mistake.

Hey all — just a friendly clarification that might help ease some concerns:

This change to remove the 80-byte OP_RETURN limit is a policy change, not a consensus change. That means:

• The 4MB block size limit stays exactly the same
• No full node will reject valid blocks because of this
• Nodes like Bitcoin Knots or btcd can still enforce stricter policies if users prefer

Why remove the limit at all? Because it was already being bypassed via worse methods like fake outputs or direct-to-miner submission — which causes more harm (especially UTXO bloat). In contrast, OP_RETURN is provably unspendable and prunable.

This isn't about turning Bitcoin into a data chain — it's about minimizing harm, improving relay consistency, and reducing centralization pressure from mining pools with special access.

If you want conservative defaults, you're free to run software that enforces them. Bitcoin remains a system of voluntary rules — and that’s exactly what makes it strong.

More on that:

• Bitcoin OP_RETURN Controversy: Complete Summary

From a Bitcoin L2's perspective, removing this limit is helpful. it allows us to use Bitcoin as a Data Availability option (though its not practical).

In the future, I think a trade-off can be made like this: Import a temporary storage/cache design on OP_RETURN, miners can change it with a cheaper price, and remove the data when it expires.