my biggest question is about risk of majority node mempool flooding with 4MB txs from one or more large bad actor(s) with fees to burn in an attack
Login to reply
Replies (2)
Thank you for sharing and helping my #studybitcoin journey. I still needed to translate what you are saying for complete comprehension.
As in...
Crany is raising a valid technical concern about the security implications of removing the OP_RETURN data size limit. Here's a breakdown of what he's saying:
---
Translation:
πΈ If the OP_RETURN limit is removed, malicious actors could start spamming the Bitcoin network with huge 4MB transactions (the maximum block size).
πΈ These spammy transactions might include junk data via OP_RETURN (e.g. memes, NFTs, nonsense, political messages, arbitrary data blobs).
πΈ The attacker could do this over and over again, pushing the mempools (waiting areas for transactions) of most nodes to fill up quickly β flooding the network.
πΈ Since they'd be paying transaction fees, it's not technically invalid, but it would be malicious β a kind of "griefing" attack where someone with lots of money and no regard for cost just wants to jam the system.
πΈ In essence, Bitcoinβs decentralized nodes might start drowning in data, especially lightweight or resource-constrained ones.
---
π§― Why this matters:
This is a classic tradeoff:
More data freedom β potentially more innovation (e.g. creative uses, new protocols)
More data freedom β potentially more attack surface (e.g. junk spam, DoS attempts)
Cranyβs question highlights what many critics of the OP_RETURN change are nervous about:
> Will this change make Bitcoin more resilient, or just more vulnerable?
π§ But here's the nuance:
It's not that this suddenly makes Bitcoin vulnerable β mempool flooding has always been possible, but this change could:
Lower the barrier to abuse
Make spam attacks more efficient
Create new incentives for garbage data to enter the chain
Core devs are saying: βWe can already handle this with existing tools (mempool policies, fees, node configurations).β
Critics like crany are saying: βYes, but this amplifies the risk and might overwhelm those tools β especially for less-resourced users.β
---
π So both can be true:
Yes, the concern is valid β especially from a security, UX, and decentralization lens.
And yes, Core may have thought through mitigations β but whether those are enough remains an open question.
This is why the debate is so hot. It's not about whether something is theoretically possible... it's about how easy, how often, and how damaging it could become with this specific policy shift.