Bitcoin Core vs Bitcoin Knots: Full Node Comparison

Bitcoin Core vs Bitcoin Knots at a Glance

Bitcoin Core and Bitcoin Knots are the two most widely run full node implementations on the Bitcoin network. Core is the reference implementation maintained by a team of five developers with commit access and hundreds of contributors. Knots is a patch set maintained by Luke Dashjr that layers additional configuration options and stricter default policies on top of Core's codebase.

The differences between them became a major point of contention in 2025 when Bitcoin Core v30 expanded the OP_RETURN data limit from 83 bytes to 100,000 bytes. Knots refused to adopt the change, and its node share surged from roughly 3% to over 25% of reachable nodes as operators migrated in protest.

For a broader overview of all available node implementations, see the Bitcoin node software comparison and our guide on which Bitcoin node you should run.

What Is Bitcoin Core?

Bitcoin Core is the direct descendant of Satoshi Nakamoto's original Bitcoin client. It serves as the reference implementation that defines Bitcoin's consensus rules in practice. As of mid-2026, Core has five maintainers with commit access: Ava Chow, Michael Ford, Ryan Ofsky, Hennadii Stepanov, and TheCharlatan. Hundreds of developers contribute code through a public pull request process on GitHub.

Core's development philosophy prioritizes stability, broad compatibility, and conservative changes. New features go through extensive peer review before merging. Major releases ship roughly every six to twelve months, with maintenance releases in between. The v30.0 release in October 2025 was its most controversial in years, primarily because it raised the datacarriersize limit for OP_RETURN outputs from 83 bytes to 100,000 bytes.

For a deeper look at Core's governance structure, see our research on the Bitcoin Core governance and development model.

What Is Bitcoin Knots?

Bitcoin Knots is a patch set maintained by Luke Dashjr, one of Bitcoin's earliest developers. Dashjr has contributed to Bitcoin since 2011, serves as a BIP Editor, and is CTO of the OCEAN mining pool. Knots layers additional features and stricter default policies on top of Bitcoin Core's codebase.

Knots intentionally did not rebase onto Core v30. It continues tracking the v29.x branch, preserving the pre-v30 OP_RETURN limits while adding its own filtering capabilities. The project's philosophy centers on preserving Bitcoin's original purpose as peer-to-peer digital money. Dashjr considers non-financial data storage on the blockchain (such as Ordinals inscriptions and Runes tokens) to be spam that degrades network performance.

Mempool Policy and Spam Filtering

The most significant difference between Core and Knots is how they handle mempool policy. Both implementations let operators configure which transactions their node will relay and include in the mempool, but their defaults diverge sharply.

Knots ships with restrictive defaults designed to filter what Dashjr considers spam. Core ships with permissive defaults that relay all standard transactions regardless of their data content.

The rejectparasites option is unique to Knots. It filters Ordinals-style inscription transactions that embed arbitrary data in Taproot witness scripts. Dashjr considers it a bug that Core's datacarriersize limit was never updated to cover data-carrying methods introduced by SegWit and Taproot, which allowed inscriptions to bypass the limit by disguising data as program code.

Knots also exposes many additional policy knobs that Core does not surface: script and sigop limits, dust relay fee tuning, ancestor and descendant limits, block template sizing overrides, and coin-age relay floors. The philosophy is to give node operators maximum control over what their node relays.

GUI and RPC Differences

Beyond policy defaults, Knots adds several features to the graphical interface and RPC layer that Core does not include.

GUI additions in Knots:

• Sweep Private Key dialog for importing funds from a private key
• NetWatch tab for live network activity monitoring
• BIP-93 codex32 seed import support
• Legacy wallet loading (removed from Core v30)
• More granular mempool and policy configuration panels

RPC extensions in Knots:

• sweepprivkeys for sweeping UTXOs from private keys (supports p2pk, p2pkh, p2wpkh, and p2tr formats)
• Mining RPC parameter overrides for blockmaxsize, blockmaxweight, and minfeerate
• Restored UPnP support (removed from Core for security reasons)
• Tor onion-service Proof-of-Work DoS defenses (since v29.3)

Core's GUI is intentionally minimal. The development team considers stability and auditability more important than feature breadth in the graphical interface. Most advanced operations are expected to go through the RPC or CLI.

Development and Security Model

The security implications of running either implementation come down to the development model behind each project.

Bitcoin Core has a transparent, multi-maintainer development process. Pull requests are publicly reviewed before merging. Merge commits are signed. The project has a dedicated security disclosure process and a track record spanning over a decade. Its large contributor base means more eyes on the code, which generally translates to fewer undetected bugs.

Bitcoin Knots has a single maintainer. All patch review, merging, and release decisions flow through Luke Dashjr. Critics (notably Jameson Lopp) have raised concerns about this single point of failure: the merge process is less transparent than Core's, and Dashjr's server was compromised in late 2022. Supporters counter that Knots' stricter default policies actually reduce attack surface by rejecting more transaction types.

Both implementations enforce the same consensus rules on mainnet. The one exception was the BIP-110 experiment in Knots' RDTS build, which attempted to enforce new data-limiting consensus rules in August 2026. The fork activated at block 961,632 with only 2.53% hash power support, mined two blocks, and effectively failed. No sustained chain split occurred.

The OP_RETURN and Ordinals Debate

The philosophical divide between Core and Knots centers on a fundamental question: should Bitcoin nodes filter transactions based on their data content?

Core's position is that mempool policy should not discriminate based on what data a transaction carries, as long as it follows consensus rules. The v30 expansion of datacarriersize to 100,000 bytes reflects this view: users will embed data on-chain regardless of relay policy, so it is better to channel that data into OP_RETURN outputs (which are provably unspendable and can be pruned) than to force it into other, less efficient encoding methods.

Knots' position is that Bitcoin's block space should be reserved for financial transactions. Non-financial data consumes scarce block space, increases UTXO set bloat, drives up fees for legitimate users, and degrades the network. Filtering this data at the relay level is a valid exercise of node operator sovereignty.

The OCEAN mining pool, where Dashjr serves as CTO, implements this philosophy in practice. OCEAN offers miners three block template options: a Knots template that filters inscriptions with a 42-byte OP_RETURN maximum, a partial filtering template, and an unmodified Core policy template. Inscription transactions can be included by paying a 2% premium fee.

For more context on how node implementations handle these tradeoffs, see our Bitcoin node implementation comparison.

Which Should You Run?

The right choice depends on what you want from your Bitcoin node.

Choose Bitcoin Core if:

• You want the reference implementation with the broadest peer review
• You prefer a multi-maintainer security model
• You run infrastructure that needs maximum compatibility with the network
• You want the latest protocol features (v30 and beyond) as they ship
• You do not want to take a position on transaction content filtering

Choose Bitcoin Knots if:

• You want stricter default relay policies to filter inscriptions and Runes
• You need additional GUI features (sweep keys, NetWatch, codex32)
• You want fine-grained control over mempool policy settings
• You need legacy (BDB) wallet support that Core v30 removed
• You philosophically oppose the v30 OP_RETURN expansion

Operators running pruned nodes or archive nodes can use either implementation. Both support the same pruning modes and sync strategies, including AssumeUTXO fast sync.

Frequently Asked Questions

Is Bitcoin Knots safe to run?

Bitcoin Knots enforces the same consensus rules as Bitcoin Core on mainnet (the BIP-110 RDTS build was a separate, opt-in experiment that failed). The main security concern is the single-maintainer model: all patches flow through one person, which creates a narrower review pipeline than Core's multi-maintainer process. If you are comfortable with that tradeoff and want stricter relay defaults, Knots is a viable option.

Does running Bitcoin Knots cause a chain split?

No. Knots and Core follow the same consensus rules and validate the same blockchain. The differences are in relay policy (which transactions your node forwards to peers) and default configuration, not in block validation. The BIP-110 activation attempt in August 2026, which did diverge on consensus, attracted only 2.53% hash power and failed without causing a sustained split.

Can Bitcoin Knots actually block Ordinals and inscriptions?

Knots can prevent your node from relaying inscription transactions through the rejectparasites setting. However, this does not prevent inscriptions from being included in blocks. Miners running Core (or Knots with filtering disabled) will still mine inscription transactions. Your Knots node will still validate and accept blocks containing inscriptions: the filtering applies only to mempool relay, not to consensus.

Why did Bitcoin Core raise the OP_RETURN limit in v30?

Core developers argued that users were already embedding large amounts of data on-chain using less efficient methods (such as encoding data in Taproot witness scripts). Raising the OP_RETURN limit to 100,000 bytes channels that data into provably unspendable outputs, which nodes can prune. The alternative: data hidden in witness scripts that nodes must retain in the UTXO set indefinitely: was considered worse for the network long-term.

How many nodes run Bitcoin Knots?

Knots' share of reachable nodes surged from roughly 3% in early 2025 to a peak of about 25% in September 2025, driven by opposition to Core v30's OP_RETURN changes. The exact count fluctuates daily and only measures publicly reachable nodes (many nodes sit behind firewalls and are not counted). Services like Bitnodes provide live estimates of current node distribution.

Can I switch between Bitcoin Core and Bitcoin Knots?

Yes. Both use the same data directory format and blockchain data. You can stop Core, install Knots (or vice versa), and start it on the same data directory without re-syncing the blockchain. Back up your wallet file before switching. Note that Knots tracks Core v29.x, so switching from Core v30 to Knots may trigger a downgrade warning: check the release notes for any migration steps.

What is BIP-110 and why did it fail?

BIP-110 was a proposal, enforced in Knots' RDTS build, to limit arbitrary data in Bitcoin transactions at the consensus level. It activated at block 961,632 on August 8, 2026, but attracted only 2.53% of hash power. The minority chain mined just two blocks in eight hours before effectively dying. The outcome demonstrated that policy changes without broad miner and community support cannot succeed as soft forks.

This tool is for informational purposes only and does not constitute financial advice. Node counts, version numbers, and policy defaults change over time. Always verify current data on the official Bitcoin Core and Bitcoin Knots release pages before making infrastructure decisions.