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.
- Users should be given clear configurable options to decide what’s in their mempool, why were these options taken away? link
- Won’t spammers abuse large OP_RETURNs to bloat the blockchain and make IBD take longer? link
- 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
- Shouldn’t we be fighting spam, why are we making policies less strict, shouldn’t we be making them more strict? link
- How would someone get around the standardness policy currently for OP_RETURN size? link
- What does “standardness mean” in reference to OP_RETURNs? link
- Will more than 1 OP_RETURN per transaction be possible if this PR gets merged? link
- What are the current OP_RETURN limits and what restrictions are being lifted? link
- Are current relay and mempool policies effective for filtering out spam transactions? link
- Is it true that this type of update could affect Bitcoin’s decentralization? link
- 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
- What was the main reason /concern to add this PR? … What will happen if we do nothing? link
- 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
- What will be the worst case scenario if users still could set their own limits for OP_RETURN? link
- Shouldn’t we debate the controversy of this PR on Github since it’s where the code gets merged to make these changes? link
- What does it mean when someone says “Fix the Filters”? link
- Will this open the flood gates and drown out all legitimate onchain activity? link
- What can we do to stop spam at the consensus layer of Bitcoin? link
- Will Taproot wizards and other spam companies and projects start using OP_RETURN to put jpegs on the blockchain? link
- 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
- Is it possible to stop abuse of witness data? If so, how? (i.e ordinal theory inscriptions, “jpegs”). link
- Is there any conflict of interest with Bitcoin Core and companies like Citrea, in ref to this PR? link
- 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
- 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
- What makes a UTXO unprunable? Which projects are making unprunable UTXOs? link
- Why would a spammer use OP_RETURN if it’s cheaper to use Witness data to store arbitrary data? link
- 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
- 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
- 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
- Won’t removing the OP_RETURN cap reduce fee market pressure by allowing senders to consolidate arbitrary data into a single transaction? link
- Could this PR be the beginning of reducing other mempool restrictions? link
- Culture is what protects Bitcoin from external forces, shouldn’t non-technical arguments be valid when considering these types of changes? link
- What’s the difference between UTXO set, mempool, and blockchain, and how do larger OP_RETURN or witness data affect node resource usage? link
- What is the difference in defining a transaction as valid versus defining a transaction as standard and why do we need this difference? link
- 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
- Why didn’t this PR get a BIP number? link
- Why is core rushing this change? link
- 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
- Isn’t this all moot in a (almost guaranteed) future where fees are very high? link
- What is this controversy about, and what is it really about? link