v30 sparks OP_RETURN limit controversy

Bitcoin Core update v30 was released in October 2025, reigniting debate over how much arbitrary data can be stored on-chain.

What changed in the bitcoin core update and why does the op_return data limit matter?

Version v30 raises the default allowance for OP_RETURN payloads and exposes the limit via the -datacarriersize option. Consequently, larger amounts of arbitrary data — including potential inscriptions on bitcoin blockchain — can be relayed and accepted by nodes. For exchanges, custodians and institutional users, that raises questions about bandwidth, storage and reputational exposure.

How big is the Bitcoin core update and who decided it?

The Bitcoin Core development group debated options for months before merging the change into the v30 release. The release notes and announcement are available from the official project. As the release notes state, “this exposes the limit via the -datacarriersize option”, clarifying it is a policy-level setting rather than a consensus rule.

How does the datacarriersize parameter guide work and what should node operators do?

The key control is the -datacarriersize config option. Set it in bitcoin.conf with datacarriersize=VALUE or supply -datacarriersize=VALUE on the command line. This sets the maximum OP_RETURN payload your node will accept into its mempool and relay to peers.

In our operational practice, we stage any datacarriersize change on a non‑production node for 48–72 hours and monitor mempool size, relay traffic and peer bandwidth. That short staging window often reveals unexpected peer behaviour before touching production infrastructure. These checks reduce outage risk and help quantify the impact on node resources.

• Backup first: backup wallets and configs before upgrading.
• Test changes: change the parameter on a secondary node before production.
• Choose conservative defaults: a lower datacarriersize limits non financial bitcoin transactions and reduces disk and bandwidth pressure.

Why are some users performing a bitcoin knots node switch?

Because v30 makes the op_return data limit configurable, some operators prefer alternative builds that preserve stricter defaults. That has accelerated discussion about a bitcoin core vs knots divergence in policy defaults, and led to increased interest in Bitcoin Knots.

How to switch safely to Knots

Stop Bitcoin Core, backup your wallet and datadir, install Bitcoin Knots for your OS, and start the node pointing to the existing datadir or a new one with –datadir. Monitor logs closely for compatibility notes. Official Knots binaries and documentation are available from the project. Bitcoin Knots emphasises conservative policy defaults, which is why some operators concerned about inscriptions and non‑financial bitcoin transactions prefer it.

What legal or archival risks do archive nodes face?

Archive nodes store the full blockchain history. As OP_RETURN capacity grows, so does the chance of storing copyrighted, offensive or illegal data. This elevates archive node legal risk in some jurisdictions. Institutional operators should consult legal counsel and may prefer tighter datacarriersize settings or selective archival strategies.

Could inscriptions and non‑financial bitcoin transactions flood the chain?

Proponents argue more space enables creative uses and richer metadata for apps. Opponents warn that large-scale inscriptions on bitcoin blockchain could increase transaction fees and bloat storage, harming ordinary users. The change therefore intensifies the debate over Bitcoin’s base‑layer purpose.

Quick FAQ on this bitcoin core update

Will my wallet break?

Standard payments continue to work. Wallets embedding large data depend on node policy and so may behave differently across networks with divergent datacarriersize settings.

Will this cause a network split?

Consensus rules stay the same; the risk is divergent mempool and relay policies rather than chain reorgs. Thus, a split in policy defaults can fragment relay behavior without changing block validity.

Summary: v30 moves the OP_RETURN debate from a single cap to operator control via -datacarriersize. That creates operational choices and legal considerations for node operators, exchanges and developers.

Community poll suggested: Should your default node allow large OP_RETURN payloads? Options: Keep conservative cap / Allow large payloads / Use Knots / Other.

Warning: changing consensus‑adjacent config without testing can disrupt services. Backup, test and seek counsel if you run archival or institutional infrastructure.

For a practical walkthrough and migration checklist, see our guides on datacarriersize guide and community analysis.