Debate is intensifying within the cryptocurrency community regarding BIP-110, a proposal aimed at limiting the inclusion of non-transaction data, such as images and text, in the Bitcoin blockchain for a year. Supporters frame this initiative as a means to combat spam.
Data from BIP-110 Monitor shows that support for the proposal has remained below 1.5% over the past eight months. While this may suggest a lack of interest, the activation mechanism has been designed to circumvent the influence of miners, allowing the restrictions to come into effect in early August, albeit not across the entire network.
Interestingly, notable figures such as Michael Saylor, Adam Back, and Samson Mow, CEO of JAN3, have voiced strong opposition to the soft fork, raising concerns that seem far removed from any sympathy for spammers.
Critics of BIP-110 present multiple arguments against the initiative. Some highlight a possible flaw in the activation mechanism that could lead to chain divergence, while others have demonstrated that the proposed restrictions can be bypassed; for example, a Slovak developer successfully recorded an image in the blockchain despite the proposed limitations.
Let's delve into the industry’s concerns surrounding this proposal.
Seven Restrictions for One Year
Proposals for Bitcoin enhancements have existed since 2011, aiming to formalize the process for making significant code changes to the leading cryptocurrency.
The draft, officially titled Reduced Data Temporary Softfork, was submitted by a developer using the pseudonym Dathon Ohm to the repository on October 24, 2025. After a month and a half of discussion under the code BIP-444, it was designated as BIP-110 on December 3.
On June 25, 2026, version 1.0.0 received the status of Complete, meaning the authors have concluded their work and recommend its acceptance. However, this status does not imply community consensus, as the repository explicitly states.
The soft fork introduces seven restrictions for approximately one year:
- New recipient addresses (scriptPubKey) cannot exceed 34 bytes, with an exception for 83 bytes for OP_RETURN;
- Data chunks and witness elements can be up to 256 bytes;
- Prohibition of Taproot annex, a reserved field of unlimited size for future extensions that has never been utilized;
- Refusal to process Tapscript with OP_SUCCESSx opcodes, which were left as a placeholder for future soft forks;
- Prohibition on spending outputs with undefined witness and Tapleaf versions, although creating such outputs remains permissible;
- Control block — a script component with proof of path — must not exceed 257 bytes, limiting nesting to seven levels;
- Executable OP_IF and OP_NOTIF are prohibited within Tapscript.
Coins held in addresses created prior to the implementation of these new rules will not be affected by the restrictions, allowing for their use as before. This caveat is often overlooked in discussions about BIP-110, yet it alleviates the primary fear that the document would confiscate existing funds.
This rule, however, is ineffective in one scenario. Certain schemes are structured so that transactions are prepared in advance and sent months or even years later — for instance, multi-signature constructions with delayed execution. If such a transaction is created under old rules but sent during the year of restrictions, the funds may become inaccessible. Owners of such schemes are advised to transfer their coins in advance.
To understand the nature of the conflict, one key opcode is crucial.
OP_RETURN was introduced in Bitcoin Core 0.9.0 in 2014 as a safer alternative for embedding messages in the blockchain. Prior to this opcode, the only way to leave a message in the chain was to send coins to an address for which no one had the key, effectively burning the coins while preserving the text.
The issue was not the lost Bitcoins; rather, each such operation created a record in the set of unspent outputs, which the entire network must maintain. OP_RETURN allowed data to be marked as unspendable, meaning it did not need to be stored.
Initially, the limit was set at 40 bytes, then increased to 80 bytes in 2015, and finally to 83 bytes in 2016. The limit was intentionally kept low: it was sufficient for a hash but not for the entire document.
In October 2025, Bitcoin Core developers released version 30, raising the limit from 80 bytes to 100,000. This change prompted a segment of the community to shift to an alternative client, Bitcoin Knots, resulting in the current disagreements.
Most disputes center not around the restrictions themselves but rather the method of their activation.
Cannot Cancel, Only Activate
BIP-110 employs a modified version of BIP 9 — the standard procedure by which miners signal readiness for an update by setting a specific bit in the header of the mined block. There are three key changes, all of which reduce the dependence of activation on miner consensus.
Activation Threshold. Under BIP 9, a soft fork is considered approved if 95% of blocks signal support within a difficulty adjustment period. The threshold in BIP-110 has been lowered to 55%, or 1109 out of 2016 blocks.
Activation Mechanism. Initially, miners can signal support voluntarily. This is followed by a mandatory phase: nodes updated to BIP-110 will stop accepting blocks that do not have bit 4 set.
If nodes transition to the new chain, final activation of BIP-110 is expected no later than block #963,648, with the restrictions coming into effect around block #965,664.
Unsuccessful Activation Scenario. Currently, if a proposal fails to gain necessary support within the allotted time, it receives a FAILED status and is considered rejected.
BIP-110 does not include such a scenario: even after the voluntary phase ends, the update can proceed to mandatory activation if node operators support it.
Saylor, in point 86 of his essay, argues that the authors of BIP-110 have eliminated the "emergency exit": a proposal that fails to gather support should automatically cease to be valid without forced coordination.
This logic was borrowed from UASF — a user-activated soft fork. In 2017, a small portion of node operators declared they would reject blocks without support for SegWit, leading to widespread signaling by miners and the activation of the soft fork.
This episode serves as a key argument for both sides in the BIP-110 debate. Some see it as evidence that the economic majority can impose its will on miners, while others view it as a warning: if the tool worked once, a minority could use it for a far more contentious purpose.
Exact dates for this schedule cannot be specified: miners typically produce blocks roughly every ten minutes, but the interval varies, making any number here approximate. Different sources suggest the start of the mandatory phase could be August 9 or mid-August, with a week’s variation being normal.
Timer until the start of the mandatory phase. Source: BIP-110 Monitor.23 Blocks
The first to signal support for the initiative was not a mining pool, but an individual. On March 1, 2026, a solo miner under the alias Barefoot Mining mined a block signaling support for BIP-110 through the Ocean pool's infrastructure.
This was made possible by the DATUM protocol, which allows Ocean clients to create their own block templates without coordination with the pool operator. The Ocean pool itself does not apply BIP-110 rules, meaning Barefoot Mining’s signal represents a personal stance rather than a decision by the pool’s management.
By mid-April, the situation had barely changed. During difficulty adjustment period #467, only three out of 1840 mined blocks signaled support for BIP-110, all through Ocean. Major pools such as Foundry, AntPool, F2Pool, ViaBTC, Marathon, and Luxor did not submit any signals.
Only one major player publicly expressed their opinion — F2Pool co-founder Wang Chun categorically opposed the initiative.
The highest support came during the concluded period #475: 23 blocks, or 1.2% of the total. However, even this record fell significantly short of the required 1109 blocks (55%). The new difficulty adjustment period starting on July 27 has yet to yield any signals of support.
Graph showing miner support dynamics for the new rules. Source: BIP-110 Monitor.When considering hash rate rather than the number of blocks, support for BIP-110 appears even more limited. By the end of June, approximately 5 EH/s out of a total network power of 940 EH/s supported the initiative. The largest pool, AntPool, with a share of around 14%, did not submit any signal.
In contrast, node support is significantly more pronounced. The share of Bitcoin Knots increased notably in the first months of the year, estimated to range from 8% to over 20% of all publicly accessible nodes in the network. Developer Jameson Lopp suggests a likely reason: many nodes are set up via Tor, almost for free and in any quantity, making it easy to inflate raw numbers.
Hash rate and node support diverge. Large pools do not signal bit 4 — and for them, this is a position, not inaction. Meanwhile, some node operators are transitioning to Bitcoin Knots, which is prepared to implement the new rules.
Foundry Poses the Question Directly
Instead of immediately taking a position on BIP-110, Foundry USA decided to consult its clients first. On July 21, the largest pool published an analysis of the arguments from both supporters and opponents of BIP-110 on its website. The next day, an email voting form was opened there.
The voting scheme almost predetermines the outcome. Each client's vote is weighted by their average hash rate over the past ten days — from July 6 to 15. Silence is counted as "no." The pool promises to change its signal to "yes" only if supporters reach 51% of the total votes.
The window for voting closes at block #961,632 — the same height where the mandatory signaling for BIP-110 is scheduled to start. This coincidence is not accidental: the pool needs to decide by this point.
Foundry’s share of the network hash rate exceeds 22%. This marks the most significant public gesture in the eight months of observation, as a major player has formally asked its clients rather than remaining silent.
With typical turnout for such polls, achieving 51% hash rate is mathematically challenging — it’s not merely an ideological issue. The silent majority automatically strengthens the "against" camp.
Foundry has not publicly disclosed the results — neither turnout nor interim counts. The inclination of clients will only be revealed post-factum: if the pool changes its signal, it will be noticeable on monitoring tables before any official announcement.
Crying Luke Dash Jr.
On February 27, 2026, Slovak programmer Martin Habovštiak tweeted that the Bitcoin network mistakenly accepted his "complete image file" as a transaction without OP_RETURN — and now the file will forever remain in the blockchain.
The hexadecimal code of the transaction decodes into a 66 KB TIFF file. The image features Crying Luke Dash Jr., one of the main proponents of BIP-110.
Technically, it bypasses all three vectors identified by the soft fork's authors as critical: OP_RETURN is absent, SegWit v0 is used instead of Taproot, and the OP_IF opcode is not utilized.
Later, Habovštiak explained that he wanted to test one of the key arguments of BIP-110 supporters. They claim that a full node operator could face legal risks if illegal content is stored on their computer within the blockchain. This leads to the conclusion that the size of individual data elements should be limited enough to prevent the placement of substantial illegal content. The programmer called this line of reasoning absurd.
There is a detail easily overlooked. BIP-110 is promoted not just as a battle against spam but also as legal protection for node operators. This argument is less frequently raised in discussions about the soft fork compared to "spam" — and it was precisely this argument that the developer sought to refute through his experiment.
Habovštiak referred to his action as a one-off and refused to publish the code — stating he wanted to avoid provoking "a new wave of NFT shitcoins" in Bitcoin. He emphasized that he dislikes spam but despises lies even more. However, he believes that those wishing to clutter the network will always find a workaround: in his view, most protective measures only create new issues.
According to data from TheBitcoinPortal, by early March, around 8.8% of nodes were signaling support for BIP-110 .
Not Just About Spam
None of BIP-110's critics defend the inscriptions in the blockchain; their objections are directed at the method, not the content.
Adam Back first expressed his opinion on February 15, stating that the initiative undermines Bitcoin's reputation as a store of value and resembles a "lynch mob" — an attempt to force changes without collective agreement. He described spam as an irritating factor that fits within the block size limit and does not threaten the network. At that time, about 7.5% of nodes were signaling support — almost exclusively on Bitcoin Knots.
The dispute reignited on July 22 when the infrastructure company Start9 invited miners to simply toggle a bit: according to their estimates, this would cost about 0.1% of annual revenue, while refusal could lead to a chain split and loss of paying users.
Back responded succinctly: "Don’t toggle the bit, and nothing will happen," labeling the entire campaign as a manifestation of idiocracy. In response to accusations of "cyclicality" in reasoning, he referred to the practices of IETF — the international organization that develops internet standards — where only substantiated technical objections are considered. He argued that no process can accommodate sabotage attempts; otherwise, it would be shaken by any coordinated group.
Samson Mow, CEO of JAN3, described the "1% attack" scenario on July 25: renting 1% of the network's hash rate and raising 3000 nodes. Prior to the fork, this would incur no costs — the equipment continues to mine Bitcoin as usual. Afterward, renting would cost approximately 4.5 BTC per day, and maintaining nodes would require $15,000 per month. According to Mow's calculations, the entry price is so low that responding to such scenarios would set a precedent for future actions.
The most concise formulation comes from analyst Axel Adler Jr., who stated that changing consensus should only occur when there is an objective technical necessity — a critical vulnerability, inflation risk, or a real security threat. BIP-110 in its current form "affects the neutrality of the network more than the problem warrants."
Voices in favor of the proposal are nearly silent. The only public argument came from Start9, asserting that inaction is riskier. No major pool, exchange, or investment firm has openly supported the initiative.
ChatGPT Found a Flaw
Imagine that the rules for entering a club have changed. The bouncer is now meticulously checking each arrival against an updated list. However, those who entered ten minutes ago are not being rechecked.
There’s nothing to complain about: the bouncer is acting strictly according to instructions. But the reality is that people who would not have been allowed in according to the new rules are already inside.
On July 18, a researcher using the alias Dathon Pwn published an analysis of just such a vulnerability — not in a club, but in the BIP-110 activation client.
Each node maintains a list of blocks it has already accepted and trusts this database upon restart. BIP-110 introduces new verification conditions that only activate when a node sees a block for the first time. Imagine an operator works on a standard client and accepts block B according to old rules. Later, they upgrade and activate BIP-110 on the same database. The record remains unchanged: it is still marked as legitimate, even though it was verified under the old rules.
The author illustrates this with an example. Alice's node operates without BIP-110 and accepts block B, which, under the old rules, is entirely legitimate. Later, Alice updates her client, and the new restrictions come into effect. Bob's node, on the other hand, applies them from the start. When he receives the same block B, he rejects it.
Alice and Bob's interaction, with software updated at different times. Source: Dathon Pwn's analysis.Both nodes now claim that BIP-110 is enabled, yet they disagree on which Bitcoin history is correct.
Such discrepancies could accumulate among various miner groups — it is sufficient to find a block that old rules accept but new rules reject. If several groups cement different such cases in history, the network risks fracturing into multiple incompatible chains.
The author did not demonstrate that any block in the actual Bitcoin network already violates BIP-110. The issue is not about bypassing Proof-of-Work, remote code execution, or database corruption. A node that consistently applied BIP-110 correctly rejected the fresh test block. The problem only concerns those who adopt the new rules retroactively.
Ultimately, one thing is confirmed. A client can enable BIP-110 and retain a history that it would reject upon re-validation.
SegWit had protections against such errors. A client remembered how it processed each block, checked this history upon each restart, and refused to start if re-validation was needed. The BIP-110 activation client lacks such protection.
The investigation began unusually. The author fed a commit with the activation code to ChatGPT 5.6 Sol and deliberately formed a "confident" prompt: "Is there a bug in the consensus in this code?" — not knowing in advance whether there is one or not.
The model's output was manually verified: the bug was reproduced on two builds, with and without BIP-110. A fresh node refused to start, and the database had to be rebuilt from scratch. The error occurred in three cases: with a block lacking the required activation signal, with a transaction exceeding the allowed size, and with a script exceeding the data limit. The author posted a draft fix separately.
The finding was decided to be disclosed before the beginning of August: major pools are already polling clients about their readiness to signal for BIP-110. Foundry is not the only example, but it is the most notable.
110 Objections from Saylor
On July 18, shortly after Dathon Pwn's analysis was published, Saylor released his own essay criticizing BIP-110. In eleven sections, he presents 110 objections — from arguments about network neutrality and fundamental Bitcoin principles to proposing an alternative approach.
It is unnecessary to delve into all the points in detail, but several arguments underpin his entire critique.
According to Saylor, the seven changes cannot be viewed in isolation: it is impossible to support some while rejecting others — the document demands acceptance as a single package (point 21).
The restriction of OP_RETURN to 83 bytes was a relay policy setting. It is now becoming a rule of block reality (point 23). This policy remains softer than consensus: a node can refuse to relay a transaction without declaring an entire block invalid (point 64).
The activation threshold has been lowered from the usual 95% to 55%, and there is no FAILED status for the document.
The most significant objection is saved for last: the rules will be in effect for a year and then removed, but the precedent for their acceptance will remain permanently (point 91).
He concludes with a pun. Saylor reinterprets the acronym BIP as Bitcoin Iatrogenic Proposal, borrowing the medical term "iatrogenic" — harm caused by the treatment itself. He ends his essay with the phrase: "Bitcoin does not need purity guardians. It needs neutrality guardians."
A separate point, number 100, addresses corporations. Their involvement is legitimate when it strengthens Bitcoin, but it does not grant special rights. It is also incorrect to consider them outsiders in the global monetary network.
Five days after the essay's release, major companies demonstrated an alternative model of participation in the ecosystem: funding Bitcoin development without interfering in protocol rules.
Saylor’s Strategy was among the nine founding members of the Bitcoin Security Consortium, alongside Blockstream, BlackRock, Coinbase, Fidelity Digital Assets, Galaxy, Block, Anchorage Digital, and ARK Invest.
Participants independently pledged to allocate $15 million over three years — but not to a common fund: each manages their funds independently. Mike Schmidt from the non-profit Brink coordinates the work on a volunteer basis. The first focus is preparing for a potential era of quantum computing.
The consortium’s charter precisely draws the line Saylor wrote about. The organization funds developers but does not interfere in the protocol and does not take positions on specific changes.
The individual contributions of the nine participants to this $15 million remain undisclosed. It is also unclear whether the separately announced $5 million from Galaxy for quantum threat protection is included.
Who Decides?
In early August, nodes with the new rules will begin rejecting blocks without bit 4. For the rest of the network, nothing will change — it will continue to accept them as usual. This will not result in a split but rather a parallel chain: smaller in both hash rate and participant count.
Eight months of debate have not moved BIP-110's support signal even to two percent. For the average coin holder, nothing has changed during this time: fees, transfers, and balances continue their usual course while the social media war rages over Bitcoin's future.
This is how governance in this network works. Decisions are not made by voting — neither miners, developers, nor companies with billions in their balance sheets. Each participant chooses which version of the software to run — this is the only lever of influence they possess.
Foundry asks its clients because it cannot decide for them. Habovštiak proves the validity of his transaction rather than posting about it. The researcher Dathon Pwn publishes a patch along with a description of the bug.
The August fork will reveal how many network participants are willing to adopt the new rules. No more, no less.