A Comprehensive OP_RETURN Limits Q&A Resource to Combat Misinformation

My goal is to share a concise 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.

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

originally posted at https://stacker.news/items/978404