- A proposal to lift the 80-byte OP_RETURN limit has sparked concerns over blockchain bloat
- Critics warn it could dramatically increase data size, but former Bitcoin Core developer Greg Maxwell disputes this
- Maxwell argues the change may actually *reduce* average block sizes due to Bitcoin’s block weight structure
A technical debate has resurfaced in the Bitcoin community following a proposal to remove the 80-byte limit on OP_RETURN — a field used to embed arbitrary data into Bitcoin transactions. While some argue the change could significantly inflate blockchain storage demands, former Bitcoin developer Greg Maxwell has pushed back, calling the concern misguided and based on flawed assumptions. The current debate over removing the 80-byte limit revives long-standing tensions between Bitcoin’s role as sound money versus a broader data platform, 11 years after its implementation.
Proposal to Remove the Limit
OP_RETURN, introduced in 2014, allows Bitcoin users to embed small pieces of data in transactions in a way that doesn’t bloat the spendable coin set. Originally capped at 40 bytes and later raised to 80, it was designed to support lightweight metadata use cases like timestamps and digital proofs without turning Bitcoin into a general-purpose data storage network. While it has enabled innovations like NFTs, identity systems, and timestamping protocols, it has also sparked controversy over blockchain bloat, spam, and ‘mission creep’.
The debate resurfaced again yesterday, with a reply to a Reddit post asking for help understanding the issue outlining a scenario where removing the OP_RETURN size limit could increase blockchain growth by as much as 36%, especially in high-use or spam attack scenarios. The writer warned that lifting the cap could lead to blockchain bloat, increased costs for full nodes, and greater centralization risks due to the strain on archival storage.
Citing figures like ~18.25 GB/year under heavy use, and a potential 7 GB/week under spam attack conditions, the post highlights possible long-term consequences for Bitcoin scalability and fees. The post’s author also noted that although OP_RETURN data is prunable (can be discarded by most nodes), archival nodes – which store the full chain history – would still be burdened with storing this excess data. The post argues that even existing efficiency measures like Taproot do little to mitigate the overall trend toward blockchain expansion, something that many developers want to avoid.
“Hallucinated Nonsense”
Noted former Bitcoin developer Greg Maxwell responded forcefully to the post, dismissing the data-heavy prediction as “LLM hallucinated nonsense.” Maxwell clarified that OP_RETURN is non-witness data, meaning it takes up four times the weight compared to witness data in Bitcoin’s block weight system. Since block weight, not raw byte size, is the constraint, OP_RETURN-heavy transactions could actually reduce block sizes in practice. Maxwell used an analogy to illustrate his point:
In other words, if you had a bucket that can store 5 gallons that you normally completely fill with marbles, if you start adding styrofoam peanuts to your mix the weight of the full bucket will go down because the peanuts displace denser marbles.
In Bitcoin’s case, that could mean blocks contain less overall data when filled with more OP_RETURN content.
Maxwell conceded that increased demand might still lead to higher fees, but firmly rejected the idea that the proposal would inflate blockchain size in the way critics fear. He called the alarmist analysis “truthy looking figures” that misrepresent how Bitcoin’s block structure functions.
A Never-Ending Battle
The OP_RETURN debate taps into long-standing tensions in the Bitcoin community between utility and minimalism: OP_RETURN enables use cases like timestamping, NFTs, and decentralized identity systems, but critics say such uses stray from Bitcoin’s intended monetary role. The issue also revives concerns about decentralization, as more data on-chain could make it harder for individuals to run full nodes — a critical part of Bitcoin’s distributed design.
As the release of the proposal approaches, developers and node operators will need to weigh these trade-offs carefully.
