What Was BIP 110 Trying to Do?
BIP 110 was called the Reduced Data Temporary Softfork. It proposed temporarily restricting several ways that arbitrary data could be embedded in Bitcoin transactions.
The basic idea was that Bitcoin was designed primarily as a monetary network, while some users had begun using Bitcoin block space to store arbitrary data such as images, text, and token-related information.
BIP 110 therefore proposed restricting some of the mechanisms that allowed large amounts of arbitrary data to be stored on-chain.
Importantly, it did not directly attempt to eliminate Ordinals themselves. Ordinal theory was software that assigned individual identities to satoshis and tracked them according to rules applied to the Bitcoin blockchain.
The important question was:
Where was the actual data being stored?
To understand that, it helped to go back to SegWit and Taproot.
SegWit — BIP 141
In 2017, Bitcoin activated Segregated Witness (SegWit) through BIP 141, which was a soft fork.
SegWit created a separate witness structure containing information needed to validate transactions, including signatures and scripts.
SegWit also introduced Bitcoin's modern block-weight system.
Instead of simply saying that every block could contain 1 MB of data, Bitcoin began measuring blocks in weight units.
The maximum block weight became:
4,000,000 weight units.
Witness data received a lower weight in that calculation than ordinary transaction data.
That distinction later became very important because it made certain types of data storage more economical.
Taproot — BIPs 340, 341 and 342
In 2021, Bitcoin activated Taproot through BIPs 340, 341 and 342. These were also soft-fork changes.
Taproot introduced new ways of constructing and spending Bitcoin outputs using Taproot scripts.
One consequence was that substantial amounts of arbitrary data could be placed into Taproot script-path witness data.
That became particularly important for Ordinal inscriptions.
So the sequence was:
SegWit → witness data and the witness discount
then:
Taproot → additional scripting capabilities
and later:
Ordinals → use of those existing capabilities to store inscriptions.
OP_RETURN — Bitcoin's Data Field
Another place people could put data was OP_RETURN.
A simple way to think about OP_RETURN was as a kind of memo/data field in a Bitcoin transaction.
It allowed a transaction to carry a small amount of information that did not represent a spendable Bitcoin output.
This became particularly important for Runes.
Runes
Runes were a protocol for creating fungible tokens on Bitcoin.
Unlike Ordinal inscriptions, Runes used OP_RETURN to encode their protocol instructions.
So the relationship looked roughly like this:
Bitcoin transaction → OP_RETURN → Rune protocol data → Runes
The Rune itself was not a native Bitcoin coin. Compatible software interpreted the transaction data according to the Rune protocol.
This meant that if OP_RETURN data limits were tightened, that could affect how Runes used Bitcoin block space.
Ordinals
This brings us to Ordinals.
Ordinal theory gave individual satoshis an identity and provided a system for tracking them as they moved through Bitcoin transactions.
It could be thought of roughly as giving every satoshi a serial number.
An important distinction was that Ordinals did not require inscriptions.
The Ordinal system could track individual satoshis without putting an image or other arbitrary data on them. Ordinals are a separate system, outside of Bitcoin, that tracks satoshis.
Inscriptions
An inscription is where additional data was associated with a satoshi.
That data could have been:
- An image
- Text
- HTML
- SVG
- Or other arbitrary content
The content is represented by bytes and stored in the witness portion of a Taproot transaction.
This was where the SegWit → Taproot → Ordinals connection became important.
The sequence was:
SegWit (2017)
↓
Created the witness structure and witness discount
↓
Taproot (2021)
↓
Created additional Taproot script-path capabilities
↓
Ordinals (2022–2023)
↓
Used those existing Bitcoin features
↓
Inscriptions
↓
Stored arbitrary content in Taproot witness data
The inscription data could be divided among multiple data pushes, allowing larger files to be stored across the witness portion of a transaction.
BRC-20 Tokens
BRC-20 took the idea one step further.
BRC-20 was a token protocol built on top of Ordinal inscriptions.
A BRC-20 inscription could contain instructions interpreted by BRC-20 software to:
- Deploy a token
- Mint tokens
- Transfer tokens
Bitcoin itself did not recognize a BRC-20 token as a native Bitcoin asset.
Instead, BRC-20-compatible software read the inscriptions and maintained token balances according to the protocol's rules.
The relationship was therefore:
Bitcoin
↓
Ordinals
↓
Inscriptions
↓
BRC-20
↓
Fungible tokens
Bitcoin Stamps
Bitcoin Stamps took a different approach to storing data.
Instead of relying primarily on the Taproot witness mechanism used by Ordinal inscriptions, Stamps embedded data into Bitcoin transaction outputs, particularly through multisig-based techniques and Counterparty-related formats.
So there was an important distinction:
Ordinals/Inscriptions → witness data
while:
Stamps → transaction-output data
That distinction mattered when looking at what BIP 110 was trying to restrict.
What Was BIP 110 Actually Trying to Restrict?
BIP 110 did not say:
"Ban Ordinals."
And it did not say:
"Ban Runes."
Instead, it proposed restrictions on several of the mechanisms used to put arbitrary data into Bitcoin transactions.
Among the proposed restrictions were:
-
New
scriptPubKeys over 34 bytes were restricted, with an exception for OP_RETURN outputs up to 83 bytes. -
Certain
OP_PUSHDATApayloads and witness stack elements over 256 bytes were restricted. - Certain undefined witness versions were restricted.
- Taproot annexes were prohibited.
- Certain large Taproot control blocks were restricted.
- Certain Tapscript constructions were restricted.
The overall objective was to make it substantially harder to embed large amounts of contiguous arbitrary data in Bitcoin transactions.
How Would That Have Affected Inscriptions?
This was probably the most important part.
An inscription could contain a large image because the inscription data could be divided into multiple witness data pushes.
Under BIP 110's proposed rules, individual witness data elements over 256 bytes would have been restricted.
That did not mean:
"Ordinals disappear."
The Ordinal numbering system could still exist.
Instead, the question would have become:
How could someone put a large image onto the blockchain using the remaining permitted structures?
BIP 110 therefore targeted the data-storage mechanism, rather than directly targeting the concept of an Ordinal.
Someone could potentially divide data into smaller pieces, but the proposal was intended to make arbitrary-data storage more difficult.
The Big Picture
The history could be summarized this way:
2017 — SegWit / BIP 141
Bitcoin introduced the witness structure and block-weight accounting.
Witness data received a discount in block-weight calculations.
2021 — Taproot / BIPs 340, 341 and 342
Bitcoin introduced new Taproot spending and scripting capabilities.
Those capabilities could carry substantial witness data.
2022–2023 — Ordinals and Inscriptions
People developed software that tracked individual satoshis and used Taproot witness data to associate arbitrary content with them.
Images, text, and other data could be stored directly on-chain.
BRC-20
People used Ordinal inscriptions to create a protocol for fungible tokens.
Runes
A different token protocol used OP_RETURN to encode its instructions.
Bitcoin Stamps
Another approach stored data in transaction outputs, using techniques associated with Counterparty.
BIP 110
BIP 110 proposed restricting several of the underlying mechanisms used to store arbitrary data:
large witness/data pushes + large output scripts + certain Taproot mechanisms + larger OP_RETURN data
The goal was to temporarily reduce arbitrary-data storage on Bitcoin while preserving normal monetary transactions.
One Important Distinction
The easiest way to understand the entire issue was to separate Ordinals from inscriptions.
Ordinals: the system for identifying and tracking individual satoshis.
Inscriptions: arbitrary data associated with those satoshis.
So when people argued about "Ordinals spam," the actual block-space issue was primarily the inscription data, not the act of assigning numbers to satoshis.
That distinction was central to understanding what BIP 110 was trying to change.
