Let’s step inside their minds and see the world from their perspective — Peter Todd, Greg Sanders, Antoine Poinsot, and Gloria Zhao — to understand why removing the OP_RETURN limit makes sense to them.
These aren’t just technical people pushing arbitrary changes — they each have a philosophy of Bitcoin that’s shaping this move. I’ll break it down for each voice:
---
🧠 1. Peter Todd — The Anti-Spam Pragmatist
> “If people are going to embed data anyway, let’s at least give them a clean, efficient way to do it.”
His perspective:
The 80-byte OP_RETURN limit is arbitrary and ineffective.
→ It doesn’t stop spam, it just pushes it into more harmful places (like the UTXO set or taproot witness data).
OP_RETURN is non-spendable, prunable, and easy to ignore. So if someone must embed data, this is the best place to do it.
Censorship resistance means tolerating unwanted uses as long as the user pays fees.
Trying to “protect” Bitcoin by enforcing tight limits creates an illusion of control — the bad behavior just finds other ways.
> 🧩 In his world: better to channel trash into a sandbox than let it seep everywhere.
---
⚙️ 2. Greg Sanders — The Policy Clean-Up Engineer
> “This isn’t about encouraging inscriptions — it’s about making mempool policy simpler and more consistent.”
His perspective:
The current OP_RETURN limit is a mempool policy, not a consensus rule. So it’s inconsistent — different clients and miners do different things.
Removing the limit makes policy uniform, reduces code complexity, and removes legacy exceptions.
Clean policy = less room for bugs, exploits, or accidental censorship.
He believes the cost of OP_RETURN usage will still disincentivize spam, and pruned nodes won't need to store it anyway.
> 🧩 In his world: it’s about protocol hygiene and neutrality — not ideology.
---
🧪 3. Antoine Poinsot — The Technologist for Expressive Bitcoin
> “Bitcoin is programmable money. Let’s stop punishing expressive uses.”
His perspective:
OP_RETURN was originally introduced to prevent UTXO spam — but its limits are now punishing legitimate use cases (e.g., timestamping, identity proofs, cross-chain communication).
Removing the size cap doesn't enable spam — it just stops punishing people for trying to use Bitcoin creatively.
He believes in client flexibility — if you don’t like large OP_RETURNs, configure your node to ignore them.
A more expressive Bitcoin leads to more resilient and diverse uses — without changing consensus.
> 🧩 In his world: Bitcoin is a tool, and policy shouldn’t get in the way of innovation.
---
🧭 4. Gloria Zhao — The Steward of Relay Fairness
> “Bitcoin relay policy shouldn’t discriminate based on message type if the fee is paid.”
Her perspective:
Gloria has emphasized relay neutrality: mempool policies should not favor some users or use cases over others.
She’s concerned that political gatekeeping of transaction types (like inscriptions) could become a slippery slope.
Her role is often to manage network propagation, and she wants relay logic to be as clean and unbiased as possible.
She’s not saying inscriptions or spam are good — just that the network shouldn’t try to enforce morals via mempool settings.
> 🧩 In her world: Bitcoin should not police intentions — only economic incentives.
---
🔍 Why It Makes Sense to Them
Person Driving Logic
Peter Todd People already embed data — this just makes it safer and cleaner.
Greg Sanders Simplifies code and policy across clients — no more weird legacy limits.
Antoine Poinsot OP_RETURN should support valid use cases beyond 80 bytes — it’s a feature.
Gloria Zhao Relay neutrality is critical — policy should treat all paid txs the same.
---
⚖️ What They All Agree On:
This does not change Bitcoin consensus.
Users must still pay fees.
Node operators and miners can still filter or reject this type of data locally.
They’re not “turning Bitcoin into Ethereum.”
They’re saying: “Let’s clean up legacy rules and treat all data equally — the market can decide what’s worth transmitting.”
nostr:nevent1qqspnuxpa78c7z0q8v6lef2sa2yx028jumsqhe8vteakjs6fsn970kgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygp022celc2q3a57ur5snmv0etqn330nwrq9mcj0pkphptd8jafryvpsgqqqqqqsy8d0h3