[BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies

[Majorian]

Dear Bitcoin Development Mailing List,

I hope this email finds you well. I am Majorian, and I've been active in the bitcoin space since 2017. 

I'm not a programmer or technical expert by any means; I'm just someone who has seen Bitcoin evolve over the years and wants to see it thrive without unnecessary division.

I'm writing today to propose a simple compromise that I believe could help bridge the gap between the various sides in the ongoing controversies in the Bitcoin community following Core 30's release.

As many of you know, these debates have created a rift in the community. My proposal isn't aimed at fully solving broader issues—that's a bigger challenge requiring more comprehensive solutions. Instead, it seeks to return Bitcoin to the de facto operational state it has maintained for over a decade, where OP_RETURN has been used sparingly and responsibly for metadata. The core goal is to codify at the consensus level the historical node relay norms that have guided Bitcoin's operation effectively for years, elevating these longstanding practices from policy to enforceable rules to ensure consistency and stability across the network.The Proposal: OP_RETURN Cap Soft ForkI suggest a backwards-compatible soft fork that introduces the following consensus rules:

• Cap OP_RETURN data size at 83 bytes: This aligns closely with historical norms (e.g., the 80-byte standard relay policy) This means that OP_RETURN can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes for the data push, and 80 bytes of data. By enforcing this at consensus, we simply make permanent the relay standards that nodes have followed in practice for much of Bitcoin's history.
• Limit to 1 OP_RETURN output per transaction: This ensures transactions adhere to traditional patterns, reducing potential abuse without disrupting standard usage.

This approach codifies the proven, historical relay policies into consensus rules, preserving Bitcoin's operational heritage.Why This Compromise?

• Simplicity: The rules are straightforward to implement and verify, with minimal code changes required.
• Bridging the Divide: It addresses concerns of new attack vectors by tightening OP_RETURN usage to match historical norms, while being agnostic on 'spam.'
• Apolitical and Restorative: This proposal is deliberately apolitical, aiming simply to return Bitcoin to the state it was in roughly a few weeks ago, before recent debates intensified. It takes no sides regarding specific implementations like Core, Knots, or others. While large OP_RETURNs have been possible at the consensus level for a long time, they've seldom been used in this manner until very recently. By capping them, we principally address concerns about OP_RETURN being used as an attack vector on Bitcoin, codifying the relay norms that have kept such usage in check.
• Plausible Deniability: Enforcing these limits provides plausible deniability, declaring firmly that Bitcoin is not designed or intended as a peer-to-peer file sharing and storage protocol in the context of OP_RETURN. This might be somewhat controversial, but I am including this anyway.
• Community Healing: By focusing on a modest, consensus-building change, we can hopefully repair the current rift and refocus on bitcoin's future.

If this idea gains traction on the list, I'd love to see it formalized as a Bitcoin Improvement Proposal (BIP). I'm not equipped to write the code myself, but I can contribute to the discussion and help rally community support. What do you all think? Is this a viable middle ground? Are there technical pitfalls I'm missing? Feedback from experts like you would be invaluable. 

Thank you for your time and dedication to Bitcoin.

Best regards,
Majorian

[Martin Habovštiak]

Hi,

Since you seem to be respectful, I decided to reply to you. Unfortunately, doing this would make things worse by forcing data longer than 83B to go into unspendable outs - that means it'd be never possible to remove them, including in case of pruned nodes.

If the contiguous data argument was valid then restricting it to something like 200B would make some sense, but even that is invalid for several reasons. 

I hope you find this message helpful. 

Martin

Dňa ut 28. 10. 2025, 17:09 Majorian <major...@gmail.com> napísal(a):

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f513d0af-90d1-43ee-ac8e-df55760674dan%40googlegroups.com.

[Erik Aronesty]

OP_RETURN is strictly better than any other mechanism for spamming the chain.   Why would I, as a node runner, prefer spammers to waste UTXOs when OP_RETURN would suffice?   Nearly half the UTXOs are now spam, and this is the main expense for running a node.

Lets look at root causes for this problem, 

 - Block space is cheap, allowing for trivial wastes of space

 - OP_RETURN doesn't relay well over 83 bytes, so its easier for me to spam with OP_PUSH (inscriptions)

If we're seriously considering a soft fork for spam, lets consider a block size reduction coupled with UTXO-sharing opcodes, like CTV.

 - UTXO sharing is good for node runners and decentralization

 - Smaller blocks are good for node runners and decentralization

 - Smaller blocks make Bitcoin strictly less useful for spammers 
 - UTXO sharing doesn't help spammers at all

 - If spammers want to store data somewhere else and use Bitcoin to represent ownership, there's nothing we can do to stop them.   But at least this gets the spam off the chain.

--

[Russell O'Connor]

This proposal isn't a compromise at all.

The entire problem was kicked off by noting that there exist some protocols that require the revealing of data that is somewhat longer than 80 bytes long (on the order of hundreds of bytes if I recall correctly).  If we cap the OP_RETURN outputs to 80 bytes and 1 per transaction, the folks using these protocols will simply have no choice but to instead place their data for publication into bare multisig outputs.  This outcome would be objectively worse for everyone involved.  The protocol users will have to pay someone higher fees.  Everyone's UTXO sets will be bloated with these unspendable transactions, and, unlike with OP_RETURN, there will be no way to decide which bare multisigs are being used as a poor man's bulletin board, and which ones are legitimate.

In fact, any attempt to cap OP_RETURN outputs will force those users to use bare multisigs instead, or perhaps use non OP_RETURN methods, such as OP_O OP_VERIFY, or whatever, which would be just worse for everyone involved.

Bitcoin Core 30 is *fixing* an existing problem, and trying to roll things back would unsolve the problem.  In fact, such a softfork would make the problem much worse by transforming a block reconstruction problem into a deliberate push towards having user who need to publish data into using uncensorable bare multisig outputs instead.

--

[TokyoBitcoiner]

Questions reacting to text in reply of Russell O'Connor:

• " there exist some protocols that require": 
  • Which protocols? 
  • Why does bitcoin need to cater to their needs? 
  • Do we cater to any protocol that comes along?
    • How do we choose which to enable, and which to discourage?
• "the folks using these protocols will simply have no choice": 
  • Did we force them to use bitcoin for their project? 
  • It sounds like "if you don't change the code to enable my project, I will be forced to trash your project." Is this wrong?
• "any attempt to cap OP_RETURN outputs will force those users": 
  • Again, force is a form of coercion. Is the bitcoin code with it's current setting forcing anyone to do anything? 
  • Are the external protocol designers the victims here?
• "Bitcoin Core 30 is *fixing* an existing problem": 
  • What problem? 
  • Is the bitcoin code responsible for fulfilling the needs of an external project or protocol? 
    • If yes, why?

I hope you will take these questions seriously. I really want to understand your thinking.

[Russell O'Connor]

On Wed, Oct 29, 2025 at 5:45 AM TokyoBitcoiner <arthu...@gmail.com> wrote:

Questions reacting to text in reply of Russell O'Connor:

• " there exist some protocols that require": 
  • Which protocols?

Citrea’s Clementine bridge, which needs 144 bytes for zk-proofs.  I don't know anything about their protocol beyond that.

 

• • Why does bitcoin need to cater to their needs? 

If we don't support these in OP_RETURNs, Citrea, and other folks like them, will use something like bare multisigs instead, which will be a little more expensive for them and much more expensive for every other Bitcoin node operator on the planet because those (likely) unspendable UTXO will have to remain in the UTXO set forever because they will be indistinguishable from legitimate bare multisigs.

• • Do we cater to any protocol that comes along?
    • How do we choose which to enable, and which to discourage?

Clamping down on OP_RETURNs won't discourage the use of these Citrea-like protocols.  Instead it will encourage them to instead use uncensorable publication channels such as bare multisigs, which will bloat the UTXO set and drive up costs for every Bitcoin node operator on the planet. 

• "the folks using these protocols will simply have no choice": 
  • Did we force them to use bitcoin for their project? 
  • It sounds like "if you don't change the code to enable my project, I will be forced to trash your project." Is this wrong?

By "force" I mean in the sense that when a recent KDE upgrade dropped the ability to specify some command to be run whenever the screen is locked, KDE "forced" me to write a systemd service to run dbus-monitor to watch for screen locking events instead.  Fortunately, in the case of KDE, being "forced" to work around their changes only makes my life worse.  However in the case of limiting OP_RETURNs, users who are "forced" to find workarounds for their proof of publication protocols  will ultimately lead to them using the uncensorable data channel of bare-multisigs, or similar, which have consequences not only for themselves but every other Bitcoin node operator on the planet.

It is specifically the externalities caused by the bare-multisig workaround that we need to address. If these externalities didn't exist, then I, and presumably others, wouldn't care so much.

• "any attempt to cap OP_RETURN outputs will force those users": 
  • Again, force is a form of coercion. Is the bitcoin code with it's current setting forcing anyone to do anything? 
  • Are the external protocol designers the victims here?

The victims will be every node operator on the planet who has to deal with the unprunable UTXO bloat caused by users posting their proof-of-publication data via the uncensorable bare-multisig avenue.  This collective cost will actually be much higher than the cost to the external protocol designers who only have to pay a few more pennies for their transactions.

 

• "Bitcoin Core 30 is *fixing* an existing problem": 
  • What problem?

The problem is a combination of protocols that require using proof-of-publication choosing to use uncensorable bare-multisigs instead, and/or, so long as this proposal isn't adopted, the problem of users bypassing the network to get their OP_RETURN transactions mined which leads to poor quality block reconstruction and poor quality fee estimates and the like.

• • Is the bitcoin code responsible for fulfilling the needs of an external project or protocol? 
    • If yes, why?

Again the victims here wouldn't be the external protocol designers.  They will just pay the extra pennies to publish using bare-multisig.  The victims would be every Bitcoin node operator on the planet.  And while the core developers have no warranties or responsibilities attached to their open source code, I think we would agree that "costs borne by every Bitcoin node operator on the planet", is something they ought to bear in mind in their work.

 

I hope you will take these questions seriously. I really want to understand your thinking.

Hope this helps. 

[yes_please]

Hi all, 

Perhaps we can find a meeting point if we focus on the max size of OP_return ? 

The increase from 83 to 100'000 bytes has been motivated as "probably we will have to increase it again in the future, it requires energy and time for code maintenance, so we'd rather increase it now to 100'000 bytes and be done with it". While these are valid points, the unknown consequences that might manifest with such a drastic increase all at once may not be the most prudent approach. 

Considering also that "the canary in the coal mine", namely Citrea use case, requires only 144 bytes to utilize op_return instead of more harmful ways, the increase to 100'000 bytes appears disproportionate given the circumstances, and again non-prudent enough (which is what I suspect is creating most of the debate at hand).

caucasianjazz12 

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.com.

[Greg Maxwell]

I searched for the source of your quotation and am unable to find it, but its author appears to be confused or missing a complete understanding.

The particular size isn't motivated by application but because major miners had already removed the rule completely.  As such no lesser setting would achieve the goal of matching relay to what will actually get mined and completely solve the bad situation created by the mismatch.

If you consider this regrettable it's worthwhile to consider that a failure to increase it previously (on several prior proposals) and even a failure to discuss and evaluate it was likely due to the unprofessional and relentless harassment of Luke-jr.  Had that not occurred perhaps the limit would have been incrementally increased previously before major miners on their own found it to be in their interest to simply remove it (as removing it is much easier than twiddling it).  The consequence of failing to be pragmatic is the loss of that nudge.

That said, the economics and incentives of bitcoin are such that the removal was inevitable once people were willing to pay for it-- and I would have happily told you this in 2014 or whenever back when op_return was reallowed for relay.  Beyond the current situation with the rule completely bypassed this inevitably favors removal once the policy has started eroding.  Even if miners had only bypassed to a few kilobytes or whatnot moving to match that would only result in repeated cycles of transactions that will get mined failing to relay, each cycle favoring private submission mechanisms and promoting mining centralization.  Policy is only at best a nudge and a fragile one.

I think in many people's view-- certainly in mine-- cirtia or whatever was irrelevant to the discussion except as a concrete example of a fake pubkey user that would rather not do that-- and one that wasn't some random NFT thing that we'd all rather not be using Bitcoin at all. In other words, that the benefit of avoiding more utxo bloat wasn't speculative.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPDT2SSC4p97xpDUKGE%2BwsRe3vw1%3D1q6-72UJHvzMPoTau7A7g%40mail.gmail.com.

[Melvin Carvalho]

čt 30. 10. 2025 v 3:16 odesílatel Greg Maxwell <gmax...@gmail.com> napsal:

I searched for the source of your quotation and am unable to find it, but its author appears to be confused or missing a complete understanding.

The particular size isn't motivated by application but because major miners had already removed the rule completely.  As such no lesser setting would achieve the goal of matching relay to what will actually get mined and completely solve the bad situation created by the mismatch.

If you consider this regrettable it's worthwhile to consider that a failure to increase it previously (on several prior proposals) and even a failure to discuss and evaluate it was likely due to the unprofessional and relentless harassment of Luke-jr.  Had that not occurred perhaps the limit would have been incrementally increased previously before major miners on their own found it to be in their interest to simply remove it (as removing it is much easier than twiddling it).  The consequence of failing to be pragmatic is the loss of that nudge.

That said, the economics and incentives of bitcoin are such that the removal was inevitable once people were willing to pay for it-- and I would have happily told you this in 2014 or whenever back when op_return was reallowed for relay.  Beyond the current situation with the rule completely bypassed this inevitably favors removal once the policy has started eroding.  Even if miners had only bypassed to a few kilobytes or whatnot moving to match that would only result in repeated cycles of transactions that will get mined failing to relay, each cycle favoring private submission mechanisms and promoting mining centralization.  Policy is only at best a nudge and a fragile one.

I think in many people's view-- certainly in mine-- cirtia or whatever was irrelevant to the discussion except as a concrete example of a fake pubkey user that would rather not do that-- and one that wasn't some random NFT thing that we'd all rather not be using Bitcoin at all. In other words, that the benefit of avoiding more utxo bloat wasn't speculative.

While much of this discussion has focused on policy, there’s also an incentive perspective.

Section 11 of the white paper notes that consensus holds iff honest nodes outpace dishonest ones.

If we interpret honest as mining blocks consistent with standard monetary use, excluding large OP_RETURN payloads, then miners who do so are likely to earn more.

When fees from arbitrary data are smaller than roughly half the block reward, standard ("honest") miners are effectively producing double-value blocks each epoch: they gain both the reward and a more secure, stable fee market over time.
That economic feedback alone could be enough to restore convergence back to standard size OP_RETURNs. Of course, setting back the default helps here too.

 

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTBNYUA%2Bu6qhywK7-hC1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%40mail.gmail.com.

[Martin Habovštiak]

"Honest" only refers to miners not trying to reverse the transactions by making an alternative chain. It has nothing to do with your subjective evaluation of the transactions worth trying to censor the "bad ones".

Bitcoin was specifically designed to prevent censorship of transactions that follow the consensus rules. Trying to go against it makes you a fool at best or an attacker at worst. 

Dňa št 30. 10. 2025, 18:37 Melvin Carvalho <melvinc...@gmail.com> napísal(a):

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYh%2BD9y6r0RZJPAGY08KSc1s%2BxUZ9UY4fR2f%3DdDc0joXEfQ%40mail.gmail.com.

[Melvin Carvalho]

čt 30. 10. 2025 v 20:35 odesílatel Martin Habovštiak <martin.h...@gmail.com> napsal:

"Honest" only refers to miners not trying to reverse the transactions by making an alternative chain. It has nothing to do with your subjective evaluation of the transactions worth trying to censor the "bad ones".

Hi Martin,

Small clarification per the white paper: "honest" isn’t only about reversing transactions. Section 8 of the white paper also discusses honest nodes and which transactions are accepted into blocks.

Satoshi further clarified standardness:
"The design supports a broad range of transaction types that are possible, but not all are standard. Standard transactions are the ones that are designed to be used for the common case."
-- June 2010

Per Section 11, the white paper's security model shows honest miners (e.g. following standard operation) outpacing alternatives. In practice, miners following a standardness agreement or soft fork for OP_RETURN would, on affected blocks, earn around $100,000 more, than under a mixed policy, making prioritizing standard transactions the economically optimal strategy.

This is because there are a finite number of blocks before each halving, so the opportunity cost of non-standard payloads is half the subsidy, which is more than enough economic upside to offset fees. A standardness agreement soft fork is therefore economically compelling for miners: it aligns with long-standing practice and provides long-term incentives.

Best,
Melvin