BIP-110 in plain English
BIP-110 is a soft-fork proposal. Its title describes it as a way to temporarily limit arbitrary data in Bitcoin. In plain terms, it asks nodes to treat some kinds of data-heavy transactions as invalid for a limited period, instead of merely declining to relay them.
That last part is the key point. The proposal is about consensus rules, which decide what every enforcing node accepts as valid. It is not a local relay or mining policy, which are choices one operator makes for their own node or their own blocks.
Three things this article will not do. It will not describe BIP-110 as an upcoming activation. It will not claim majority support among miners, nodes or users. And it will not treat it as DATUM or as another name for the later Bitcoin BLAKE2b hard fork. Each of those is a separate thing.
The article follows the specification first, then marks everything else by source type: primary (the specification), advocate or critic commentary, and news or analysis about what happened on the network. Our own editorial position is kept in its own section so it is not mistaken for a statement about adoption.
Status in one line: at our planning check on 16 October 2026, the specification listed BIP-110 as Closed and recorded a change in August 2026. Details and caveats are in the status section below.
Consensus restrictions versus relay and mining policy
Most confusion around BIP-110 comes from mixing up two layers that sound similar.
Consensus rules define which blocks and transactions are valid at all. If a block breaks a rule that a node enforces, that node rejects it, whatever the miner intended. Changing consensus rules needs broad coordination, because nodes that disagree can end up following different chains.
Relay and mining policy is narrower. A node operator can decide which unconfirmed transactions to pass along. A miner can decide which transactions to put in a block template. Other nodes still accept a block containing a transaction you would not have relayed, as long as it is valid under consensus.
| Consensus restriction | Relay or mining policy | |
|---|---|---|
| Who decides | Every node that chooses to enforce the rule | One node operator or one miner |
| Effect on other participants | Blocks that break the rule are rejected by enforcing nodes | None on validity; only what that operator relays or mines |
| Risk if enforcement is not shared | Enforcing nodes may fall out of step with the rest of the network | Mostly a difference in what appears in mempools |
| BIP-110 is about | This layer | Not this layer |
A soft fork tightens the rules so that blocks valid under the new rules are also valid under the old ones. That is why it can be proposed without every node upgrading. It is also why a minority of enforcing nodes can find themselves rejecting blocks the majority accepts.
Quick definitions
- Node: software that checks blocks and transactions against the rules it enforces.
- Miner: the party that produces blocks, usually by hashing against a block template.
- Soft fork: a tightening of the rules.
- BIP: a Bitcoin Improvement Proposal, a written design document. A status label such as Closed describes where the document stands in the BIP process. It does not measure support or prove that the idea was ever enforced.
The problem the authors aimed to address
According to the proposal and summaries of it, the concern is the growing practice of embedding arbitrary data in Bitcoin transactions. Proponents argue this burdens node operators and diverts resources from what they see as Bitcoin's core mission.
Per the specification and summaries of it, new scriptPubKeys, the locking conditions on outputs, would be limited to 34 bytes. The exception is OP_RETURN, a common way to attach data to a transaction, which would be allowed up to 83 bytes.
To keep the claim in proportion, there are three layers worth separating:
- What the authors state: arbitrary data is a burden and a distraction, and a temporary consensus limit is the proposed answer.
- What the text does: it restricts certain output sizes for new outputs, with named exceptions.
- What is not shown by the text itself: that the restriction would work as intended, that the cost to node operators is as the authors describe, or that the wider ecosystem agrees.
A proposal can describe a real problem and still be a contested answer to it. The proposal's existence is not evidence of broad support. Some skeptical readers see BIP-110 advocacy as a persuasion campaign. That is a perspective, not a measured finding, and this article treats it that way.
The money-first argument, and our position
In the BIP-110 debate, money-first is the argument that Bitcoin should prioritize its use as money. Proponents say that using the base chain for arbitrary data competes with that role and imposes costs on the people who verify the ledger. On this view, a temporary consensus limit is a way to protect the monetary use case while the wider question is settled.
That is the proponents' framing. Critics reject it, and the next section covers their points. A rationale is an argument about purpose. It is not evidence about how many people hold it.
Our position, labeled as such
BlakeStack editorial position. We back Bitcoin as permissionless money, independent node verification, and miners choosing transactions through their own nodes. We favor setups where pools coordinate rewards while miners keep control of block templates. That is our judgment. It is not a claim that BIP-110 had majority support, and it is not a claim that a proposal like BIP-110 achieves those goals.
Our interest in verification by independent participants overlaps with the concern behind BIP-110, but the overlap is partial. Someone can care about cheap, independent verification and still doubt that a consensus restriction is the right tool, or doubt that the people who propose it speak for the network.
The proposal also does not address who builds block templates. That is a separate question, covered below.
Tradeoffs, exceptions and criticism
A restriction like this needs carve-outs, and the carve-outs show where the authors saw the costs.
Exceptions built into the design
The specification includes several rules; two output-related points are worth knowing:
- The OP_RETURN allowance. One restriction caps new output scriptPubKeys at 34 bytes, except that OP_RETURN may go up to 83 bytes.
- Grandfathering. Unspent outputs created before activation are left alone, which protects existing coins and transactions from the new limit.
The specification and its changelog are the right place to read the full list of rules and exceptions. This article summarizes them and is not a line-by-line audit of the reference implementation or its tests.
What critics say
Critics raise several objections. One commentary piece argues that the proposal could damage Bitcoin's reputation by suggesting the protocol can be changed to censor transactions some people consider undesirable. Others, covered in the next section, argue that the design failed in practice because a minority of enforcing nodes cannot hold a chain without miner support.
Here is how the sources line up by type.
| Claim | Source type | How to treat it |
|---|---|---|
| New outputs capped at 34 bytes, OP_RETURN up to 83 | Specification, repeated in summaries and critiques | Check the specification text directly |
| Existing outputs grandfathered | Specification (UTXO grandfathering) | Confirm in the specification |
| Arbitrary data burdens node operators | Proponents' argument | Argument, not a measurement |
| Proposal implies censorship and harms reputation | Explainer written from a critical view | Contested opinion |
None of this amounts to a guarantee that the restriction is safe, effective or free of side effects. The specification itself calls the restriction temporary and lists exceptions. That is an admission of tradeoffs, not a proof that they are acceptable.
Status record and chain evidence
Start with the primary source. The BIP-110 page on bips.dev links to the versioned source, the changelog, the reference implementation and its tests.
| Item | What we found | Source type |
|---|---|---|
| Status label | Closed | Specification page, checked at planning on 16 October 2026 |
| Recorded change | An August 2026 change is recorded on the specification | Specification page and changelog |
| Majority support | No dated measurement supports a claim of majority support | Absence of evidence in what we reviewed |
| Upcoming activation | Nothing we found describes one | Specification status |
Recheck before relying on this. A status label is a snapshot. Open the specification and its changelog and confirm the current label and the August 2026 entry before you cite either. We do not describe the content of that change beyond the fact that it is recorded.
What happened on the network
On chain-specific evidence, we have only secondary reporting, and it should be labeled that way. News and analysis pieces describe nodes enforcing BIP-110 splitting from the main network, a brief chain halt, and a four-block chain tip on the breakaway side. One of those pieces frames the episode as a failure and asks whether the cause was flawed soft-fork design or miner capture. Commentary cited there notes that Bitcoin's difficulty rules successfully halted minority forks.
Two cautions apply. First, these are interpretations by their authors, and they disagree on cause. Second, we did not find a primary chain record in the material reviewed that we could independently verify, so we do not state block heights, dates or hashrate figures here. The existing chain-verification guide covers how to check records yourself, and we do not repeat it.
What can be said: a restriction enforced by a minority of nodes does not become the network's rule. Node counts alone also do not establish economic support or consensus.
Template selection, DATUM and the BLAKE2b fork
Three neighbors of BIP-110 get confused with it.
Block template selection. A block template is the set of transactions a miner works on. Who builds it matters, because the builder chooses what is included. A consensus restriction like BIP-110 would limit which transactions can be valid in any block, but it says nothing about who assembles templates. A miner who builds templates with their own node chooses within the consensus rules. A miner who accepts a template from a large pool operator accepts that operator's choices. That is the concentration we criticize in pool arrangements where templates are centrally supplied. Pools can instead coordinate rewards while miners keep template control.
DATUM. DATUM is a way for miners to build their own templates on SHA256d Bitcoin while still pooling rewards. It addresses who selects transactions. It is not a consensus change and it is not BIP-110. We have a separate explainer for it.
The BLAKE2b fork. Bitcoin BLAKE2b (XBT) is a separate, later hard fork that changed the proof-of-work algorithm. BIP-110 is a proposed soft fork about transaction data. Different mechanism, different goal, different date. For the fork's own dates and rules, check the FAQ on bitcoin-blake2b.org and the chain records. Our introduction to Bitcoin BLAKE2b covers the basics.
A new proof-of-work algorithm does not by itself decentralize mining, and the BLAKE2b name does not prove decentralization either. Template ownership is not something our dashboard measures.
- BIP-110: seven proposed temporary consensus restrictions, including limits on data in new outputs.
- Template selection: who chooses the transactions a miner works on.
- DATUM: miner-built templates with pooled rewards.
- BLAKE2b fork: a later proof-of-work hard fork, not BIP-110.
What to take away
If you need to explain BIP-110 in a few sentences, you can say this. It proposed seven temporary consensus restrictions, including a 34-byte cap on new output scriptPubKeys, an OP_RETURN allowance of up to 83 bytes, and exemptions for inputs spending UTXOs created before activation. Its authors framed it as protecting Bitcoin's use as money. Critics argued it risked setting a censorship precedent, and secondary reports describe an enforcing minority splitting from the main network. At our 16 October 2026 check, its specification listed it as Closed.
When you read a claim about it, ask four questions:
- Is this from the specification, or from someone describing it?
- Is it an argument, or a measurement with a date?
- Does it confuse consensus rules with relay or mining policy?
- Does it imply majority support or an upcoming activation? If so, ask for the dated evidence.
If your interest is miner independence in practice, the live question is template control, not this proposal. See current network observations on the BlakeStack dashboard and published pool terms on the pool comparison. Check any status or rule you rely on against the primary source on the day you read this.