Bitcoin Knots

Long-running Bitcoin Core derivative that ships with stricter mempool and policy controls than vanilla Core — maintained by Luke Dashjr (one of the longest-tenured Bitcoin contributors, formerly Bitcoin Core developer) under the Knots brand since 2011. Listed at Grade A because Knots is the canonical "I want a full Bitcoin node with opinionated mempool policy" answer for sovereignty-minded users: same chain as Core (no fork, no altcoin), same RPC interface (every Core-compatible tool works unchanged), but with additional configuration knobs around OP_RETURN limits, mempool filtering, transaction-size constraints, and fee policies that the Core maintainers have declined to upstream. Open-source MIT, no telemetry, no account, no operator on the data path.

What it is. Bitcoin Knots is a software fork of Bitcoin Core that periodically merges Core's mainline and adds a layered patchset of policy changes Luke Dashjr (and the small Knots maintainer team) has accumulated over a decade. The version string mirrors Core's: Knots `26.1.knots20240801` is the Aug 2024 patchset on top of Core `26.1`. Every Core feature lands eventually; some Knots features (BIP119 / OP_CHECKTEMPLATEVERIFY support, datacarrier policy bias, libconsensus exports) reach Knots first or stay Knots-only when Core declines.

Knots runs the same `bitcoind` daemon, the same `bitcoin-cli`, the same `bitcoin-qt` GUI as Core — drop a `bitcoind` install replaced with the Knots binary into any existing node setup and your wallets, RPC consumers, mempool watchers, and miners keep working unchanged. The chain it validates is unambiguously Bitcoin mainnet (or testnet/signet/regtest as you configure); Knots does not fork the consensus rules.

Background. Luke Dashjr has been contributing to Bitcoin since 2011 — Bitcoin Improvement Proposals (BIPs) authored, miner-software releases shipped (Eligius pool, BFGMiner), and a long Bitcoin Core commit history through 2023. Knots as a distribution began as Luke's personal patchset over Core: a place to ship policy changes that Core's maintainers would not merge but that node operators with stricter views on miner-mempool incentives wanted to run.

The 2024 OP_RETURN debate (Core's decision to raise the standard OP_RETURN size limit) crystallised Knots' positioning as the "smaller-block, stricter-policy" reference distribution. Node operators who disagreed with Core's relaxation moved to Knots; Knots' nodecount visible on `bitnodes.io` measurably grew through 2024-2025 as a result. Knots remains a Luke-maintained project with small contributor count (~10-15 active per release) and no commercial entity behind it; releases ship from Luke's personal infrastructure.

What you trust.

• Open-source MIT. Codebase at `github.com/bitcoinknots/bitcoin`. Built from Core's source, with the Knots patchset visible as discrete commits — you can diff Knots against the Core version it's based on and see every Knots-specific change.
• Reproducible builds. Knots inherits Core's Guix-based reproducible-build workflow. Multiple builders sign each release's manifest; you can verify the binary by rebuilding from tagged source on your own hardware.
• Same chain as Core. No consensus fork; Knots syncs Bitcoin mainnet (or any net you point it at) and produces blocks indistinguishable from Core's. Mining policy can differ (which transactions a Knots miner picks for a block) but block validity is identical.
• No telemetry, no phone-home. The daemon doesn't call back to bitcoinknots.org or anywhere else — it speaks Bitcoin's wire protocol to peers and nothing else.
• No account at any stage. Download binary, verify signatures, run. No "Knots account" exists.
• Wallet keys local. Stored on disk in your `~/.bitcoin/wallets/` (Core-compatible). Optional encryption via `bitcoind walletpassphrase`.

Operational specs.

• Install — download binary tarballs from `bitcoinknots.org/files/26.x/...` (Linux, macOS, Windows, ARM, BSD); verify signatures with `gpg --verify SHA256SUMS.asc` against Luke's published key. Or build from source: `git clone github.com/bitcoinknots/bitcoin && ./autogen.sh && ./configure && make`.
• Hardware — full node: ~700 GB SSD (Bitcoin mainnet blocks + UTXO + chainstate, growing ~80 GB/yr), 4-8 GB RAM, modern dual-core CPU. Pruned mode (`-prune=10000`) drops disk to ~10 GB at the cost of losing historical block data. Initial block download ~24-48 hours on a fast residential link.
• Configuration — `bitcoin.conf` in `~/.bitcoin/` (or `~/Library/Application Support/Bitcoin/` on macOS). All Core options work; Knots-specific options are documented in the release notes per version.
• RPC — `bitcoin-cli` works identically to Core. Any tool that talks Core RPC (mempool.space watchtower, Sparrow Wallet, Electrum personal-server, BTCPay Server, Joinmarket, Wasabi, btcpayserver, your own scripts) works against Knots unchanged.
• GUI — `bitcoin-qt` ships in the same binary distribution; same wallet UI as Core.
• Network — IPv4 + IPv6 + Tor (`bind=127.0.0.1:8333 -listenonion -proxy=127.0.0.1:9050`) + I2P. Tor-only mode is one config flag away.
• Updates — manual. New Knots releases ship periodically (roughly tracking Core's release cadence); you stop the daemon, replace the binary, restart. State migrates automatically.
• Support — IRC (`#bitcoin-knots` on Libera.Chat), GitHub Issues. No commercial support contract — this is a Luke-maintained project, not a company.

Operator philosophy. Luke Dashjr's position is consistent across a decade of public Bitcoin-Talk / Twitter / IRC / mailing-list posts: Bitcoin's value proposition depends on small blocks, restrictive mempool policy, and aggressive resistance to onchain bloat (NFTs, inscriptions, ordinals, arbitrary data carriage). Knots' policy patches operationalise this view — they give individual node operators the choice to reject transactions the user considers spam, regardless of whether they meet Core's looser standards.

The view is contested within the broader Bitcoin community; Core's maintainers have declined to merge most Knots-specific policy changes precisely because they disagree about which transactions count as "spam" (and whether nodes should filter at all). Listing Knots at Grade A is not an endorsement of the policy stance — it's an editorial recognition that the node software itself is technically sound, open-source, reproducibly-built, fully Core-compatible, and ships features a real constituency of node operators wants. Users who disagree with Luke's policy views should run Core; users who agree should run Knots.

Grade rationale. Grade A reflects: identical privacy posture to Core (full local validation, no operator on the data path, no account anywhere), open-source MIT (auditable, the patchset is reviewable as discrete commits over Core), reproducible builds via Guix (binary verifiable against tagged source), same chain as Core (no consensus fork; runs Bitcoin mainnet), plug-in RPC compatibility (works with every Core-compatible tool), named-operator accountability without dependency (Luke Dashjr publicly identified for ~14 years; even if Knots stopped updating, the daemon continues to validate Bitcoin until the next consensus change), measurable adoption (visible Knots nodecount on bitnodes.io grew through 2024-2025), and no security incident attributable to Knots-specific code in the project's history. Last verified 2026-05-27.

Useful when:

• You want to run a Bitcoin full node and prefer Luke Dashjr's stricter mempool policy defaults over Core's.
• You want to filter inscriptions / ordinals / large OP_RETURN data out of the mempool your node relays, without writing custom patches.
• You're running a small private miner and want policy controls (which transactions to mine, fee floor, datacarrier rejection) Core doesn't expose.
• You need a Bitcoin node binary that's directly Core-compatible from the RPC side but ships features Core has declined to upstream (BIP119, libconsensus exports, configurable policy biases).
• You're philosophically aligned with the "small-blocks, less-onchain-bloat" view and want to operationally express it via the software you run.
• You want a Core-derived node that's maintained outside the Chaincode Labs / Spiral-funded Core orbit by an independent contributor.

Caveats:

• Smaller maintainer pool than Core. Knots has ~10-15 active contributors per release vs Core's ~100+. Bug-fix latency on Knots-specific code is longer; security-critical Core fixes generally reach Knots within days but not always within hours.
• Single-maintainer dependency. Luke Dashjr personally owns the release process and signs the binaries. If Luke stops releasing (illness, dispute, life event), Knots continues to validate the chain (consensus is Core's) but the policy patches stop receiving updates. The project would either fork to a new maintainer or quietly become obsolete.
• Editorial controversy. Luke's Bitcoin policy positions have generated multiple long-running disagreements with Core maintainers, mining pools, and large segments of the Bitcoin community (most prominently the inscription / ordinals debate). Running Knots is a public-facing political signal in some communities; this may or may not matter to you.
• GUI is a minimal Core-style interface. `bitcoin-qt` ships the same basic interface Core does. For a polished wallet UI, pair Knots-as-backend with Sparrow / Electrum / Wasabi / BlueWallet over RPC.
• Initial sync is full-node-grade. 24-48 hours of bandwidth + CPU on first install; ~700 GB SSD for the full archival node. Pruned mode (~10 GB) drops the historical data but you lose block-explorer functionality.
• Tor / I2P configuration is manual. Knots inherits Core's Tor support but you wire up the SOCKS proxy and hidden-service onion in `bitcoin.conf` yourself. No automatic Tor-setup flag.
• No commercial support contract. Bugs reported via GitHub Issues + IRC; production-critical deployments should either run multiple-node redundancy or pay a Core/Knots-fluent consultant separately.