An update on OP_RETURN, Bitcoin Core v30, and the Core-Knots war

Context

Introduced in 2014, the OP_RETURN instruction allows small metadata to be written directly into the Bitcoin blockchain by attaching arbitrary data to a transaction.

Bitcoin Core v30, released on October 10, 2025, marks a major turning point in data integration on Bitcoin by raising the OP_RETURN limit from 83 to 100,000 bytes, removing any practical constraint on the amount of information that can be embedded in a transaction.

This change does not alter the Bitcoin protocol itself. It does not touch the consensus rules, the fundamental rules that define what makes a block valid, but only the relay policies ("policy rules") that each piece of software applies locally to decide whether or not to accept a transaction into its mempool.

The adjustment reflects a more permissive approach to blockspace management. The goal is to channel non-monetary uses into a dedicated space rather than see them proliferate through workaround methods.

This purely software-level shift revives a historic and ideological divide around Bitcoin. It crystallizes in the opposition between the network’s two main clients: Bitcoin Core, the historical implementation which has become more permissive, and Bitcoin Knots, a conservative fork attached to a strictly monetary interpretation of the protocol.

---

Reminder on Bitcoin consensus

Bitcoin Script, the protocol’s native language, defines through opcodes the spending conditions of a transaction. Unlike Ethereum, it is not designed to execute complex smart contracts, but only simple logical conditions such as signature verification, hash validation, or time locks.

Among these instructions, OP_RETURN has a special role. When executed, it terminates the script and makes the associated output permanently unspendable. The bitcoins locked in this way are irrecoverable, but the output can include arbitrary data (text, hash, digital fingerprint, etc.) up to the limit set by the client’s policy, now 100,000 bytes since Bitcoin Core v30.

As a reminder, the Bitcoin protocol is based on two distinct levels of rules:

• Consensus rules, which determine what makes a block valid (for example the maximum block size). Deviating from these rules leads to a chain split.
• Policy rules (or "standardness"), which only govern the relay and propagation of transactions on the network.

OP_RETURN falls into the second category. A transaction can be valid at the consensus level while being considered non-standard under a node’s policy and therefore not relayed by default. It remains mineable and can be included in a block. This distinction between validity and relay explains how Bitcoin Core and Bitcoin Knots can diverge in their policies without ever breaking compatibility with the blockchain.

Each node runs a client, a piece of software responsible for applying the blockchain rules. As long as these clients respect the same consensus rules, they remain interoperable. This diversity strengthens the resilience of the network, similar to Ethereum, where several implementations (Geth, Nethermind, Besu) coexist while applying the same protocol in different software forms.

However, unlike Ethereum, which separates consensus clients and execution clients, Bitcoin relies on a single type of client that handles both validation and execution of the protocol.

---

OP_RETURN: origins, limits, and evolution

Before 2014, OP_RETURN was considered a non-standard instruction. A transaction could contain such an output and still be valid at the consensus level, but it would not be relayed by nodes enforcing Bitcoin Core’s default policy.

The introduction of version 0.9 in March 2014 marked a turning point. Developers decided to allow a standardized OP_RETURN output, initially limited to 40 bytes, then raised to 80 and 83 bytes in version 0.11.

At that stage, the goal was not to offer storage capacity on Bitcoin, but to solve a problem of pollution of the UTXO set, the database of unspent outputs stored in RAM by each node. Before this change, some users were already inserting data into the blockchain through workaround techniques, thereby inflating the database that every node has to keep in memory.

OP_RETURN offered a clean solution with a dedicated space for metadata that does not bloat the UTXO set. Mastercoin (which became Omni Layer) was the first to exploit it to issue tokens on Bitcoin, notably Tether’s USDT in 2014.

The balance then shifted, first with SegWit (2017), then with Taproot (2021). SegWit introduced the witness field, separate from the rest of the transaction and benefiting from a "witness discount", a factor that reduces the accounted weight of data when computing transaction fees.

Developers quickly leveraged this capability to embed much larger data chunks in the witness at a lower cost, while remaining fully compliant with the consensus rules. The fundamental issue here is that data embedded in the witness field increases the size of the blockchain, since every node must download and store it to stay in sync.

Taproot amplified this potential by combining Schnorr signatures with Merkle trees, enabling complex scripts or arbitrary data to be included in the witness, and paving the way for solutions such as Ordinals and BRC-20.

In 2023, the Ordinals protocol popularized this mechanism, triggering a major debate on relay policies. The historical limitations of OP_RETURN were no longer effective, as the use cases they were meant to constrain had moved to the witness field. The underlying question remains open: should strict caps be maintained, at the risk of encouraging harmful workarounds, or should OP_RETURN be expanded to channel these practices into a clean, dedicated space?

---

Bitcoin Core v30: new rules for OP_RETURN

Version 30 of Bitcoin Core, released on October 10, 2025, changes the relay policy applied to OP_RETURN outputs. The -datacarriersize parameter, which defines the maximum size of metadata that can be written into OP_RETURN, goes from 83 to 100,000 bytes by default. In practice, this increase removes any effective constraint on OP_RETURN, since the total transaction size limit of 100,000 vbytes will be reached long before that ceiling.

On Bitcoin, fees are calculated based on the weight of a transaction, expressed in vbytes, a unit that weights data size according to its validation cost. By comparison, on Ethereum, cost is expressed in gas, whose amount depends on the type and number of operations executed, not just on data volume.

Version 30 also introduces the possibility of including multiple OP_RETURN outputs in a single transaction. Previously, only one could be relayed by default; transactions with several such outputs were considered non-standard, even though they were valid at the consensus level.

These parameters remain configurable. A node operator can restrict or disable the relay of data carriers, in other words choose not to relay transactions containing large OP_RETURN outputs. A proposal to remove these options was discussed during the development phases but was dropped in the final version.

---

Impacts and use cases

The changes introduced by Bitcoin Core v30, although they are limited to relay policy, open concrete perspectives for several existing and emerging projects. The expansion of OP_RETURN encourages more explicit data anchoring on Bitcoin without bloating the overall set of unspent outputs (the UTXO set).

Protocols built on Bitcoin such as Ordinals or BRC-20 rely exclusively on the changes brought by SegWit and Taproot. By contrast, other solutions like Runes, launched in April 2024 by Casey Rodarmor, the developer behind Ordinals in 2023, rely exclusively on OP_RETURN.

In this model, each Runestone written in a transaction’s OP_RETURN output acts as a state message containing the instructions needed to create, transfer, or destroy a Rune, the protocol’s native fungible token. These instructions, encoded as raw data, are then interpreted by external indexers that reconstruct the protocol’s logic.

With the removal of the OP_RETURN limit, Runes now benefits from greater flexibility for richer metadata structures without resorting to complex constructions.

The surge in OP_RETURN usage coincides directly with the launch of Runes in April 2024. The protocol turned this long-marginal feature into a central vector of on-chain activity. Within a few weeks, the volume of OP_RETURN outputs increased more than tenfold, reaching levels never seen before in Bitcoin’s history.

Beyond inscriptions, Bitcoin Core v30 also opens new use cases for Layer 2 solutions, where OP_RETURN can serve as an anchoring point for states or proofs, allowing them to periodically prove their state, similar to what Layer 2 systems do on Ethereum.

For example, Ark Protocol, designed by Burak Keceli (formerly Lightning Labs), is currently developing Arkade Assets, a framework announced in October 2025 for creating and transferring tokens natively on Bitcoin. This system uses OP_RETURN to encode on-chain asset data (stablecoins, security tokens, etc.), while allowing most operations to occur off-chain within Arkade’s VTXO environment.

In summary, v30 does not introduce new smart contract features, but the loosening of constraints makes OP_RETURN more useful as a universal data anchoring interface, mainly for Layer 2.

In practice, few projects are built directly around OP_RETURN, whose function remains limited to data anchoring. Application-level advances on Bitcoin are more likely to emerge through opcodes currently under discussion, such as OP_CAT, OP_CTV, and OP_CSFS, which extend the programmability of the language and open the way to application-level constructions on Bitcoin.

---

Bitcoin Core vs Bitcoin Knots: two visions of the same protocol

The debate around OP_RETURN has highlighted two distinct approaches to protocol maintenance. On one side, Bitcoin Core, the dominant historical client, favors a pragmatic and adaptable interpretation of the code. On the other, Bitcoin Knots, maintained by Luke Dashjr, embodies a conservative reading focused on the monetary purity of the network.

The role of a client

A Bitcoin client is software that implements the protocol rules, that is, block validation, transaction relay, and mempool management.

Each node on the network runs a client and decides locally on its relay policy, in other words which transactions to relay, store, or reject. As long as it respects the consensus rules that define what makes a block or transaction valid, it remains compatible with others.

Differences between these clients are limited to their relay policy, with no impact on consensus and no risk of a fork.

In the diagram below, all transactions within the green circle are valid at the consensus level: they respect Bitcoin’s fundamental rules and can be included in a block.

A node running Bitcoin Core, however, only relays those in the purple circle, known as standard transactions. Conversely, a client applying a different policy can choose to relay all valid transactions, including those deemed non-standard, without breaking its compatibility with the network.

Bitcoin Core: the historical reference

As the direct descendant of the software released by Satoshi Nakamoto in 2009, Bitcoin Core has established itself as the network’s technical and social reference. Thanks to its stability, rigor, and historical adoption, about 76 percent of nodes still run it in 2025.

The Core team favors a pragmatic approach, tolerating non-monetary uses as long as they remain contained, framed, and controlled. In their view, expanding OP_RETURN is a harm-reduction measure:

• Metadata remains isolated from the UTXO set.
• Nodes retain local control over their relay policy.

This position follows an economic logic. In the long run, blockspace scarcity acts as a natural filter. As a result, anchoring large amounts of data becomes expensive and tends to marginalize itself without coercive intervention.

Bitcoin Knots: the conservative counter-model

Bitcoin Knots, a direct fork of Core maintained by Luke Dashjr, a long-time developer known for his maximalist positions, keeps the same consensus rules but imposes a stricter policy.

By default, it limits OP_RETURN to 42 bytes, enables anti-spam filters, and applies a more selective relay policy. Its philosophy is based on a strictly monetary reading of the protocol: Bitcoin should remain a settlement network, not a data storage platform.

For Knots supporters, Core 30.0’s decision to allow up to 100,000 bytes per OP_RETURN is a symbolic abandonment of this founding idea.

They see three risks in this shift:

• Congestion of blockspace, where data-related transactions crowd out payments.
• Structural increase in fees, penalizing basic uses.
• Regulatory risk, tied to the ease of embedding illicit content (such as illegal data) directly on Bitcoin.

Knots aims to send the opposite signal: rejecting by principle uses considered "spam" and maintaining strict monetary discipline.

The rise of Knots

Until early 2025, Bitcoin Knots represented only a marginal fraction of the network. Around 400 nodes were running Knots, compared with more than 20,000 running Core. Since the debate around OP_RETURN and criticism from figures like Samson Mow, its share has risen sharply, now exceeding 20 percent.

This growth is also driven by adoption of Knots by several large actors. The OCEAN mining pool, co-founded by Luke Dashjr and funded through a 6.2 million dollar seed round led by Jack Dorsey, relies on Bitcoin Knots for its nodes. Its share of the hash rate has tripled since the beginning of the year, placing it among the ten largest mining pools in the world, which increases the visibility and legitimacy of the client.

This resurgence reflects an ideological rather than technical disagreement. The two clients apply the same consensus rules and validate the same blocks, guaranteeing full compatibility.

In practice, even a minority of nodes running Core is enough to ensure the propagation of large OP_RETURN transactions. Unless an overwhelming majority of the network adopts Knots, this form of resistance remains symbolic.

Technical comparison: Bitcoin Core vs Bitcoin Knots (v30, 2025)

---

Risks and trade-offs

The changes introduced by Bitcoin Core v30 around OP_RETURN do not affect consensus but alter several technical and operational balances in the network. The main risks relate to network load, mempool-level attack surface, software governance, and the structural growth of the blockchain.

No hard fork risk

Core and Knots apply the same consensus; their differences affect only how transactions are propagated. A block accepted by Knots is also accepted by Core, and vice versa. As long as this distinction is maintained, there is no possibility of a hard fork, and both clients operate on the same Bitcoin blockchain.

Technical risks: load and DoS attacks

Raising the OP_RETURN ceiling increases the potential DoS attack surface at the mempool level.

A more permissive relay policy can make it easier to flood the network with transactions that are valid but considered of low usefulness, temporarily saturating the memory or bandwidth of some nodes.

Node operators, however, have countermeasures: disabling relay of data carriers, local filtering, or customizing their relay policies.

The change also increases network load. Relaying and validating transactions containing several hundred kilobytes of data requires more bandwidth and CPU power. At scale, this kind of usage would make synchronization and storage of full nodes heavier.

Economic incentives

The OP_RETURN change is not economically neutral. A 100 kB transaction costs around 0.002 BTC at 2 sat/vB, that is roughly 230 dollars at the current price.

If a meaningful share of network traffic adopted this "data-heavy" format, it would represent several hundred BTC in additional fees per year.

This change creates an economic trade-off. Miners and pools (Foundry, MARA, AntPool) benefit from a new source of revenue, notably via direct services such as Slipstream, which allow large transactions to be submitted outside the public mempool.

But in return, monetary users bear higher fees during congestion periods. The trade-off is explicit: more revenue for mining, hence more long-term security, but reduced accessibility for low-value payments.

Historically, peaks in Bitcoin fee revenue almost always coincide with waves of Ordinals inscriptions or derivative protocols (Runes, BRC-20). Three major spikes can be observed in particular, corresponding to "data-heavy" activity periods in May 2023, December 2023, and April 2024, when inscriptions saturated blockspace and pushed weekly fees above 100 million dollars.

Governance dynamics and maintenance models

Bitcoin Core remains the most audited client on the network, with several hundred historical contributors, five lead maintainers, and a semi-annual release cycle.

Bitcoin Knots, by contrast, relies almost exclusively on Luke Dashjr, assisted by a few occasional reviewers. This narrower model slows the integration of fixes and creates a strong dependency on a single maintainer.

Knots releases are generally published with a slight delay compared to Core, which can postpone the application of minor security fixes. In addition, most community audit efforts concentrate on Core, leaving Knots with limited external review. This does not compromise consensus security, which is identical between the two clients, but slightly increases operational risk for nodes running Knots.

---

Conclusion

The changes introduced by Bitcoin Core v30 around OP_RETURN do not alter the foundations of consensus, but they do shift the lines of software governance. By relaxing its relay policy, Core adopts a pragmatic approach, choosing to allow non-monetary uses within a controlled framework rather than push them into rule-bypassing workarounds.

Knots represents the opposite stance, a strict monetary maximalism where any tolerance for data is seen as a dilution of Bitcoin’s role. These two visions reflect a gradual differentiation of relay policies rather than a split in the protocol.

In practice, Bitcoin remains a unified system: a single blockchain, but several possible interpretations of the rules that govern its blockspace.