What Your Node Can Refuse
Bitcoin Core 30 effectively removed the 80-byte OP_RETURN default that had stood for eleven years, and the other side moved to Knots and went as far as a soft fork. The two layers of policy and consensus, what each side gets right, the BIP-110 chain split and the hard fork that followed, how much data actually lands in blocks today, and what a node operator can and cannot choose.
At 19:35 UTC on August 8, 2026, block 961,632 was mined. It was an ordinary block. Some of the nodes that received it rejected it anyway, because a particular signal bit in its header was not set. Those nodes waited for a block on their side that did set the bit, and their chain all but stopped within a few blocks. Two days later an editor of the BIP repository changed the proposal's status to Closed and wrote: it split to a new chain and stalled.
The nodes that split off were Bitcoin Knots nodes running a soft fork called BIP-110. It all started with one configuration value: the default limit on data in an OP_RETURN output, 80 bytes.
How to Throw an Output Away
An output in a Bitcoin transaction is normally money someone can spend later. The output script is a lock, and whoever satisfies it takes the coins. OP_RETURN in the script language breaks that structure on purpose. When a script hits this opcode it fails on the spot, so an output that begins with OP_RETURN can never be spent. Because that is provable, nodes can leave such outputs out of the UTXO set, the list of coins not yet spent. The amount is usually zero, and the bytes after the opcode simply stay in the blockchain as data.
The device exists because data could not be kept out. Before 2014, people were already putting images and documents into the blockchain by sending dust to fake addresses whose "address" was really data. Nobody can spend such outputs, but nodes cannot prove that, so they stay in the UTXO set forever. The list every full node has to keep close at hand swells with junk.
Bitcoin Core 0.9.0, released March 19, 2014, was the first version to relay OP_RETURN outputs as standard. Its release notes spent a paragraph heading off a misunderstanding.
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes - some of which were already deployed - that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin's UTXO database.
The notes went on to say that storing arbitrary data in the blockchain is still a bad idea. The limit was merged at 80 bytes, cut to 40 shortly before release, and raised back to 80 in 0.11.0 (2015). From 0.12.0 (2016) it was measured against the whole output script: 80 bytes plus a few bytes of opcodes, 83 in total.
In between, 0.10.0 (2015) added two settings: -datacarrier, which turns OP_RETURN relay off entirely, and -datacarriersize, which changes the size limit. Both were written by Luke Dashjr. The description of his 2014 pull request is short: this seems to be something miners want control over. Eleven years later the option would stand at the centre of the fight.
Rules That Reject and Rules That Admit
To follow the debate you first need to see that a node holds two layers of rules.
The lower layer is consensus. It decides whether a block is valid: the 21 million cap, signature checks, the block weight limit. Every node rejects a block that breaks consensus, and changing these rules takes a soft fork or a hard fork.
The upper layer is policy, often called standardness. It decides whether a transaction that is not yet in a block will be accepted into my mempool and passed on to my peers. Minimum feerate, transaction size and OP_RETURN size live here. Policy can differ from node to node, and changing it requires nobody's consent.
The key fact is that OP_RETURN size has never had a consensus limit. A block containing an OP_RETURN larger than 80 bytes was valid from the start. The 80-byte limit only meant "I will not take this into my mempool or pass it on." If a miner put such a transaction in a block, every node accepted and stored that block. Policy can narrow the road a transaction takes to a miner, but it cannot change what happens after the transaction is mined.
What Happened in the Spring of 2025
On April 17, 2025, Antoine Poinsot posted to the Bitcoin developer mailing list proposing to relax the OP_RETURN standardness limits. The trigger was a bridge built by a project called Citrea. It needed to leave more than 80 bytes of data on Bitcoin, so it was splitting the data across unspendable Taproot outputs: exactly the pattern 0.9.0 had tried to stop, the one that bloats the UTXO set forever. Poinsot's argument was that the limit does not stop useful activity; it only pushes data into more harmful places.
Ten days later Peter Todd opened a pull request removing the limit and the configuration options altogether. He wrote that the limit was easily bypassed, both by services such as MARA's Slipstream that take transactions directly to a miner and by forks such as Libre Relay that relay without a limit. As opinion gathered around keeping the options, the PR was closed unmerged on May 12. Instead, a different PR by Greg Sanders was merged on June 9: keep the options, but raise the default to effectively unlimited.
In between, on June 6, 31 Bitcoin Core contributors published a joint statement on relay policy.
Knowingly refusing to relay transactions that miners would include in blocks anyway forces users into alternate communication channels
The statement added that this was not endorsing or condoning non-financial data usage, the same caveat 0.9.0 had made.
The options themselves wobbled once more. The merged PR marked both as deprecated, which was read as a move to take away node operators' choice and fed the backlash. On September 30 a PR removing the deprecation was merged, and the fix made it into the release.
Bitcoin Core 30.0 shipped on October 10, 2025. The relevant passage of the release notes:
-datacarriersize is increased to 100,000 by default, which effectively uncaps the limit (as the maximum transaction size limit will be hit first). It can be overridden with -datacarriersize=83 to revert to the limit enforced in previous versions.
From this version a transaction may also carry several OP_RETURN outputs, with the limit applied to their combined size.
What Each Side Gets Right
Core's case is mostly arithmetic. Since SegWit, witness data counts at a quarter of its weight, which is why Ordinals inscriptions put their data in the witness. OP_RETURN sits in an output, so the same data costs four times as much there. Lift the limit and the cheapest place for data is still the witness; keep the limit and that road stays open. What the limit blocks is only the case that must use OP_RETURN, and those users move to fake public keys or unspendable outputs that bloat the UTXO set. There is also a cost when nodes fail to hold transactions that do get mined. When a new block arrives, a node rebuilds it from transactions already in its mempool and fetches only the rest (compact blocks), so the more unknown transactions, the slower the propagation. Fee estimates drift from real blocks. And the bigger the direct-to-miner channel grows, the more it favours large miners who can run one.
Knots's case begins with principle. Luke Dashjr answered Poinsot's first post with "utter insanity": the bugs should be fixed, not the abuse embraced. Even if data embedding really is bypassed, making it standard signals that Bitcoin may be used as a data store. Someone running a node has the right to choose what is stored on their disk and passed through their connection. The legal risk of storing illegal content was raised too. Against that came the reply that the witness and paid bypass channels already allow it, so the limit is beside the point, along with reports of lawyers calling the concern overblown.
The two cases answer different questions. Core asked whether the limit reduces data, and the answer was: hardly. Knots asked whether Bitcoin welcomes data, and the answer was: no. As in the Ordinals debate, both sides looked at the same facts and called each other irresponsible.
From Policy to Consensus
By the time Core 30 arrived, the share of public nodes running Knots had risen sharply; trackers reported it above 20% at one point in September 2025. But node counts do not decide what goes into blocks. Miners decide that, and miners have ways around policy filters. That is why a proposal emerged to move a fight lost at the policy layer into consensus.
BIP-110, "Reduced Data Temporary Softfork", was assigned its number in December 2025. It narrows consensus for a single year: new output scripts up to 34 bytes (83 for OP_RETURN), data pushes and witness items up to 256 bytes, and Taproot annexes, OP_SUCCESS and executing OP_IF in scripts all made invalid. Coins created before activation are exempt. The document itself notes that the limits could get in the way of contracts such as BitVM, which might have to wait until the soft fork expires.
Knots shipped the soft fork in version 29.3 on May 9, 2026. It had to be switched on in the configuration, and a build without it was published separately. Activation collected signals for a period and then, in the mandatory period, rejected blocks without the signal. Of the 2,016 blocks just before the mandatory period, 51, about 2.5%, carried the signal, all of them mined by the OCEAN pool. The first block of the mandatory period was the 961,632 above. A soft fork that most hashpower does not follow cannot change the majority chain; only the nodes enforcing it fall away.
The next Knots release went one step further. The notes for 29.4.1, published September 2, 2026, describe August 8 like this.
On August 8th, most former miners abandoned Bitcoin en masse and together with other bad actors have been falsely promoting a new altcoin as "Bitcoin".
The release contained a hard fork changing the proof-of-work algorithm from SHA-256 to BLAKE2b, with the BIP-110 rules switched on at the same point, so existing mining hardware cannot mine that chain. The notes call it the first backward-incompatible change in 13 years. The two sides give opposite answers to the question of who left, but the facts are single: nodes running this release now validate a different chain.
What Goes into Blocks Now
Parsing the 144 blocks mined from the morning of October 14 to the morning of October 15, 2026 (UTC; heights 971,383 to 971,526), 877 of 694,840 transactions carried an OP_RETURN larger than 83 bytes. The largest was 15,507 bytes, about 727 KB in total. OP_RETURN bytes get no discount and count as four weight units each, so that is a little over 0.5% of the day's block space (4 million weight units per block). By pool: Foundry 332, F2Pool 237, ViaBTC 129, SpiderPool 80, MARA 67, while AntPool mined 31 blocks with none. Whether a pool takes large OP_RETURNs varies from pool to pool. That, too, is policy.
Node figures depend on how you count. On the same day coin.dance counted 4,074 Knots nodes among 25,453 reachable public nodes (16.0%), while the census run by Luke Dashjr, which adds an estimate of unreachable nodes, put it at 12.8% of about 105,000. Whether to count Knots nodes running the BLAKE2b hard fork as Bitcoin nodes is a matter of interpretation. The latest Bitcoin Core release is 31.1, from July 8, 2026; 31.0 made no change to OP_RETURN policy.
What Your Node Can Choose
For anyone running their own node, the story leaves something concrete.
After Core 30, writing -datacarriersize=83 in the configuration file still restores the old limit, and with the deprecation withdrawn the option is not going away soon. The setting does exactly two things: it keeps large OP_RETURN transactions out of your mempool, and it stops you passing them on. If such a transaction is mined through another route, your node receives, validates and stores that block. It has to download that transaction fresh when the block arrives, so block reconstruction is a little slower and fee estimates drift a little from real blocks. If disk space is the worry, pruning (prune) is the direct tool rather than the limit: it deletes old blocks and keeps disk use under the size you set.
Policy guards your mempool; consensus guards everyone's ledger. The option Luke Dashjr wrote in 2014 let each node choose its own mempool, and what Core changed in 2025 was that option's default. In 2026 BIP-110 tried to impose the choice on everyone, and that needed hashpower to follow. When it did not, the only road left was a different chain. As in the block size war, Bitcoin's rules do not change because someone decides; they are settled by what nodes, miners and users each choose to run. What your node can refuse is only what comes into your node.