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

Update (3 November 2026): we wrote this comparison in June 2026, when Bitcoin Core and Bitcoin Knots followed the same chain. They no longer do. On 8 August 2026, Knots nodes enforcing BIP-110 split from the chain Bitcoin Core follows, and since Knots 29.4.1 (2 September 2026) Knots follows a separate chain with a BLAKE2b proof of work. If you run Knots, read what changed and how to check which chain your node is on before you send or receive.

Short answer (updated 3 November 2026): when we wrote this, Bitcoin Core and Bitcoin Knots followed the same chain, and we described the difference between them as one of relay and mempool policy, meaning what each node is willing to accept and forward to its peers by default. That is no longer the whole story. Knots 29.4.1 and later follow a different chain from Bitcoin Core, with a BLAKE2b proof of work (a hard fork, according to Knots' release notes). Policy-only differences cannot fork the chain; consensus changes can, and in August 2026 one did. So the first decision is now which chain you want your node on. Only after that comes the original question: which maintainer and release model you trust, and which transactions you personally want to relay. If you want a strict relay policy on the chain Bitcoin Core follows, a few lines of bitcoin.conf on Core will do it (see below). We describe what each client does and quote each side in its own words.

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.

Update, 3 November 2026: Core and Knots now follow different chains

Until August 2026 the two clients followed the same chain, and the rest of this article, written in June, describes that situation. It changed in two steps.

1. 8 August 2026: the BIP-110 split. BIP-110, the "Reduced Data Temporary Softfork" (Knots calls it RDTS), is a consensus change, not a relay setting. Knots 29.3 shipped it in May 2026 as an opt-in that asked for explicit confirmation (consensusrules=rdts in bitcoin.conf). Under BIP-110, blocks 961632 to 963647 had to signal for it, and nodes enforcing it rejected blocks that did not. Most SHA256d mining power kept producing blocks that did not signal. The pull request that closed BIP-110 in the BIPs repository, merged on 10 August, describes what happened: "BIP 110 was released on mainnet by Knots and entered its mandatory signaling period today (8th August 2026), rejecting non-signaling blocks. It split to a new chain and stalled." (BIPs PR #2245). Bitcoin Optech called it an "unsuccessful activation attempt".
2. 2 September 2026: Knots 29.4.1 and the BLAKE2b hard fork. Knots 29.4.1 changed the proof of work from SHA256d to BLAKE2b at a fixed block height (a flag day), activated the BIP-110 rules at the same height, set a temporary 800 kWU block weight limit and dropped the BIP-110 opt-in. Its release notes call this "a backward-incompatible protocol change" and list it as "Hardfork: New BLAKE2b proof-of-work algorithm". According to bitcoin-blake2b.org, the first BLAKE2b block is 961640, dated 30 August 2026. Knots 29.4.2 and 29.4.3 (21 September and 28 October) then made newly mined coins on that chain wait longer before they can be spent: 45 days, and about 180 days from block 979919.

The two sides describe the result in opposite terms. Knots' 29.4.1 release notes call the SHA256d chain "a new altcoin launched by former miners" and the events of 8 August "the biggest attack on the Bitcoin network to date". The page those notes link to (bitcoinknots.org/learn/2026-blake2b, which now redirects to bitcoin-blake2b.org) says the BLAKE2b rules keep Bitcoin "as money only by rejecting use of the network for arbitrary data storage". The BIPs repository, which now lists BIP-110 as Closed, and Bitcoin Optech describe the same events as an activation that failed and a chain that "stalled". Bitcoin Core, mempool.space and most SHA256d mining power stayed on the SHA256d chain. In this article we call the two networks the SHA256d chain and the BLAKE2b chain.

What this means if you run a node:

• Policy-only differences cannot fork the chain; consensus changes can, and in August 2026 one did. Relay settings such as datacarrier still never make a node reject a valid block. BIP-110 and the BLAKE2b proof of work are consensus rules, so nodes that enforce them follow a different chain.
• Knots 29.4.1 and later follow the BLAKE2b chain. Bitcoin Core follows the SHA256d chain. Choosing between the two clients now means choosing a chain, not just a relay policy.
• Both chains share their history up to the split. bitcoin-blake2b.org says "Coins created before the fork stay spendable after it", so the same coins show up on both chains. Until you have checked which chain your node is on, don't send or receive with a wallet that relies on it.
• Code base. Bitcoin Core's 32.1 release notes (late October 2026) say that "versions 29.x and older are at 'End of Life' and will no longer receive updates". Knots' latest release, 29.4.3 (28 October 2026), is still built on the 29.x code base, which the Knots project maintains itself.
• Umbrel users. The Bitcoin Knots app on Umbrel (app 1.2.13 = Knots v29.4, last updated 8 August 2026) says it "adds BIP 110 code" and asks you to "accept or switch to another version" in the Umbrel interface. If you accepted, your node enforces BIP-110. We have not tested on a live Umbrel which chain such a node ended up on, so check yours.

How to check which chain your node is on

mempool.space shows the SHA256d chain. Compare its latest block with your node:

# your node's height ("blocks") and tip ("bestblockhash")
bitcoin-cli getblockchaininfo

# the hash your node has at a given height, to compare with mempool.space
bitcoin-cli getblockhash <height>

The same commands work on Core and on Knots. If your node is synced and its height and hash match mempool.space (allowing for a block or two of delay), it is on the SHA256d chain. If its height sits far behind and stops moving, or its hash at the same height differs, your node is following another chain. Either way, decide which chain you want before you move any funds.

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. Until May 2026, Bitcoin Core and Bitcoin Knots shipped the same consensus rules, because Knots, a downstream fork of Core, kept them identical on purpose. Knots 29.3 (May 2026) added BIP-110 as an opt-in consensus change, and Knots 29.4.1 (September 2026) changed the proof of work: see the update above.
• 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, for the filtering debate, "which client protects Bitcoin" is the wrong question. 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. Consensus changes work differently. No client can impose one on the rest of the network, but each client decides which rules its own users enforce, and that decides which chain those users follow. 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 has periodically rebased on top of Bitcoin Core releases and layered 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. Its current releases (29.4.x) are still based on Core 29.x, while Core has moved on to 32.1. Since 2026 Knots also ships consensus changes of its own (BIP-110, then the BLAKE2b proof of work, covered in the update above); the rest of this section is about its relay policy.

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 has historically tracked Core's releases and then added 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

Dimension	Bitcoin Core (v30+)	Bitcoin Knots
Consensus rules	Reference implementation; SHA256d proof of work	Same as Core until May 2026. 29.3–29.4: BIP-110 as an opt-in. 29.4.1 and later: BLAKE2b proof of work plus BIP-110 rules (a hard fork, according to its release notes)
Default OP_RETURN / datacarrier policy	Default raised to 100,000 bytes (effectively uncapped; relays large data)	Restrictive by default (limits / can refuse data relay)
Default mempool / relay posture	Permissive: mempool aims to mirror what miners mine	Stricter: filters more "non-monetary" transactions
Maintainership	Many contributors, multiple maintainers, formal process	Primarily one maintainer (Luke Dashjr) rebasing on Core
Release cadence	Regular, well-resourced release cycle	Has historically tracked Core, then added patches (slower, downstream); current releases are still on Core's 29.x base
GUI (bitcoin-qt)	Yes	Yes
Tooling / LSP / wallet ecosystem support	Broadest; the default target for almost all software	Largely RPC-compatible with Core; some tooling tests against Core only, and since 29.4.1 "other software, such as third-party wallets, may require upgrades to remain compatible" (Knots release notes)
Reproducible / verifiable builds	Yes (Guix)	Yes (Guix)
Which chain it follows (3 Nov 2026)	The SHA256d chain (the one mempool.space shows)	29.4.1 and later: the BLAKE2b chain

Notice what the table does not contain: any row where one client is "more Bitcoin" than the other. Until August 2026 the differences lived in policy, governance and ecosystem support. The first and last rows are about consensus, and they decide which chain your node is on.

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.

Everything in this section is about relay filters, which you can run on either client. BIP-110 was a different kind of tool: a consensus rule. Nodes enforcing it did reject blocks, and that is how the August 2026 split happened (see the update above).

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, its ecosystem support and the chain Core follows, set these in your bitcoin.conf (all three options are still in Bitcoin Core 32.1, checked in its source code in November 2026):

# 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, and they are still there in 32.1. 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. Since the August 2026 split, moving from Core to a current Knots release, or back, also means moving to the other chain (see the update above).

• 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. The current app (1.2.13, Knots v29.4) "adds BIP 110 code" and asks you to accept it or switch to another version, so it is no longer a like-for-like 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. While Core and Knots shared consensus rules and on-disk formats, you could often point the new client at the existing blocks/ and chainstate/ directories and avoid a full re-download. Since the August 2026 split, a data directory that has followed one chain past the split holds blocks the other client does not accept, so don't count on reusing it. Version skew also 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 reindex or a full re-sync.
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. Since August 2026 the first decision is which chain you want your node to follow: Bitcoin Core follows the SHA256d chain, and Knots 29.4.1 and later follow the BLAKE2b chain. The lists below cover the rest.

Run Bitcoin Core if…

• You want your node on the SHA256d chain, the one mempool.space shows and most SHA256d mining power mines.
• 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 your node on the chain Knots follows: since 29.4.1, the BLAKE2b chain with BIP-110 rules.
• 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 with a 29.x code base that Knots maintains itself (Core put 29.x at end of life with 32.1 in October 2026).
• You do not depend on tooling that is only validated against Core's exact behavior.

If you mainly want self-verification, or are sizing hardware

• You run a node mainly to verify your own transactions and enforce the rules for yourself. Either client gives you full self-verification of the rules it enforces. Since August 2026 those rules differ, so pick the chain first.
• You are sizing hardware and just want something that syncs and stays online. The history up to the August 2026 split is the same on both chains, so the hardware requirements are a fair guide for either client.

The takeaway is the unglamorous one. First decide which chain you want your node to follow; we have quoted both sides so you can judge that on what each project says and does. Then pick the maintainer and release model you trust and the mempool policy you want to relay. On relay policy, anyone telling you that one client "saves Bitcoin" and the other "attacks Bitcoin" is selling tribe, not engineering. Running more than one well-maintained implementation helps the network as long as they agree on consensus and their operators know exactly what their settings do.

Frequently Asked Questions