A data-driven response to instagibbs' gist on retiring the OP_RETURN limit.
The original gist presents a reasonable-sounding engineering case. This response does not question the author's intent. It questions the claims against the available data, much of which post-dates the original gist.
The original gist correctly identifies why OP_RETURN exists: to channel data embedding into provably unspendable outputs rather than polluting the UTXO set. That design worked. The question is whether removing the 80-byte ceiling was the right next step. The data suggests it was not.
The gist asserts this without quantitative support. The data tells a different story.
- 99% reduction in non-financial transactions when relay filters are active (Chris Guida)
- BIP-110 simulation over 4.7 million transactions (Renaud Cuny, Bitcoin Block Space Weekly Issue #8):
- 1,957,896 transactions (41.5%) would be filtered
- 747.85 MB (36%) of block space reclaimed
- 99.95% of filtered transactions were Ordinals inscriptions
- Zero legitimate smart contracts blocked
A policy that achieves 99% effectiveness has not outlived its utility. It is working.
The gist notes that private mining accelerators and alternative implementations bypass the limit. This is true, but incomplete.
"Easily bypassed" does not mean "ineffective." Door locks are easily bypassed. Speed limits are easily bypassed. We retain both because they reduce the problem to manageable levels, not because they eliminate it.
The 99% reduction figure is the empirical answer. Perfect enforcement was never the standard for any relay policy in Bitcoin's history. If it were, dust limits, ancestor caps, and signature-operation checks would all be candidates for removal.
It is also worth noting that some bypass tools (e.g., Libre Relay) were created after the limits existed, then cited as evidence that limits do not work. That is circular reasoning, not empirical evidence.
The gist argues that blocking OP_RETURN pushes data into spendable outputs that pollute the UTXO set. This framing presents two options: unlimited OP_RETURN or UTXO pollution. There is a third: effective filtering.
The 80-byte limit operated for approximately a decade. During that period, UTXO pollution from data embedding was not a significant or growing problem. The surge in non-financial transaction volume began with Ordinals (February 2023) and Runes (April 2024), both of which exploit witness space and OP_RETURN respectively. They did not arise from the 80-byte limit being too restrictive.
The current state:
- 41% of block space is non-financial data (last 90 days, Renaud Cuny)
- 136 million non-financial transactions over 3.5 years
- 76 GB of non-financial data stored on every node, permanently
This is not a UTXO cleanliness problem. It is a block space allocation problem that the limit removal made worse.
The gist describes filtering as an "aggressive blacklist" leading to a "complex game of cat-and-mouse." The simulation data contradicts this.
Renaud Cuny's corrected BIP-110 analysis tested the rules against 4.7 million real transactions:
- 99.95% of Rule 7 catches were Ordinals inscriptions
- Zero legitimate smart contracts were blocked
- The false positive rate was effectively zero
These are not theoretical projections. They are results from running the filter against actual mainnet data. The patterns are reliable. The cat-and-mouse framing assumes a sophistication of evasion that has not materialised at scale.
BIP-110 includes a grandfather clause that exempts all pre-activation UTXOs. The code audit (BIP-110 Game Theory & Code Audit) confirms correct implementation with per-input flag override. Pre-signed transactions spending pre-activation outputs are unaffected.
This objection has been addressed in the BIP text, the reference implementation, and multiple public discussions.
The gist presents a cleaner UTXO set as a tangible benefit of removing the limit. This argument depends on the assumption that data embedding will happen regardless and OP_RETURN is the least harmful channel.
If filters achieve 99% reduction, the assumption is wrong. The choice is not between "data in OP_RETURN" and "data in spendable outputs." The choice is between "data on-chain" and "99% less data on-chain."
The gist states Option 3 "earned broad, though not perhaps unanimous, support."
The community response to the OP_RETURN limit removal PR was 423 against and 105 for, a ratio of approximately 4:1 in opposition. Bitcoin Knots, which retains spam filtering, surged from 2-4% to 21% of reachable nodes in the months following Core v30's release.
"Broad support" within the maintainer group is not the same as broad community support. One of Core's own maintainers stated in December 2023: "If it is controversial, then we don't touch it." The 4:1 opposition ratio suggests this standard was not applied.
The 80-byte OP_RETURN limit was itself a minimal rule. It had been in place for approximately a decade. Removing it was the change, not maintaining it.
Framing a decade-old default as "editorial preference" while framing its removal as "transparent and minimal" is itself a framing choice. The community did not request this change. It was proposed, opposed 4:1, and merged.
The original gist contains no quantitative data. No transaction counts, no block space analysis, no fee breakdowns, no simulation results. The argument is structured around engineering intuition and theoretical reasoning.
Since the gist was written, substantial empirical work has been published:
| Metric | Value | Source |
|---|---|---|
| Non-financial block space | 41% (last 90 days) | Renaud Cuny, Block Space Weekly |
| Non-financial transactions | 136M over 3.5 years | Renaud Cuny |
| Data stored on every node | 76 GB | Renaud Cuny |
| Filter effectiveness | 99% reduction | Chris Guida |
| BIP-110 simulation accuracy | 99.95% correct catches | Renaud Cuny, Issue #8 |
| Legitimate contracts blocked | 0 | Renaud Cuny, Issue #8 |
| OP_RETURN limit increase | 1,250x (80b to 100KB) | Bitcoin Core v30 |
| Community opposition | 4:1 (423 vs 105) | GitHub PR |
| Inscription fee premium | 0.08% of block reward | Ocean vs SpiderPool |
| Miner revenue from total fees | 0.64% | Renaud Cuny |
This data was not available when the original gist was written. It is available now. The question is whether the conclusions in the gist still hold in light of it.
The original gist makes a coherent theoretical case. But engineering decisions should be evaluated against empirical data, not theoretical reasoning alone. The data shows:
- The 80-byte limit was effective (99% reduction when enforced)
- Filter patterns are reliable (99.95% accuracy, zero false positives on legitimate contracts)
- The community opposed the change (4:1)
- The problem has grown since the change (41% of block space, 76 GB on every node)
- The economic incentive to resist filtering is negligible (0.08% of block reward)
Bitcoin is peer-to-peer electronic cash. The policy surface should serve that function. When 41% of block space is consumed by non-financial data for 0.08% of block reward, the policy is not serving its users. The 80-byte limit was not perfect, but it was working. Removing it made the problem worse, and the data now exists to demonstrate that clearly.
Data sourced from Bitcoin Block Space Weekly (Renaud Cuny), Chris Guida's filter analysis, and the BIP-110 Game Theory & Code Audit.