A Comprehensive OP_RETURN Limits Q&A Resource to Combat Misinformation

Philosophy
,
1

My goal is to share a consolidated list of questions about OP_RETURN limits that we’ve answered on Stacker News, as the original thread has become unwieldy with over 200 comments. We began compiling this list about a week ago. I’ve frequently shared individual links and received very positive feedback. I hope this resource helps us work from a common set of facts and reduces misinformation. I hope you find this as a valuable resource.

Special thanks to @murch for encouraging me to ask questions and for taking the time to field many of them.

I’ll list the questions in order of activity and tips received. I’ve removed duplicates, rephrased some statements as questions, and ignored completely irrelevant questions.

  1. Users should be given clear configurable options to decide what’s in their mempool, why were these options taken away? link
  2. Won’t spammers abuse large OP_RETURNs to bloat the blockchain and make IBD take longer? link
  3. A similar PR was proposed by Peter Todd 2 years ago, why was it rejected then? What has changed since then, why would this get approved now? link
  4. Shouldn’t we be fighting spam, why are we making policies less strict, shouldn’t we be making them more strict? link
  5. How would someone get around the standardness policy currently for OP_RETURN size? link
  6. What does “standardness mean” in reference to OP_RETURNs? link
  7. Will more than 1 OP_RETURN per transaction be possible if this PR gets merged? link
  8. What are the current OP_RETURN limits and what restrictions are being lifted? link
  9. Are current relay and mempool policies effective for filtering out spam transactions? link
  10. Is it true that this type of update could affect Bitcoin’s decentralization? link
  11. Is it possible to stop the abuse of payment outputs (i.e., bare multisig, fake pubkeys, and fake pubkey hashes) that are used to embed data, thereby creating unprunable UTXOs that bloat the UTXO set? link
  12. What was the main reason /concern to add this PR? … What will happen if we do nothing? link
  13. If OP_RETURN still cannot stop all the garbage, why is so important to remove it? Does it affect future development / improvements for LN? link
  14. What will be the worst case scenario if users still could set their own limits for OP_RETURN? link
  15. Shouldn’t we debate the controversy of this PR on Github since it’s where the code gets merged to make these changes? link
  16. What does it mean when someone says “Fix the Filters”? link
  17. Will this open the flood gates and drown out all legitimate onchain activity? link
  18. What can we do to stop spam at the consensus layer of Bitcoin? link
  19. Will Taproot wizards and other spam companies and projects start using OP_RETURN to put jpegs on the blockchain? link
  20. If we prevent these transaction from going into our mempools doesn’t that prevent or delay these spam transactions from being mined therefore discouraging the spammers? link
  21. Is it possible to stop abuse of witness data? If so, how? (i.e ordinal theory inscriptions, “jpegs”). link
  22. Is there any conflict of interest with Bitcoin Core and companies like Citrea, in ref to this PR? link
  23. Is there any estimation on how much would this affect fees for the average user, considering external projects (like Citrea) using it? Any possibility that this could saturate the mempool and boost fees beyond reasonable? link
  24. Was this PR initially proposed because of Citrea BitVM needs? If so don’t they only need a slight bump in OP_RETURN size, why is it being proposed to make the size unrestricted? link
  25. What makes a UTXO unprunable? Which projects are making unprunable UTXOs? link
  26. Why would a spammer use OP_RETURN if it’s cheaper to use Witness data to store arbitrary data? link
  27. Won’t large OP_RETURNs allow people to spam the mempool with 100kb transactions and mess up bitcoin for everyone by bloating the mempool and not allowing legitimate transactions in the mempool? link
  28. If relaxing op_return standardness limit seeks to make ‘spam’ prunable, then what are proponents of this change assuming about the long-term feasibility of running a ‘full’ (unpruned) bitcoin node? link
  29. Is allowing standardness for larger OP_RETURNs a slippery slope? If we allow this won’t we continue to allow things that make bitcoin less for money and more for arbitrary data? link
  30. Won’t removing the OP_RETURN cap reduce fee market pressure by allowing senders to consolidate arbitrary data into a single transaction? link
  31. Could this PR be the beginning of reducing other mempool restrictions? link
  32. Culture is what protects Bitcoin from external forces, shouldn’t non-technical arguments be valid when considering these types of changes? link
  33. What’s the difference between UTXO set, mempool, and blockchain, and how do larger OP_RETURN or witness data affect node resource usage? link
  34. What is the difference in defining a transaction as valid versus defining a transaction as standard and why do we need this difference? link
  35. If you’re happy with your viewpoint on consensus and mempool rules, is not upgrading Bitcoin Core until it makes sense to you a valid action to take right now? link
  36. Why didn’t this PR get a BIP number? link
  37. Why is core rushing this change? link
  38. If there will be a hard fork resulted from this PR (split chain like in 2017), what will happen with existing LN channels? Will exist on both chains with 2 LNs? link
  39. Isn’t this all moot in a (almost guaranteed) future where fees are very high? link
  40. What is this controversy about, and what is it really about? link
4 Likes
2

First of all thank you for your guide, very useful.

In regard to point#24, specifically as to why the limit has been increased so much to 100’000 bytes, the given motivation is: “…undemanded blockspace is no longer a thing. OP_RETURN outputs would have to compete for blockspace with other transactions at all times. The limit is neither as important nor as effective today as when it was introduced. Instead of providing mining pools with a financial incentive to accept oversized OP_RETURN outputs out of band, and to have debates to slightly loosen the limit further every once in a while, it seems easier to get rid of the incentive and debates by dropping it altogether”.

The given motivation claims that the limit is irrelevant as large op_return will be pushed out by market forces. In regard to the latest claims that in this way (with 100’000 bytes for op_return) CP images can:

  1. be uploaded as a single jpeg which is visible/clear enough

  2. It is possible to visualize it in a much much simpler way (being a single hash) compared as to other data already embedded in the blockchain but that are “fractured” in multiple txs and are much harder to reconstruct?

If the 2 points above are correct, would not this expose btc to a massive risk of having CP images uploaded on the chain? (I’m referring to legal risks here). If this is the case a sufficiently motivated actor will not be discouraged by large fees, also as it would be enough to upload 1 of these images to have enough reasons/proofs to his advantage.

Since this specific case has surfaced aggressively in the recent discussions, and there seems to be contradicting ideas (on how easy it is to visualize it) i would be appreciated to have some clarification on this

3

If the 2 points above are correct, would not this expose btc to a massive risk of having CP images uploaded on the chain?

There are much worse ways to push data on-chain, than OP_RETURN. For example, it is possible to use some future Segwit version, and push everything, as a continuous 4 MB witness data chunk.

Also, 520-byte chunks can be easily collected, and displayed, so even if some data will be fragmented between many outputs, many transactions, and many coins, then it doesn’t matter, because writing a parser, which will collect all of that, and display it to the user, is quite easy.

4

Thank you for the reply. So basically it is already feasible in an equally easy way, and the “new” op_return would not change this particular use case in any way.

I was confused as it was claimed that using single op_return of 100KB would have made it easier to visualize the jpeg (much less complicated tools needed to see the image from the hex)