Introduction

The purpose of this article is to explain what BIP-110 is, outline the technical details, and highlight key arguments for and against it. The intent is to provide an objective and educational overview of this proposed change to Bitcoin.

This article is a sequel to our previous piece Putting History into Context: a reflection on Core vs. Knots. That article provides historical context to how we arrived at the current debate. In brief, it explains how, after the block size wars, the network chose to upgrade to SegWit (and later Taproot). These upgrades expanded Bitcoin’s transaction structure, improving scalability while also enabling new ways to embed non-monetary data in transactions. 

Most notably, this led to the emergence of ordinals and inscriptions using witness space, which opened the door for a novel method to post data, such as images directly onto the Bitcoin network. The article highlights that this wasn’t simply a “spam problem,” but the downstream result of earlier consensus changes, miner incentives, and network dynamics. 

It also highlights the important nuance between node policy and consensus rules. Nodes can filter which transactions they relay, but miners ultimately decide what gets mined (included in blocks). In today’s environment, where mining pools are relatively concentrated, the effectiveness of relay filtering is limited. Consequently, running a node with filters does little to prevent transactions that are valid under current consensus rules from being included in the timechain. 

While increasing transaction activity or diversifying block template creation could more effectively reduce so-called spam, much of the Bitcoin community has focused on node-software related solutions. This tension helped fuel the rise of Bitcoin Knots, a node implementation favored by users seeking stricter filtering and greater configurability.

To reiterate: node implementations do not change Bitcoin’s consensus rules, and therefore have limited impact on preventing these transactions. In response, an anonymous developer known as Dathon Ohm proposed a Bitcoin Improvement Proposal, BIP-110, a temporary change to Bitcoin’s consensus rules intended to restrict certain types of non-monetary transactions. The official BIP-110 website and GitHub repository provide further technical details.

Technical Details of BIP-110

In Bitcoin, rules can be changed if there is community consensus, but only under specific conditions. A rule change must ensure that older nodes continue to recognize new blocks as valid. New rules may further restrict what is considered valid, but they cannot allow anything that older nodes would reject. This kind of change is known as a soft fork. Both SegWit and Taproot are examples of softforks. 

If a change causes older nodes to reject blocks produced under the new rules, the network splits into two separate ledgers. This is known as a hard fork. While BIP-110 only restricts what is allowed, making it compatible as a soft fork, it also temporarily disables parts of Taproot that could be needed for future upgrades. For this reason, the author frames it as a one-year measure intended to reduce data-embedding methods while giving the network time to develop a better long-term solution.

According to the author’s specification, the deployment, named reduced_data, temporarily enforces the following rules to the network:

• Limits new output scriptPubKeys to 34 bytes
  • except OP_RETURN outputs, which may be up to 83 bytes
• Limits OP_PUSHDATA* payloads to 256 bytes
• Limits script-argument witness items to 256 bytes
  • except the BIP16 redeemScript push in scriptSigs
• Makes spending undefined witness versions invalid
  • except defined spends such as Witness v0, Taproot, or P2A
  • creating outputs with undefined versions remains valid
• Makes Taproot annex usage invalid
• Limits Taproot control blocks to 257 bytes
  • roughly equivalent to a Taptree of up to 128 script leaves
• Makes any Tapscript containing OP_SUCCESS* invalid
  • even if unexecuted
• Makes executed OP_IF and OP_NOTIF invalid in Tapscript

In general, BIP-110 restricts much functionality of Taproot, and therefore largely affects very specific users of Taproot. 

Before exploring the arguments for or against BIP-110, it is important to understand how such an upgrade would be activated.

BIP-110 uses Bitcoin’s standard soft-fork activation mechanism (a modified version of BIP9), where miners signal support by setting bit 4 in the version field of the blocks they mine. Bitcoin counts those signals over each 2,016 block difficulty period (approximately two weeks). If at least 1,109 of 2,016 blocks (55%) signal support, the proposal becomes LOCKED_IN, and activates one difficulty period later. 

BIP-110 starts signaling on December 1, 2025, and includes a special mandatory signaling window from block 961,632 to 963,647. During this period, BIP-110 nodes reject blocks that do not signal bit 4, ensuring lock-in by block 963,648 and activation by block 965,664 (estimated around September 1, 2026). 

This window effectively forces signaling behavior by treating non-signaling blocks as invalid for nodes enforcing BIP-110. From another point of view, if BIP-110 is not getting support, this will result in BIP-110 Knots nodes having an incorrect understanding of the Bitcoin ledger from block 961,632 onward. At the time of writing, Knots nodes constitute roughly 22% of the network (source).

Critics would point out a small caveat to this number though, as Bitcoin nodes are not sybil-resistent. Meaning, because it is very cheap to create a Bitcoin node, it can be hard to determine if a node count is one individual creating many of them. Here is a link to a website that attempts to ascertain the degree at which this is occurring, and the data here suggests that many BIP-110 nodes may be operated by a small number of entities, although this concern is less pronounced for Knots or Core nodes. 

Below is a graph of all three node types (Core, Knots, BIP-110) over time (Source: Jameson Lopp X Post).

All this is to say that, in order for this BIP-110 to take place, it would require 55% of active mining hashpower to signal support. The hard deadline for when miners must show support is the two-week window before September 2026. 

You can view the status of this signaling here. 

Discussions around BIP-110

What is its Intended Purpose?

Let us now explore the arguments for and against BIP-110. 

In short, the purpose of this proposal is to limit the ability of users of the network to create transactions that contain non-monetary data, such as images through inscriptions. It does so by limiting how much data can be included in transactions (like capping OP_RETURN and other data fields), limiting certain advanced Taproot features, and disabling  specific scripting opcodes in Tapscript (such as OP_IF, OP_NOTIF, and OP_SUCCESS*). 

These specific restrictions are aimed towards limiting the ability for users to post ordinals, which embed images into transactions via Taproot witness structures, typically using OP_PUSHDATA (often wrapped in OP_IF structures). This is the central purpose of BIP-110: to temporarily limit the inscription of ordinals while the network evaluates longer-term solutions.

It is important to note, however, that restricting the current method of ordinals does not necessarily stop users from being able to post images on a BIP-110 compliant network. Notably, an X account named Martin Habovštiak posted an image to the network, demonstrating that an image could still be embedded within the constraints of BIP-110. As a result, some critics argue that this kind of upgrade is ultimately ineffective in trying to stop this type of activity on the Bitcoin network and is akin to a game of wack-a-mole. 

On the other side of the argument, proponents of BIP-110 do not claim that all methods are prohibited. Rather they argue that a temporary restriction provides the network time to develop more robust solutions. The urgency behind this proposal is also influenced by concerns about illicit imagery being etched permanently onto the network. 

Would BIP-110 Violate Property Rights?

One of the more debated concerns around BIP-110 is whether it could “freeze” someone’s bitcoin or prevent them from spending it, thereby violating their property rights. 

The proposal does not delete or confiscate funds. However, in very specific circumstances, it could make certain coins temporarily unspendable while the rules are active. This would only happen if a user’s coins rely on a script that BIP-110 disables and there is no other way to spend them. For that to occur, all of the following would need to be true:

• The coins are held in a Taproot (P2TR) address
• The spending path being used relies on restricted features (like OP_IF or certain script structures explained above)
• There is no alternative way to spend the coins (no keypath or other valid script path)
• The user is trying to spend them while BIP-110 rules are active

If any of these conditions are not met, the funds remain spendable. 

The proposal also includes a safeguard: UTXOs created before activation are exempt from the new rules. This means existing coins can still be spent, even if they use patterns that would later be restricted. 

However, critics highlight a practical concern. Users interact with wallets, not UTXOs. So, if a user continues using the same wallet after activation that was using these script structures, any new outputs (like change addresses) created under the new rules could potentially still be affected if they inherit the rules of the original UTXO, even when the original UTXO was exempt. 

Is there a Risk of a Chain Split?

Lastly, there is also concern surrounding the potential of a chain split for Bitcoin.

A chain split occurs when different parts of the network begin to follow different versions of the blockchain due to disagreement over which rules are valid. This is most commonly associated with hard forks. However, as explained earlier, BIP-110 introduces restrictive changes, meaning it falls under the classical categorization of a soft fork, where upgraded nodes enforce stricter rules while older nodes can still accept those blocks as valid. 

That said, the method of this soft fork’s implementation has raised concern, as it differs from how previous soft forks have been deployed.

In prior Bitcoin soft forks (like SegWit), activation typically followed a process where miners signaled readiness and the network only activated once there was overwhelming support (usually ~95%). During that process, non-signaling blocks were still accepted. Accordingly, the proposal could simply fail to activate if enough miners didn’t opt in. This made activation relatively low-risk: by the time rules turned on, there was already broad coordination across miners, nodes, and the ecosystem, reducing the chance that different groups would follow different chains. 

It is worth noting that SegWit’s activation (BIP-141) was not purely passive. BIP-148 introduced a user-activated enforcement phase (which was to be activated on August 1st 2017) where nodes rejected non-signaling blocks, because the adoption of SegWit was being stalled by miners. This was designed to provide added pressure on miners to coordinate, but it occurred alongside strong ecosystem alignment and high eventual signaling thresholds. However, it is still a matter of debate on whether or not this enforcement played much of a role in the adoption of SegWit as nodes running BIP-148 were potentially a smaller percentage of total nodes. For example, this source states that half a month before its activation, BIP-148 nodes were only 13% of reachable nodes.

Furthermore, BIP-91 was introduced as a separate coordination mechanism that aimed to avoid the potential chaos of the user-activated soft fork (UASF) of BIP-148, and ultimately played a decisive role in SegWit’s activation. Proposed as a miner-activated soft fork (MASF), BIP-91 lowered the effective signaling threshold to 80% over a much shorter 336-block window (roughly 2–3 days), allowing miners to more quickly coordinate. Once activated, BIP-91 nodes would reject any blocks that did not signal for SegWit (BIP-141), creating a strong economic incentive for all miners to begin signaling or risk having their blocks orphaned. In effect, BIP-91 did not activate SegWit directly, but instead forced alignment toward the original 95% BIP9 threshold, acting as a bridge between stalled miner signaling and the looming BIP-148 UASF. 

In July 2017, BIP-91 rapidly gained support and locked in, after which nearly all blocks began signaling for SegWit, allowing it to officially lock in by early August and fully activate later that month. This sequence of events is often credited with helping the network avoid a more contentious chain split by aligning miner incentives before BIP-148’s enforcement took full effect.

BIP-110 differs because it lowers the signaling threshold to 55%, allowing activation with significantly less agreement. Furthermore, it introduces a mandatory signaling window, where nodes enforcing BIP-110 will reject blocks that do not signal support, even before full activation. 

This creates a more aggressive coordination mechanism: it is a UASF similar to BIP-148. As a result, if a meaningful portion of miners does not comply, or if support fluctuates around the threshold after activation, there is a higher chance that different parts of the network temporarily follow different chains. 

While one chain will win out based on majority hashpower, this approach increases the risk of short-term instability compared to previous soft fork activations. 

A hypothetical situation could play out as follows: 56% of miners signal BIP-110 readiness during the mandatory signaling window. BIP-110 nodes would reject all blocks not signaling for BIP-110. Let us assume, for the sake of argument, that BIP-110 nodes are still a minority of all nodes. Bitcoin nodes follow the most-work chain that they consider valid. If BIP-110-supporting miners produce the majority of blocks, then both classic nodes and BIP-110 nodes would initially follow this chain (Chain B). 

Suppose this continues for 100 blocks. Now imagine some of those miners go offline, and miners not signaling BIP-110 regain majority hashpower. These miners begin extending Chain B (becoming Chain A) with blocks that do not signal bit 4. Classic nodes will follow Chain A, since those blocks are valid under their rules and it has the most work. However, BIP-110 nodes will reject those blocks entirely and continue following Chain B, even if it grows more slowly.

If hashpower continues to fluctuate, it is theoretically possible for Chain B to later regain majority and overtake Chain A, causing a reorganization where classic nodes switch back to Chain B and rewrite recent transaction history. 

In practice, however, prolonged instability is unlikely. Mining is unfortunately highly centralized with Foundry and Ant Pool controlling most hashpower. Economic incentives strongly encourage miners to converge on a single chain quickly to avoid wasting resources on invalid or orphaned blocks. As a result, while short-term divergence and reorganizations are plausible in a contentious activation, the network would most likely stabilize around a single dominant chain. 

Concluding Remarks

Bitcoin is the one of the most important invention of our time. It is a seat of power in our dynamically changing world. This war over the future of Bitcoin, like the Block Size Wars, is not the first time where bitcoin has been attacked, and it will not be the last. 

Bitcoin is the most resilient computer science invention in history. Its code and the energy that secures it are robust. However, the humans who steward and interact with it remain susceptible to influence and error. 

We live in an age where war and the competition of resources are not fought solely with kinetic violence, but with information as well. Cryptography and the computer were born out of the realization that information shapes outcomes. Today, information itself plays a major role in deciding who wins and who loses. 

Bitcoin is at the heart of this modern battlefield. 

Post-Script

It is the author’s sincerest intention that this article proved helpful in providing an educational and unbiased view on the current debate. As you reflect upon how you yourself should move forward, please forgive one moment of the author’s personal reflections.

Consider the ancient roman tactic divide et impera (divide and rule). This tactic is similarly shared in the Art of War by 孙子:

“If his forces are united, separate them”

As previously stated, while the code and energy supporting Bitcoin is incredibly difficult to attack, human coordination is far more fragile.

“So in war, the way is to avoid what is strong and to strike at what is weak.” – 孙子

Many of us spend much of our time attached to our phones, absorbing information from social media that is constantly being manipulated and doctored by external forces. Flames can be stocked, ideas can be magnified and silenced at will, all the while our interpretation of reality and therefore our actions are gently guided by those who wish to stir conflict. 

“All warfare is based on deception” – 孙子

Additional References

Tzu S. The Art of War. Shambhala Publications, Incorporated; 2011.