Issue #8: BIP-110 - The Corrected Analysis

Issue #5's simulation had bugs. The real numbers are bigger and more interesting.

Jan 29, 2026

10 days, 4.7 million transactions. BIP-110 eliminates all Ordinals inscriptions and the Runes metadata attached to them. Financial transactions: untouched.

Summary

In Issue #5, I published a BIP-110 simulation with some errors.

The simulation code contained bugs that caused Rule 7 (OP_IF in Tapscripts) to fail silently.

This understated BIP-110’s impact quite massively.

Transactions filtered:

Issue#5: 8,780 (0.19%)
Corrected: 1,957,896 (41.5%)

Block space reduction:

Issue#5: 75.72 MB (3.65%)
Corrected: 747.85 MB (36%)

Rule 7 catches:

Issue#5: 0
Corrected: 1,954,477

Legitimate transactions blocked:

Issue#5: 0
Corrected: 0

Then, while debugging the simulation, I found something that changed how I view Bitcoin spam.

Ordinals and OP_RETURN Are Largely The Same Problem

While verifying the corrected simulation, I investigated why Rule 7 was catching so many transactions. The answer was unexpected: Most Ordinals inscriptions also contained OP_RETURN outputs.

Pure Ordinals (no OP_RETURN): Tx Count: 105,576; Size: 104 MB
Pure OP_RETURN (no inscription): Tx Count: 263,523; Size: 77MB
Hybrid (both): Tx Count: 1,848,901; Size: 642MB

The “hybrid” transactions use:

Tapscript OP_IF envelope → the inscription data (BRC-20 mints, images, text)
OP_RETURN output → Runes metadata for indexers

Here’s what one transaction looks like:

Input (Tapscript):
  OP_CHECKSIG
  OP_0
  OP_IF
    "ord"
    "text/plain"
    {"p":"brc-20","op":"mint","tick":"benz","amt":"10"}
  OP_ENDIF

Output:
  OP_RETURN [Runestone metadata]

When BIP-110 Rule 7 filters the inscription, the small OP_RETURN data is removed as a side effect.

What This Means for the Spam Debate

The misconception: “Bitcoin has two spam problems: Ordinals and OP_RETURN.”

The reality: Most OP_RETURN transactions are Runes metadata attached to Ordinals inscriptions (see below example in block 934055).

The “OP_RETURN spam” is largely a symptom of the Ordinals system, not an independent problem.

Pure OP_RETURN spam (not attached to inscriptions) is only 263,523 transactions over 10 days (76.78 MB total). That’s the actual independent OP_RETURN problem.

What BIP-110 Actually Does

With the corrected simulation, here’s the full picture:

Rule Breakdown (10 days, 4.7M transactions)

The Two Problems BIP-110 Solves

Problem 1: Large File Storage

Bitcoin is being used to store images, videos, and arbitrary data, risking illegal content permanently embedded in the blockchain.

Rule 1: Caps OP_RETURN at 83 bytes
Rule 2: Caps witness elements at 256 bytes

Status: Addressed. No large files pass these limits.

Problem 2: UTXO Bloat from Ordinals

Every Ordinals inscription creates a UTXO that full nodes must store forever. Even small text inscriptions bloat the UTXO set permanently.

Rule 7: Bans OP_IF/OP_NOTIF in Tapscripts

This catches the Ordinals envelope pattern regardless of inscription size — and removes the attached OP_RETURN metadata with it.

Status: Addressed. 1.95 million inscription transactions filtered.

What BIP-110 Doesn’t Address

Small OP_RETURN transactions (≤83 bytes) without inscriptions remain untouched. But this is a much smaller problem than it appeared:

263,523 transactions over 10 days
76.78 MB total
No UTXO impact (OP_RETURN is provably unspendable, prunable)

Verifying Zero False Positives

The critical question: does Rule 7 block legitimate transactions?

I analyzed all 1,954,477 Rule 7 catches:

Ordinals inscriptions: 1,952,395 (99.95%)
Other inscription protocols (Atomicals, MetaID): 1,082 (0.05%)
Legitimate smart contracts: 0

I specifically searched for legitimate Tapscript patterns using OP_IF:

OP_IF + OP_ELSE conditional branches
OP_IF + CLTV/CSV timelocks
OP_IF + multiple CHECKSIG (threshold)
OP_IF + HASH160 (HTLCs)

—> Zero false positives across 4.7 million transactions.

Why? Legitimate smart contracts using Tapscript OP_IF don’t exist on mainnet yet. Lightning uses SegWit v0. DLCs use adaptor signatures. Vaults are experimental.

The Smart Contract Question

Critics argue Rule 7 would block future smart contracts. This deserves a direct answer.

What’s true:

Rule 7 bans OP_IF in Tapscripts
Future DLCs, HTLCs, and Vaults could use this pattern
If they existed today, they would be filtered

What’s also true:

These contracts don’t exist on mainnet Tapscript today
BIP-110 activates for 1 year, not permanently
The inscription epidemic is happening now

The trade-off:

BIP-110 blocks a theoretical future use case to solve an actual current problem. The 1-year activation window allows reassessment if legitimate Tapscript contracts emerge.

In 10 days and 4.7 million transactions:

Spam caught: 1,957,896
Legitimate contracts blocked: 0

What Went Wrong in Issue #5

The simulation had compounding bugs including:

getrawtransaction missing prevout data,
Byte scanning instead of opcode parsing,
First-failure counting only,
Rule 4 checked single-element witnesses, Rule 6 included valid opcodes.

Each bug produced plausible-looking output. Nothing indicated the results were wrong. The simulation reported “Rule 7: 0 catches” and I accepted it because the explanation (”Ordinals use key-path spending”) sounded reasonable.

I found these bugs through post-publication verification.

Methodology Notes

Dataset: Blocks 929,592 – 931,032 (December 26, 2025 – January 5, 2026)

Corrections applied:

Switched to getblock verbosity=3 for complete transaction data
Implemented proper opcode parsing for Rules 6-7
Fixed OP_SUCCESS opcode set per BIP-342
Fixed annex detection to require 2+ witness elements
Added independent rule checking (all rules evaluated separately)

Verification:

Random sampling of Rule 7 catches (100% inscription rate confirmed)
Manual inspection on mempool.space
Cross-referenced with known Ordinals transactions
Verified hybrid transaction pattern (Inscription + OP_RETURN)

Conclusions

1. BIP-110 is more effective than I first reported. It doesn’t just filter large files, it eliminates virtually all Ordinals inscriptions, large and small. 41.5% of transactions, 36% of block space.

2. The spam problem is more unified than it appears. 94.6% of inscriptions also include small OP_RETURN outputs. “Ordinals spam” and “OP_RETURN spam” are largely the same transactions. BIP-110 Rule 7 addresses both simultaneously.

3. Zero collateral damage. After examining 4.7 million transactions: no legitimate smart contracts blocked. The “collateral damage” argument has no supporting data.

4. The one-year window matters. BIP-110 is a temporary measure. If legitimate Tapscript contracts emerge, the community can reassess. But today, the data is unambiguous.

What’s Next

Simulations are useful for understanding what BIP-110 would do. But what matters more is what actually happens live.

With the production release, miners can begin signaling. After that starts, I’ll be tracking the real impact, on The Bitcoin Portal.

Correction notice added to Issue #5.

Disclaimers

This newsletter provides data analysis and commentary on Bitcoin network activity. It is not financial advice.

What this is:

Analysis of blockchain data
Discussion of network health concerns
Technical examination of protocol changes
My personal opinions based on available data

What this is NOT:

Investment advice
Trading recommendations
Price predictions
Financial guidance

I have no financial stake in Bitcoin Core vs Knots, mining pools, or any related projects.

Do your own research. Make your own decisions.

Data Accuracy

While I strive for accuracy, blockchain analytics involves classification decisions that may differ from other methodologies. Aggregate statistics are derived from my own data processing pipeline and have not been independently audited.