Inside the Looming Failure of BIP-110: Why Bitcoin’s Proposed Ban on Ordinals is Heading for Rejection
As Bitcoin marches toward its August 2026 deadline for BIP-110—a controversial, temporary soft fork proposal designed to restrict arbitrary data embedding—the network’s decentralized governance model is once again on full display. BIP-110, titled the "Reduced Data Temporary Softfork," aims to impose a one-year moratorium on the data-stuffing practices that have powered the rise of Ordinals and BRC-20 tokens.
Yet, with the activation window well underway, miner signaling for the proposal remains effectively at zero.
The impending failure of BIP-110 is more than just a footnote in technical development; it represents a fundamental clash of philosophies over what Bitcoin is, how its block space should be utilized, and who decides the rules of the network. For developers, miners, investors, and enterprise stakeholders, the mechanics of why and how BIP-110 is failing offer critical insights into the immutable nature of Bitcoin’s consensus layer.
Main Facts: The Core of the BIP-110 Controversy
At its heart, BIP-110 is an attempt to resolve a lingering architectural debate sparked by the Taproot upgrade in November 2021. Taproot inadvertently removed size limits on witness script data, allowing developers to bypass the traditional 80-byte limit on OP_RETURN outputs by embedding large files—including images, audio, and text—directly into the witness portion of a transaction. This technical loophole gave birth to "Ordinals," turning the Bitcoin blockchain into an immutable, decentralized storage network for digital artifacts.
BIP-110 proposes a simple, temporary fix: restrict the amount of arbitrary data that can be pushed via witness scripts to a maximum of 42 bytes per input for a period of exactly one year.
Key Elements of the Proposal:
- Target Mechanism: It targets the specific script structure used by Ordinals—the
OP_FALSE OP_IF ... OP_ENDIFenvelope—which allows arbitrary data up to 4 megabytes (an entire block) to be stuffed into a single transaction input. - The Threshold: To activate, the proposal requires 95% of mining power to signal support within a specific 2,016-block difficulty retarget window before the August 2026 deadline.
- Current Status: Miner signaling is sitting at approximately 0.25%, rendering the proposal dead on arrival.
Chronology of the Ordinals Dispute and BIP-110
The road to BIP-110 is marked by technical upgrades, unintended consequences, and a growing divide within the global Bitcoin community.
+------------------+ +------------------+ +------------------+ +------------------+
| November 2021 | | January 2023 | | Late 2023 | | August 2026 |
| Taproot Activates| --> | Ordinals Launch | --> | BIP-110 Proposed | --> | Activation Epoch |
| Removes witness | | Inscriptions rise| | Temporary ban | | Deadline; near |
| size limits | | fees skyrocket | | on large data | | 0% miner support|
+------------------+ +------------------+ +------------------+ +------------------+1. The Taproot Catalyst (November 2021)
The Taproot soft fork was activated with near-universal consensus, aimed at improving privacy, smart contract flexibility, and transaction efficiency. Crucially, it removed the size limits on witness data, assuming that transaction fees would naturally deter users from uploading large, non-financial files.
2. The Rise of Ordinals (January 2023)
Developer Casey Rodarmor introduced the Ordinals protocol, which assigns unique identifiers to individual satoshis (the smallest unit of Bitcoin) and allows users to "inscribe" them with arbitrary data. Almost overnight, the Bitcoin network saw a massive influx of digital art, meme coins (BRC-20), and text files. This led to unprecedented mempool congestion, with transaction fees surging to multi-year highs.
3. The Backlash and the Drafting of BIP-110 (Late 2023)
"Bitcoin purists" argued that Ordinals were a form of network abuse, cluttering node storage, bloating the UTXO (Unspent Transaction Output) set, and making it more expensive for users in developing nations to use Bitcoin for peer-to-peer cash transactions. In response, developers drafted BIP-110 as a "cooling-off" measure to give the ecosystem one year to find alternative solutions without permanently altering Bitcoin’s codebase.
4. The Activation Epoch and Present Day
BIP-110 was released for miner signaling under a strict timeline. However, since its deployment, mining pools have almost completely ignored the proposal, choosing instead to collect the lucrative fees generated by Ordinal transactions.
Technical Breakdown & Supporting Data
To understand why BIP-110 is failing, one must examine the mechanics of soft fork activation and the specific code that defines the proposal.
How Soft Forks and BIP 9 Activation Work
A soft fork is a backward-compatible change to Bitcoin’s consensus rules. Nodes running older software versions will still accept blocks created by upgraded nodes, preventing the chain from splitting into two competing networks.
Since 2016, Bitcoin has primarily used BIP 9 (or variations thereof) to coordinate upgrades. BIP 9 relies on miner signaling via the nVersion field in block headers. Miners use specific bits in this 32-bit integer to signal that they are ready to enforce the new rules.
The standard BIP 9 state machine consists of several phases:
- Defined: The proposal is written and assigned a version bit.
- Started: Miners can begin setting the assigned bit in their solved blocks.
- Locked-In: If signaling reaches the 95% threshold (1,914 out of 2,016 blocks in a retarget period), the upgrade is locked in.
- Active: The rules become active and are enforced by the network.
- Failed: If the deadline passes without lock-in, the proposal expires.
The following Python script illustrates this basic threshold logic:
# Simplified BIP 9 state machine logic
THRESHOLD = 0.95 # 95% of blocks in a retarget window
WINDOW = 2016 # One retarget period (approx. two weeks)
def check_activation(signaling_blocks: int, total_blocks: int) -> str:
ratio = signaling_blocks / total_blocks
if ratio >= THRESHOLD:
return "LOCKED_IN" # Activates after one more window
return "STARTED" # Still counting
print(check_activation(1914, 2016)) # => LOCKED_IN (95.0%)
print(check_activation(1800, 2016)) # => STARTED (89.3%)
print(check_activation(5, 2016)) # => STARTED (0.25%) — Current BIP-110 situationThe BIP-110 Script Restriction
BIP-110 targets the exact "envelope" structure that Ordinals developers use to hide arbitrary data within tapscript witness data. This envelope is designed to be ignored by the Bitcoin execution engine during normal transactions, acting as a technical "comment" block.
# Standard Ordinals inscription envelope (what BIP-110 targets)
OP_FALSE
OP_IF
OP_PUSH "ord" # Protocol tag identifying the data as an Ordinal
OP_PUSH 1
OP_PUSH "text/plain" # MIME content type
OP_PUSH 0
OP_PUSH <arbitrary data up to 4MB per input>
OP_ENDIF
<actual spend script>Under BIP-110, any transaction where a witness stack item within this envelope exceeds 42 bytes is flagged as invalid by upgraded nodes. Because old nodes do not enforce this limit, they continue to see these transactions as valid, satisfying the definition of a soft fork.
Verifying the Lack of Support via Code
Anyone can verify the lack of miner support for BIP-110 on-chain. By querying a local Bitcoin Core full node or using a public API, developers can check the version bits of recently mined blocks.
Below is a Python implementation utilizing the bitcoin-rpc library to scan the blockchain for BIP-110 signaling (using Version Bit 4):
from bitcoinrpc.authproxy import AuthServiceProxy
import struct
RPC_URL = "http://rpcuser:[email protected]:8332"
BIP110_BIT = 4 # Assigned version bit for BIP-110
def get_rpc():
return AuthServiceProxy(RPC_URL)
def check_version_bit(nversion: int, bit: int) -> bool:
"""
BIP 9 signals when nVersion has bit N set
and the high bits match 0x20000000.
"""
BIP9_TOP_MASK = 0xE0000000
BIP9_TOP_BITS = 0x20000000
if (nversion & BIP9_TOP_MASK) != BIP9_TOP_BITS:
return False
return bool(nversion & (1 << bit))
def scan_signaling(num_blocks: int = 2016) -> dict:
rpc = get_rpc()
tip_hash = rpc.getbestblockhash()
tip = rpc.getblock(tip_hash)
signaling = 0
total = 0
block_hash = tip_hash
for _ in range(num_blocks):
block = rpc.getblock(block_hash)
nversion = block["version"]
if check_version_bit(nversion, BIP110_BIT):
signaling += 1
total += 1
block_hash = block.get("previousblockhash")
if not block_hash:
break
return
"blocks_scanned": total,
"signaling": signaling,
"not_signaling": total - signaling,
"signal_percentage": round((signaling / total) * 100, 2),
"threshold_needed": 95.0,
"locked_in": (signaling / total) >= 0.95,
# Example execution output:
# 'blocks_scanned': 2016, 'signaling': 5, 'not_signaling': 2011,
# 'signal_percentage': 0.25, 'threshold_needed': 95.0, 'locked_in': FalseFor those without a local full node, the same data can be retrieved from public APIs, such as Mempool.space:
import httpx
def check_signaling_via_api(num_blocks: int = 100) -> dict:
"""
Queries the mempool.space API to check version bits.
"""
signaling = 0
BIP110_BIT = 4
resp = httpx.get("https://mempool.space/api/blocks")
blocks = resp.json()
for block in blocks[:num_blocks]:
nversion = block["version"]
# Bitwise check
BIP9_TOP_MASK = 0xE0000000
BIP9_TOP_BITS = 0x20000000
if (nversion & BIP9_TOP_MASK) == BIP9_TOP_BITS:
if bool(nversion & (1 << BIP110_BIT)):
signaling += 1
sample_size = len(blocks[:num_blocks])
return
"sample_size": sample_size,
"signaling": signaling,
"signal_percentage": round((signaling / sample_size) * 100, 2),
print(check_signaling_via_api())Official Responses and Community Perspectives
The rejection of BIP-110 is not simply a matter of technical feasibility; it is a deliberate choice by key participants in the Bitcoin network. The opposition to the proposal features prominent figures in the ecosystem who argue against the soft fork on governance, economic, and philosophical grounds.
The Governance Precedent: Michael Saylor and Adam Back
Industry leaders like MicroStrategy founder Michael Saylor and Blockstream CEO Adam Back have expressed strong skepticism toward consensus-level interventions for application-layer disputes.
Their arguments center on the following core principles:
- Protocol Neutrality: Bitcoin’s consensus layer should remain an objective, neutral referee. It should not distinguish between a transaction containing a financial settlement, a multisig setup, or an image of a digital artwork. Once the network begins censoring specific types of data, it risks losing its status as an unbiased global ledger.
- Slippery Slope of Censorship: If the community agrees to temporarily ban Ordinals via a soft fork, it establishes a precedent. In the future, governments or special interest groups could pressure developers and miners to implement "temporary" soft forks to ban other transaction types, such as privacy-preserving transactions or specific UTXOs.
- Market-Based Solutions: The correct way to manage block space congestion is through the free market. If Ordinals users want to occupy block space, they must pay the prevailing market rate. High fees will naturally price out low-value data stuffing, forcing Ordinals to migrate to Layer 2 networks or alternative storage systems.
The Miner Incentive Alignment
Miners have a direct financial incentive to reject BIP-110. Bitcoin’s security budget relies on block rewards (which halve every four years) and transaction fees. The fee boom catalyzed by Ordinals has provided a crucial revenue cushion for mining pools, particularly during periods of low market volatility. Forcing a restriction that destroys a highly active transaction class would directly harm miner profitability.
Implications: The Post-BIP-110 Era
As BIP-110 moves toward its inevitable expiration in August 2026, the Bitcoin network will experience several long-term implications.
1. The Validation of Economic Governance
The failure of BIP-110 proves that Bitcoin’s governance model is highly conservative and resistant to top-down changes. Even when developers write code to restrict perceived "spam," they cannot force it upon the network without the economic consent of miners, node operators, and users.
2. The Separation of Consensus Cleanup
With BIP-110 out of the picture, developers are focusing on the broader "Consensus Cleanup" efforts. Rather than targeting specific applications like Ordinals, these initiatives aim to patch genuine protocol vulnerabilities, such as quadratic hashing bugs or resource exhaustion attacks that could threaten network stability. These proposals are being handled independently to avoid conflating security with ideological debates over block space usage.
3. The Shift to Layer 2 and Fee Markets
The debate over Ordinals will not disappear, but it will be resolved through economic reality rather than hardcoded restrictions. As the block reward continues to diminish, the necessity of a robust fee market becomes paramount. Ordinals have demonstrated that demand for Bitcoin’s block space extends beyond simple peer-to-peer payments, positioning Bitcoin as a multi-faceted settlement layer.
Ultimately, the demise of BIP-110 reaffirms Bitcoin’s core value proposition: it is a decentralized, censorship-resistant network governed by mathematical consensus and market dynamics, entirely immune to hasty interventions.
