Bitcoin Core vs Bitcoin Knots in 2026: Which Node Software Should You Run?

Short answer: Bitcoin Core and Bitcoin Knots enforce the identical consensus rules. A block valid for one is valid for the other, and they will never fork the chain over the choices discussed in this article. The only difference that matters to most operators is relay and mempool policy — what each node is willing to accept and forward to its peers by default. So the real decision is not "which client protects Bitcoin," it is "which maintainer and release model do I trust, and which transactions do I personally want to relay." Both are defensible answers.

This page exists because the question got loud in late 2025 and early 2026, when Bitcoin Core v30 changed a default that had been a flashpoint for years. A lot of operators switched to Knots in response. A lot of that switching was based on a misunderstanding of what node-level filtering actually does. Below, we separate the engineering from the politics so you can decide on facts.

What changed in Bitcoin Core v30: the OP_RETURN / datacarrier default

Bitcoin transactions can embed small amounts of arbitrary data using an OP_RETURN output. OP_RETURN is a script opcode that marks an output as provably unspendable and lets you attach a data payload. Because the output is unspendable, it does not bloat the UTXO set — which is exactly why it was introduced in Bitcoin Core 0.9.0 (2014) as the "approved" channel for data (it initially allowed 40 bytes; the familiar 80-byte standard-relay limit was set in a later release), steering people away from worse alternatives like fake addresses (data encoded as unspendable P2PKH outputs) and bare-multisig stuffing (data placed in the pubkey slots of, e.g., 1-of-3 multisig outputs) that do pollute the UTXO set forever.

For years, Bitcoin Core shipped a default relay policy that limited standard OP_RETURN data to roughly 80 bytes (the datacarriersize setting), and capped the number of such outputs per transaction. This was a policy limit on relay, never a consensus rule. Miners were always free to include larger data, and increasingly did — particularly once inscription and token protocols learned to route data through other script paths (notably witness data via Taproot) that the 80-byte OP_RETURN limit never touched.

In Bitcoin Core v30, released on 10 October 2025, the default OP_RETURN size limit was raised to 100,000 bytes — effectively uncapped, since the transaction-size limit is reached first and multiple OP_RETURN outputs per transaction were permitted for relay and mining. (Core initially planned to deprecate user configurability of these options in v30, but that plan was reversed before release — the datacarrier/datacarriersize options remain fully configurable in v30.) The maintainers' stated reasoning was pragmatic, not ideological: the 80-byte limit was no longer achieving its goal. Data was being embedded anyway through harder-to-filter channels, and some of those workarounds were worse for the network (UTXO bloat, out-of-band deals with miners that bypass the public mempool). Removing an ineffective filter, the argument went, makes the default node's mempool a more accurate preview of what miners will actually mine.

The counter-argument from operators who disagreed: a node's defaults are a statement of values, and loosening the filter signals acceptance of non-monetary data on the timechain. That is a legitimate preference. It is also a policy preference — which is the entire point of the next section.

Consensus vs policy: the distinction that makes this whole debate make sense

If you take one thing from this article, take this: consensus rules and relay policy are two different layers, and only one of them defines Bitcoin.

• Consensus rules decide whether a block is valid — block size/weight limits, the 21 million supply cap, signature validity, the rules of script execution, difficulty adjustment. Every node on the network must agree on these or the network forks. If your node and mine disagree on consensus, we are on two different chains. Both Bitcoin Core and Bitcoin Knots ship the same consensus rules. This is not a coincidence: Knots is a downstream fork of Core that deliberately keeps consensus identical.
• Relay / mempool policy decides which unconfirmed transactions your node will accept into its mempool and forward to peers. Policy is local. It is advisory. A transaction your node refuses to relay is still perfectly valid and can still be mined into a block that your node will then accept without complaint.

This is why the "which client protects Bitcoin" framing is the wrong question. Neither client can change a consensus rule by itself, and neither one needs to: they already agree. The filtering knobs in Knots (and the ones you can set in Core) operate entirely in the policy layer. They change what your node gossips. They do not change the rules of Bitcoin, and they cannot stop a transaction from being confirmed once a miner decides to include it. We cover the underlying responsibilities of node software in our deeper piece on node software security and verification.

What Bitcoin Knots actually is

Bitcoin Knots is a derivative of Bitcoin Core maintained by Luke Dashjr, a long-standing Bitcoin developer. It periodically rebases on top of Bitcoin Core releases and layers on a set of additional features and — most relevant here — stricter default relay and mempool policy. Knots has existed for over a decade; it is not a 2025 invention. What changed in 2025–2026 is that its stricter posture became attractive to operators who wanted to keep filtering data that Core v30 stopped filtering.

Concretely, Knots ships defaults that:

• Keep a tighter datacarrier / datacarriersize policy (it can refuse to relay OP_RETURN data, or restrict its size, by default).
• Tend toward refusing to relay transactions that match patterns associated with arbitrary data embedding and "spam," to the extent that is detectable at the policy layer.
• Expose more aggressive configuration switches for operators who want a maximally restrictive mempool.

Knots' release cadence is slower and more singular than Core's: it tracks Core's releases and then adds its patches, with releases driven largely by one maintainer rather than a broad contributor set with a formal multi-maintainer process. Whether that is a feature or a risk is exactly the kind of judgment this decision comes down to (more on that below). For background on how the broader landscape of node implementations evolved and the tradeoffs between them, see our technical analysis of Bitcoin node software.

Bitcoin Core vs Bitcoin Knots: side-by-side

Notice what the table does not contain: any row where one client is "more Bitcoin" than the other. The differences are real, but they live in policy, governance, and ecosystem support — not in the rules of the network.

What running Knots-style filtering does — and does NOT — achieve

This is the section most of the internet gets wrong, so be precise here.

What it does:

• Your node relays less of what you consider spam. If you run a restrictive policy, your node will not gossip the filtered transactions to your peers. If enough peers do the same, those transactions propagate more slowly across the public peer-to-peer network.
• Your local mempool reflects your values rather than reflecting the miner-eye view. Some operators simply prefer this.
• It marginally raises friction for data-embedding that depends on cheap, fast public propagation.

What it does NOT do:

• It does not stop miners from mining the data. A miner who wants to include a transaction does not need your mempool. Many large data transactions reach miners through direct submission, private relay, or accelerator services that bypass the public mempool entirely. Policy filtering at your node has zero effect on those paths.
• It does not change consensus. When a miner mines a block containing the data you filtered, your strict node still validates and accepts that block. It must — the block is consensus-valid. Filtering never causes your node to reject a valid block.
• It does not remove the data from the chain. Once confirmed, it is in the blockchain you store and serve regardless of which client you run.
• It is not a vote that "wins" by majority. Relay policy is not a consensus mechanism. A large fraction of nodes running strict policy can slow propagation, but it cannot prohibit anything that miners are economically motivated to confirm.

So the honest framing is: running Knots-style filtering is a way to not personally participate in relaying transactions you disapprove of, and to apply some friction at the margins. It is a values-expression and a mild propagation lever. It is not a mechanism that protects the chain from data, because the chain's contents are decided by miners and consensus, not by your relay policy. If that is enough reason for you to run it, that is a perfectly coherent choice. Just choose it for what it actually does.

How to replicate Knots' stricter defaults on Bitcoin Core

You do not need to switch clients to get a stricter mempool. Bitcoin Core exposes the same policy knobs; Knots mostly just ships them pre-tightened. If your goal is a restrictive relay policy and you also want Core's release cadence and ecosystem support, set these in your bitcoin.conf:

# Refuse to relay/mine any OP_RETURN (datacarrier) outputs at all
datacarrier=0

# If you prefer to allow OP_RETURN but cap its size (bytes),
# set datacarrier=1 and a size instead of datacarrier=0:
# datacarrier=1
# datacarriersize=83

# Do not relay or mine bare multisig outputs
# (an old data-embedding vector that bloats the UTXO set)
permitbaremultisig=0

What each setting does:

• datacarrier=0 — Your node will not accept or relay transactions whose only non-standard feature is an OP_RETURN data output, and your node's wallet/mining template will not create them. This is the blunt "no data" switch. Note: in v30 the DEFAULT datacarriersize was raised to 100,000 bytes (effectively uncapped), but the datacarrier and datacarriersize options themselves remain fully supported and configurable. Still confirm the exact behavior in your installed version's release notes.
• datacarriersize=N — If you keep datacarrier=1, this caps the maximum size (in bytes) of the OP_RETURN scriptPubKey your node will relay. Setting it to 83 reproduces the historical Core default (83 bytes is the aggregate OP_RETURN scriptPubKey size Core enforced before v30; the often-quoted 80 bytes is the maximum single data push inside that envelope).
• permitbaremultisig=0 — Refuses to relay "bare" (non-P2SH) multisig outputs. These are a legacy channel for stuffing data into spendable-looking outputs that linger in the UTXO set. Turning this off is arguably the most defensible filter because bare-multisig data does create permanent UTXO bloat, unlike OP_RETURN.

After editing bitcoin.conf, restart bitcoind (or bitcoin-qt) for the changes to take effect. No reindex is required to change relay policy — these settings affect new transactions entering your mempool going forward, not historical blocks you have already validated. Always confirm the precise option names and behaviors against the release notes for your installed version, since policy options are exactly the area where Core has been changing defaults. For a general primer on keeping a node correctly configured and updated through protocol changes, see our guide to node health and protocol updates.

Switching implementations on a prebuilt node (Umbrel, Start9, RaspiBlitz)

If you run a packaged node platform rather than bare bitcoind, swapping the underlying implementation depends on what the platform supports:

• Start9 (StartOS) historically makes the implementation explicit: Bitcoin Core and Bitcoin Knots have been offered as selectable services in the marketplace, so switching can be as direct as installing the other service. Your existing chainstate may or may not be reusable depending on how the service handles its data directory.
• Umbrel now offers Bitcoin Knots as a dedicated app in its App Store alongside the Bitcoin Core app, so switching can be a one-click install — but your chainstate may not transfer automatically between the two apps, so check before assuming a seamless swap.
• RaspiBlitz is script-driven and lets advanced operators change the Bitcoin implementation, but expect to do it via the menu/config rather than a GUI button.

Two practical cautions when switching:

1. Reindex implications. Because Core and Knots share consensus rules and on-disk formats, you can often point the new client at the existing blocks/ and chainstate/ directories and avoid a full re-download. But version skew matters: if the new client is older than the data was written by, or expects a different database version, it may demand a -reindex (re-validate from local block files, hours) or even a fresh sync. Back up before swapping and budget time for a possible reindex.
2. Verify your build. The whole point of running your own node is "don't trust, verify." Whichever client you install, prefer reproducible builds and verify the release signatures / hashes against the maintainers' published values before running it. A node binary you did not verify is a trust assumption you did not need to make.

If you are still choosing between packaged platforms in the first place, our comparison of Umbrel vs Start9 and the step-by-step Umbrel and Start9 setup guide walk through the tradeoffs. For a from-scratch path, see how to run a Bitcoin full node in 2026.

Who should run which: an honest decision framework

Decide by operator type and what you actually care about — not by tribe.

Run Bitcoin Core if…

• You want the broadest ecosystem and tooling compatibility (wallets, Lightning implementations, indexers, and Lightning Service Providers almost universally test against Core first).
• You value a multi-maintainer release process and a large contributor base for security review and timely releases.
• You are fine with the default permissive relay policy, or you are comfortable setting your own policy via bitcoin.conf (see above) to get strictness without leaving Core.
• You run anything that depends on the node behaving exactly like the reference implementation.

Run Bitcoin Knots if…

• You want strict, opinionated relay defaults out of the box and would rather not manage policy flags yourself.
• You specifically want your node to not relay data transactions as a matter of principle, and you understand this is a propagation/values lever, not a consensus protection.
• You are comfortable with a primarily single-maintainer, downstream release model and slightly later access to upstream changes.
• You do not depend on tooling that is only validated against Core's exact behavior.

It genuinely does not matter much if…

• You run a node mainly to verify your own transactions and enforce the rules for yourself. Both clients validate identically, so either one gives you full self-verification.
• You are sizing hardware and just want something that syncs and stays online — both have the same hardware requirements because they store and validate the same chain.

The maximalist-sounding takeaway is the unglamorous one: pick based on the maintainer/release model you trust and the mempool policy you personally want to relay. Anyone telling you that one client "saves Bitcoin" and the other "attacks Bitcoin" is selling tribe, not engineering. Both are full nodes that enforce the same rules. The network is healthier when operators run a diversity of well-maintained implementations and understand exactly what their settings do.

Frequently Asked Questions

{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Will switching to Bitcoin Knots fork me off the network?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “No. Bitcoin Knots is a downstream fork of Bitcoin Core that keeps the consensus rules identical. A block valid under Core is valid under Knots and vice versa. Knots differs only in relay/mempool policy — what it chooses to forward to peers — which never causes it to reject a consensus-valid block. You will stay on the same chain as everyone else regardless of which of the two you run.”}}, {“@type”: “Question”, “name”: “Does running Knots stop spam or data inscriptions from being added to the blockchain?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “No. Relay policy is local and advisory. Your strict node will refuse to gossip transactions you filter, which adds friction at the margins, but it cannot stop miners from including those transactions in blocks — and miners frequently receive large data transactions through direct submission or private relay that bypasses the public mempool entirely. Once such a transaction is mined, your node validates and accepts the block because it is consensus-valid. Filtering expresses your values and slightly slows propagation; it does not remove or prevent data on-chain.”}}, {“@type”: “Question”, “name”: “Can I get Knots’ strict filtering without leaving Bitcoin Core?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. Core exposes the same policy knobs; Knots mostly ships them pre-tightened. In your bitcoin.conf, set datacarrier=0 to refuse OP_RETURN data outputs (or keep datacarrier=1 with datacarriersize=83 to cap them at the historical default), and permitbaremultisig=0 to refuse bare multisig outputs. Restart bitcoind to apply — no reindex is needed for relay-policy changes. Always confirm the exact option behavior in your installed Core version’s release notes, since these defaults have been changing.”}}, {“@type”: “Question”, “name”: “Why did Bitcoin Core v30 remove the OP_RETURN size limit?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “The maintainers argued the roughly 80-byte limit had stopped working as intended. Data was being embedded anyway through channels the limit never covered (such as Taproot witness data), and some workarounds were worse for the network — bloating the UTXO set or pushing deals out-of-band to miners and away from the public mempool. Removing an ineffective relay filter makes the default node’s mempool a more accurate preview of what miners actually mine. It was a policy change, not a consensus change, and operators who disagree can still configure a stricter policy or run Knots.”}}]}