It started with a dispute about JPEGs, Ordinals and OP_RETURN. Today, it’s about something much bigger: who really decides the rules of Bitcoin. The controversial BIP-110 is approaching the point where some nodes may start rejecting blocks accepted by the rest of the network. Less than 200 blocks left to reach the key border.
Bitcoin is facing one of the most interesting tests of its consensus model in years.
At the time of writing this text, the network was at altitude 961 438. BIP-110 begins its most controversial phase on the block 961 632. This is only a 193-block difference, or at a normal mining rate, approximately several dozen hours.
The numbers are even more interesting. In the current difficulty adjustment period, BIP-110 was signaled by 47 out of 1,823 mined blocks, i.e. approximately 2.58%. The threshold required for a standard lock-in is 55%.
At this stage, achieving it before the end of the period is mathematically impossible.
And yet the story of BIP-110 does not end there.
The riskiest part begins now.
BIP-110 was supposed to stop “spam” on Bitcoin
BIP-110, formally named Reduced Data Temporary Softforkwas prepared by Dathon Ohm. The original draft and technical advice was credited to Luke Dashjr, a long-time Bitcoin developer and lead maintainer of Bitcoin Knots.
The purpose of the proposal is stated clearly:
Bitcoin is intended primarily as money, not as a decentralized hard drive.
The changes would be valid for approximately one year, 52,416 blocks to be exact, and then expire automatically.
However, this is much more than a simple “JPEG ban”.
BIP-110 limits new scriptPubKey up to 34 bytes, except OP_RETURN up to 83 bytes. It also introduces a 256 byte limit for some data in scripts and witnesses, restrictions on Taproot, blocks the use of some mechanisms intended for future updates, and prohibits the execution of OP_IF and OP_NOTIF in Tapscript.
In other words: the proposal actually makes it harder to save large data, but at the same time it touches on some more advanced ways of using Bitcoin scripts.
And this is where the problem begins.
It all started with Bitcoin Core 30
The background to the entire conflict is the change introduced in Bitcoin Core 30.
Earlier versions of the software limited the size of the data passed through OP_RETURN by default. In Core 30 parameter -datacarriersize was increased to 100,000 bytes by default, which effectively removed the previous limitation at the relay policy level. The new version also allowed multiple OP_RETURN outputs to be passed in one transaction.
What is very important, it was not a change to the Bitcoin consensus rules.
Larger OP_RETURN transactions could have entered blocks earlier if the miner chose to include them. Core 30 mainly changed the default rules for transmitting such transactions between nodes and creating block templates. User can still set -datacarriersize=83.
However, for some of the community, changing the default setting alone went too far.
BIP-110 is the answer to this dispute, but it takes it a level higher. Instead of filtering unwanted transactions locally, the proposal wants to recognize some of them as incorrect at the consensus level.
That’s a huge difference.
55% will no longer be there. Now the game for everything begins
Normally, BIP-110 was expected to reach the 55% threshold, or 1,109 signaling blocks in one period of 2,016 blocks.
That didn’t happen.
The current result of approximately 2.6% means that a voluntary lock-in before block 961,632 is no longer possible.
However, the creators of BIP-110 provided a mechanism resembling User Activated Soft Fork. From the height 961 632 to 963 647 BIP-110 enforcement nodes are to discard any blocks that do not signal support via bit 4.
If everything went according to the authors’ plan, it would lead to a lock-in at block 963,648 at the latest, and the actual new rules would start operating from block 965,664.
On the BIP110.org website, this mechanism is presented as “mandatory signaling”, which guarantees lock-in.
But there’s a major catch.
BIP-110 cannot force miners using other software to follow these rules.
It can only make it BIP-110 nodes will stop accepting their blocks.
And that’s exactly why the next few days are so interesting.
Can Bitcoin Really Divide?
Let’s imagine that after reaching block 961,632, a large mining pool creates a block without a corresponding signal.
For a standard Bitcoin Core node, such a block may be completely valid.
For the enforcing node, BIP-110 will be invalid.
If additional miners start building on this block, the majority network will continue its work. BIP-110 nodes will wait for an alternative block that complies with their rules.
In this way, two different blockchain stories can emerge.
This does not automatically mean the creation of two equivalent “Bitcoins”. If the vast majority of hashrate, exchanges, services and users stay on one side, the second chain may be of marginal importance and produce blocks very slowly.
Given the current level of signaling, this scenario is one of the main arguments of BIP-110 critics.
Jameson Lopp, Adam Back and other opponents of the proposal have argued for months that trying to force changes with little support could create greater risks than the problem BIP-110 tries to solve.
Michael Saylor went even further. He published the list in July “110 reasons why BIP-110 is a bad idea”openly opposing change.
But BIP-110 supporters see it completely differently
The other side of the argument argues that this is why their own nodes exist.
If the user considers certain rules to be appropriate, he or she has the right to run software that will enforce them. According to this logic, miners should not unilaterally decide what rules apply to the network.
This is an argument well known from Blocksize Wars and SegWit activation.
BIP-110 supporters therefore hope that the risk of blocks being rejected by thousands of nodes will encourage mining pools to start signaling at the last moment.
The OCEAN pool supports BIP-110 signaling capabilities, and Foundry has decided to defer the decision to its customers by running voting weighted by the hashrate provided.
For now, however, there is no data indicating a massive change in the attitude of miners.
BIP-110 is also not a perfect “spam filter”
There is one more thing worth paying attention to, which is easy to forget in the political part of this discussion.
The authors of BIP-110 themselves admit that the proposal it cannot completely eliminate the storage of arbitrary data in Bitcoin.
Data can be divided into smaller fragments, encoded in a different way, or hidden in structures that look like normal financial data.
BIP-110 is primarily intended to increase the cost and impede the most obvious ways of using blockchain as a data store.
There is also a price for this.
The specification acknowledges that limitations may complicate the operation of experimental solutions using Taproot and more advanced designs such as BitVM. There are also very specific scenarios related to previously signed Taproot transactions where funds could be temporarily frozen.
The authors assess the probability of such cases as low, and UTXOs created before the activation of the new rules have been subject to the grandfathering principle and remain exempt from restrictions.
The most interesting thing about BIP-110 is not the Ordinals
JPEGs, inscriptions and OP_RETURN are only the surface of this conflict.
The real question is different:
what should happen in Bitcoin when some users consider a given activity harmful, but others do not want to change the consensus rules?
Bitcoin has no board of directors, no CEO, and no official shareholder vote.
Developers can write the code. Node operators can either enable it or ignore it. Miners choose software and transactions to place in blocks. Exchanges and users decide which chain they assign economic value to.
BIP-110 just pits all these groups against each other.
With 2.58% signaling, it is difficult to talk about broad support for miners today. At the same time, the proposal mechanism means that the lack of support does not simply lead to the peaceful extinction of the idea.
From block 961 632, part of the network will start playing according to different rules.
Therefore, the next few hundred blocks can say much more about Bitcoin’s governance than the entire “spam” dispute that lasts several months.
And paradoxically, this may prove to be BIP-110’s most important legacy, regardless of whether the soft fork itself ultimately survives.
