---

name: bitcoin-knots description: | Bitcoin Knots: Luke Dashjr's Bitcoin Core fork with stricter mempool policy and additional configuration. Since the 2026 BIP-110 and BLAKE2b hardforks it is also a separate consensus network, not only a policy downstream. Differences vs Core, when to consider, compatibility. USE WHEN: evaluating Knots for stricter mempool policy, reviewing a node deployment that uses Knots, understanding policy and consensus divergence between Core and Knots. allowed-tools: Read, Grep, Glob

Bitcoin Knots

Bitcoin Knots is a fork of Bitcoin Core maintained primarily by Luke Dashjr. It applies a series of patches on top of each Core release, historically focused on mempool / standardness policy, additional options, and stricter defaults.

As of September 2026 this is no longer only a policy fork. Current Knots releases carry consensus changes — BIP-110 (RDTS) and a BLAKE2b proof-of-work hardfork — and follow a different chain from Bitcoin Core. See Consensus rules before deploying anything.

Key differences from Core

Mempool policy

• Stricter standardness for what can be relayed:
  • OP_RETURN / datacarrier: -datacarriersize defaults to 83 bytes of scriptPubKey (MAX_OP_RETURN_RELAY in src/policy/policy.h at v29.4.1.knots20260508), and only one nulldata output per tx is relayed (multi-op-return reject). Bitcoin Core 30.0 (October 2025) raised its own default to 100,000 and relays multiple nulldata outputs, so this is now the widest policy gap — see Relay policy since 30.0. Knots' own 83 is a raise from 42, made in v29.2.knots20251110 (2025-11-10) and described in those release notes as temporary, to be "reverted back to 42 in a future version".
  • More aggressive filtering of inscriptions / non-standard tx patterns by default.
• -rejectparasites and similar flags to refuse to relay txs Luke considers spam (in particular Ordinals/inscriptions in some configurations). These are on by default in current releases, not opt-in: src/policy/policy.h at v29.4.1.knots20260508 has DEFAULT_REJECT_PARASITES{true}, DEFAULT_REJECT_TOKENS{true}, DEFAULT_PERMIT_BAREMULTISIG{false} and DEFAULT_PERMITBAREDATACARRIER{false}. -rejecttokens was flipped to default-on in v29.4.1 and also detects Counterparty transactions.

Additional options

Some options exist in Knots but not Core (e.g., specific spam-filter heuristics, more granular feature toggles). Always cross-reference the Knots docs for the version in use.

Consensus rules: policy-only until 2026

Historically (through v29.3.knots20260210, 2026-02-10) Knots did not modify consensus. A Knots node validated the same blockchain as a Core node, and the two diverged only at the mempool / relay layer:

• A tx accepted by Core's mempool may be rejected by Knots and vice versa.
• A miner using Knots may exclude txs Core would have included, and produce blocks Core nodes still accept.

That still describes the policy delta, but it is no longer the whole picture. Two consensus changes landed in 2026:

• BIP-110 "Reduced Data Temporary Softfork" (RDTS) shipped in v29.3.knots20260508 (2026-05-09). Enforcement was opt-in in that release — it required consensusrules=rdts in bitcoin.conf or a GUI confirmation — and a non-RDTS build of the same version was published as v29.3.knots20260507 (2026-05-08). BIP-110 signals on version bit 4 with a 1109/2016 (55%) threshold, and makes blocks that do not signal bit 4 invalid across blocks 961632-963647. The RDTS consent requirement was removed again in v29.4.1 (knots#362).
• A BLAKE2b proof-of-work hardfork shipped in v29.4.1.knots20260508 (2026-09-02). Its release notes state that mitigating the situation "requires a backward-incompatible protocol change", and list a BLAKE2b PoW algorithm, a temporary 800 kWU block weight limit (~300 kB), RDTS activation at the PoW-change flag day, and fixes for CVE-2013-2292 / CVE-2020-14199 / CVE-2017-12842.

What happened in practice: at block 961,632 (2026-08-08) AntPool mined the first non-signaling block. The main network accepted it; BIP-110 nodes rejected it and followed a minority chain that produced two blocks in roughly eight hours while the main chain advanced 48, then stalled — only 2.53% of blocks had signaled bit 4 over the preceding two weeks, against the 55% threshold. BIP-110 was marked Closed in the BIPs repo on 2026-08-09. Per bitcoinknots.org, BLAKE2b then activated as a flag day at block 961,640 of the Knots chain (2026-08-30), with the RDTS data limits running to 2027-09-01.

Running a current Knots release means following a different chain, under a different proof-of-work algorithm. As of September 2026 that is a hard fork, not a configuration preference. Builds are identified by their date suffix, not their base version: everything up to and including v29.3.knots20260210 (2026-02-10), plus the non-RDTS v29.3.knots20260507, still validates the same chain as Bitcoin Core. RDTS enforcement starts at v29.3.knots20260508 and is unconditional from v29.4.1.knots20260508.

When to consider Knots

Rows below are for the current release line (v29.4.x, which is consensus-incompatible with Core as of September 2026):

Use case	Knots?
Default Bitcoin node	No (use Core; ~83% of public nodes do, Sept 2026)
Strict spam filter at the relay layer	Only on an RDTS-free build (up to v29.3.knots20260210, or v29.3.knots20260507); current releases change consensus too
Mining with custom policy	No — current Knots mines a BLAKE2b chain that Core rejects
Lightning service	No (Core is the standard, better support)
Block explorer / indexer	No (Core has better tooling support)
Deliberately following the Knots/BLAKE2b chain	Yes — that is what the current line is for; treat it as a separate network

Compatibility

• RPC: near-identical to Core, with Knots-specific extensions. v29.4.1 added block header fields to getblockheader / getblock: txcount (replacing the deprecated nTx), header_version, nonce2, nonce3, extranonce, time_offset, header_flags, xor_key, xor_key_mask_clear_bits and mm_rhs.
• ZMQ: identical.
• File formats: identical (cookie, debug.log, wallet.dat, descriptors).
• P2P: same protocol and message types, but v29.4.1 added a NODE_BLAKE2B service bit and prefers those peers over NODE_REDUCED_DATA (knots#368), and bases DNS-seed cadence on the NODE_BLAKE2B peer count (knots#386).

An RDTS-free Knots node (up to v29.3.knots20260210, or v29.3.knots20260507) in your network is indistinguishable from a Core node to peers — only the mempool admission decisions differ. A v29.4.x node is not: it validates a different chain, so blocks are not interchangeable in either direction.

Releases

• Tagged based on Core releases: vX.Y.Z.knots20YYMMDD.
• Released after each Core minor version, with a delay of weeks-months.
• Backports of Core bugfixes are applied along with Knots-specific patches.
• Current release as of 2026-09-15 is v29.4.1.knots20260508 (published 2026-09-02), preceded by v29.4.knots20260508 (2026-08-07), the v29.3.knots20260508 / v29.3.knots20260507 pair (2026-05-09 / 2026-05-08) and v29.3.knots20260210 (2026-02-10).
• Knots is still on the 29.x base while Bitcoin Core's own line has reached v31.1 (2026-07-08), so "based on the current Core release" no longer holds.
• Subversion strings append a separate Knots:<date>/ segment after the base-version field: current builds report /Satoshi:29.4.1/Knots:20260508/, 2024-era builds reported /Satoshi:27.1.0/Knots:20240801/, and the suffix is emitted by FormatSubVersion() as far back as v21.2.knots20210629. Detect Knots by matching the Knots: segment, not the base version.

Verification

Like Core, Knots ships signed releases. Verification process is the same:

gpg --verify SHA256SUMS.asc
sha256sum -c SHA256SUMS

Luke Dashjr's GPG fingerprint is the primary signer.

Common bugs / gotchas

• Mempool divergence confusing operators: a tx broadcast to a Knots node may not propagate if other peers are Core (they accept it but Knots peer's first hop drops it). Or vice versa.
• Build options differ; Knots build instructions diverge from Core in some cases.
• Some features lag Core in Knots due to maintainer bandwidth.
• Upgrading a Knots node across the 2026 releases changes which chain it follows. Moving from a build up to v29.3.knots20260210 (or the non-RDTS v29.3.knots20260507) to v29.4.1.knots20260508 moves the node onto the BLAKE2b chain. The v29.4.1 release notes warn that a node that was "old, pruned, and followed invalid blocks" may need a full resync. Audit the exact build string (getnetworkinfo.subversion) before assuming a deployment is still on the Core-compatible chain.

Network share

As of 2026-09-15, Coin Dance reports Knots on 4,399 of 25,864 public nodes (~17.0%) against Bitcoin Core's 21,431 (~82.8%). A Bitnodes snapshot the same day independently counts 4,420 Knots user agents out of 26,478 reachable nodes (~16.7%). Knots is a double-digit minority of public nodes, on both counts.

The figure is volatile — check a live tracker (coin.dance/nodes/share, bitnodes.io) rather than trusting a number written here. Two caveats when reading it:

• Node share is not hashrate and is not a measure of consensus support.
• Since the August 2026 split the crawlers bucket by user agent, so a Knots node on the BLAKE2b chain and a Core node on the SHA256d chain appear in the same total despite validating different chains.

Status

Knots is a maintained, active Bitcoin implementation, not abandonware — v29.4.1.knots20260508 shipped 2026-09-02. Since that release it is best understood as a separate network rather than a niche configuration of the same one. The mainstream chain is still the Core one, by node count (~83%, Sept 2026) and by the fact that the BIP-110 chain managed two blocks in the eight hours after the split while the Core chain advanced 48.

See also

• release-engineering/SKILL.md
• operations/SKILL.md — in particular Relay policy since 30.0, the Core defaults this fork diverges from
• ../../metaprotocols/inscriptions/SKILL.md