Bitcoin Core vs. Knots: Versions, Defaults and Node Share, Checked Against the Source Code
The Core vs. Knots argument is loud. The differences themselves are a handful of default settings, and every one of them can be read in the code.
The short answer: Bitcoin Core and Bitcoin Knots follow the same consensus rules, so they accept the same blocks and stay on the same chain. They differ in relay policy defaults: Core 30 and later relay OP_RETURN data up to 100,000 bytes [2][3], while Knots 29.4.2 keeps an 83-byte limit, rejects token transactions by default and uses a minimum relay fee ten times higher [5]. On October 7, 2026, 16.5% of reachable nodes ran Knots, per Bitnodes [7].
For the history of the dispute and the arguments on each side, read our Core vs. Knots explainer. This page answers the narrower factual questions, with each default taken from the release tags themselves. The rest of our network coverage tracks hashrate and blocks from our own node.
Knots is built on Core, with extra patches on top
Because the consensus code is shared, a Knots node and a Core node accept exactly the same blocks. Neither can make the other fork off the chain by relaying or refusing a transaction.
The latest versions are Core 32.0 and Knots 29.4.2
As of October 22, 2026, the newest Core version is 32.0, tagged in the repository on October 21, 2026 [1]. The official binaries and the bitcoincore.org release page were not yet out that day. The previous final release is 31.1, published on July 8, 2026 [1].
The latest Knots release is 29.4.2.knots20260508 [6]. The version string tells you its base: Core's 29 line, plus Knots' own release stamp, 20260508. So a Knots node today runs on a Core base three major versions older than the newest Core release. If you move between the two, read both release notes for downgrade or data-migration warnings first.
The OP_RETURN default is 100,000 bytes in Core and 83 in Knots
Core 30.0, published on October 10, 2025, raised the default -datacarriersize to 100,000 bytes,
which its release notes describe as effectively uncapping the limit; it also started relaying
transactions with more than one OP_RETURN output [2]. In Core 31.1's source, the default is defined
as the maximum standard transaction weight divided by four, which is that same 100,000 [3].
Knots 29.4.2 defines the default as 83 bytes: 80 bytes of data, plus one byte for the OP_RETURN
opcode and two for the push opcodes [5]. It also has -datacarrierfullcount, on by default, which
applies that limit to all the data-carrying methods Knots recognises, not just OP_RETURN [5].
Knots also rejects token transactions by default
Two more Knots defaults have no Core equivalent. -rejecttokens is on by default and refuses to
relay or mine "transactions involving non-bitcoin tokens"; -rejectparasites refuses "parasitic
overlay protocols" [5]. Knots also keeps a minimum relay fee of 1,000 sats per thousand virtual
bytes, 1 sat/vB, where Core 31.1 uses 100, or 0.1 sat/vB [3][5].
None of these settings changes which blocks a node accepts. They change which unconfirmed transactions it passes along and, if it mines, which ones it puts in its own blocks.
Knots versions expire; Core versions don't
Knots ships with a built-in expiry. Its source sets the default -softwareexpiry to roughly two
years after the release's copyright year, 2026 for 29.4.2, and warns four weeks ahead [5]. The
Knots website explains that an expired version can be restored by adding softwareexpiry=0 to
bitcoin.conf, and warns that obsolete versions are not maintained [6]. Core 31.1 has no
-softwareexpiry option at all [3].
If you run Knots on a machine you rarely touch, put the expiry date in your calendar. Our Core 32 node operator checklist covers the upgrade side for Core.
About one reachable node in six runs Knots
On October 7, 2026, the Bitnodes crawler counted 4,111 Knots nodes out of 24,881 reachable ones, 16.5%, with 83% running Core [7]. Only 80 of the Knots nodes ran the RDTS build tied to BIP-110, which our BIP-110 playbook covers. Bitnodes did not respond when we tried to refresh the count on October 19, 2026, so these remain the latest figures we have read directly.
Crawlers only see nodes that accept incoming connections, so nodes behind a firewall go uncounted on both sides. Treat the share as a direction, not a census.
Sources
- Bitcoin Core, Bitcoin Core 32.0 release notes at the v32.0 tag, and Bitcoin Core 31.1 release notes, published July 8, 2026; repository tags checked October 22, 2026. (Primary, official)
- Bitcoin Core, Bitcoin Core 30.0 release notes, published October 10, 2025. (Primary, official)
- Bitcoin Core, source at tag v31.1: src/policy/policy.h (
MAX_OP_RETURN_RELAY,DEFAULT_MIN_RELAY_TX_FEE) and src/init.cpp. (Primary, source code) - Bitcoin Knots, README, "Development Process". (Primary, project documentation)
- Bitcoin Knots, source at tag v29.4.2.knots20260508: src/policy/policy.h, src/init.cpp, src/node/mempool_args.cpp and src/init.h. (Primary, source code)
- Bitcoin Knots, bitcoinknots.org, download page and maintenance notes, checked October 19, 2026. (Primary, project website)
- Bitnodes, snapshot of reachable nodes and their user agents, October 7, 2026, 06:34 UTC, as recorded in our Core vs. Knots explainer. (Secondary for this page: our earlier reading of a third-party crawler)
Want to see how hashrate splits across mining pools, calculated from our own node? Check our network coverage.
More in Network and mining
Last updated: October 22, 2026