Bitcoin Knots is a Bitcoin software project with node, wallet, command-line, and graphical functionality. Its repository is derived from Bitcoin Core, and its own README says development generally happens in Bitcoin Core and is merged into Knots for releases. Knots also accepts changes that may not be included upstream and publishes separate tags, binaries, release notes, checksums, and project documentation.
That lineage does not make the two products interchangeable. Shared ancestry can reduce duplicated implementation work, but each release is its own artifact. A claim about compatibility, defaults, migration, or policy needs an exact Bitcoin Knots version, an exact Bitcoin Core version, the relevant configuration, and evidence from source or tests.
This guide was reviewed on July 24, 2026 against Bitcoin Knots v29.3.knots20260508, commit f41f01e1e6de7025d52a865bef97f2a67277f0f3, and Bitcoin Core v31.1, commit 9be056a8a72b624dae9623b2f7bded92c2a21c91. These releases are from different major lines, so the comparison is useful for boundaries, not a one-to-one feature scorecard.
Lineage and shared development
The Knots repository is a fork of bitcoin/bitcoin. Much of its validation, networking, wallet, graphical, build, and testing code originates in Bitcoin Core. Knots release notes identify upstream Bitcoin pull requests alongside Knots-specific changes, making the provenance of individual changes inspectable.
“Fork” here describes source-code lineage. It does not automatically mean a separate coin, network, or consensus history. Whether two running nodes remain on the same chain depends on the validation rules they enforce, the blocks they receive, and any relevant activation or configuration state.
Knots can backport upstream work, retain behavior changed elsewhere, or add features maintained outside Bitcoin Core’s main tree. The result is not simply “Bitcoin Core with more options.” Some changes affect user interfaces, some affect policy, some affect resource management, and some can touch consensus-related code. Each must be classified separately.
Separate releases and maintenance
Bitcoin Knots has its own version scheme and release process. The reviewed release is 29.3.knots20260508, published through the official Knots site with release-specific checksums, signatures, source, binaries, and detailed enhancement documentation.
A Knots version number cannot be compared numerically with a Bitcoin Core version as if both projects shared one synchronized release train. The reviewed tag uses 29.3 plus a Knots release-date suffix, while the Core reference is 31.1. Those labels identify different project release lines; they do not order every included change, because Knots can backport selected upstream work and carry separate changes absent from Core.
The correct question is therefore not “Which has the higher version?” It is “Which exact source trees, release notes, configurations, and tested behaviors are being compared?”
Node, wallet, and graphical interfaces
Like Bitcoin Core, Knots can connect to peers, download and validate blocks and transactions, maintain chainstate and a mempool, expose RPCs, and optionally build wallet and graphical components.
Shared names do not guarantee identical interfaces. An RPC can be added, removed, or extended. A graphical setting can expose a Knots-specific policy. A command-line option can use the same name with a different default. Wallet migration behavior can differ by release.
Applications should feature-detect or pin supported versions rather than assuming that every Bitcoin Core RPC, field, startup option, or wallet behavior is identical in Knots. Human-readable product descriptions are weaker evidence than tagged help output, source, release notes, and cross-implementation tests.
Consensus compatibility and policy differences
Consensus compatibility means two nodes enforce compatible block-validity rules for the chain state being evaluated. Policy compatibility means they make similar local decisions about unconfirmed transactions. These are different.
Many Knots differences concern mempool admission, relay, mining selection, data-carrier handling, fee treatment, or configurable filters. Such differences can change which unconfirmed transactions a node sees or forwards without making confirmed blocks invalid.
However, it is unsafe to state that all Knots releases always enforce exactly the same consensus rules as all Bitcoin Core releases. The reviewed Knots release notes describe RDTS/BIP 110 logic implemented as a modified BIP9 temporary deployment. They instruct bitcoind operators to add consensusrules=rdts, while the GUI asks for explicit confirmation; the same site also lists a closely dated build without RDTS support. Whatever view a reader takes of the proposal, this is direct evidence that version, executable, and configuration must be included in a compatibility claim.
The neutral method is to ask:
- Which exact release and commit is running?
- Which consensus-related configuration is active?
- Which chain and activation state are being evaluated?
- Which blocks or test vectors demonstrate agreement?
- Are observed differences consensus rejection, mempool policy, wallet construction, or interface presentation?
A policy disagreement may fragment transaction relay while nodes still accept the same blocks. A consensus-rule disagreement can create a chain split. The labels “Core” and “Knots” do not answer which case applies.
Release-specific policy and configuration differences
The official enhancement document for 29.3.knots20260508 inventories project-described backports, retained changes, fixes, and enhancements across configuration, policy, wallet, RPC, graphical, networking, build, and other components. It does not identify a complete one-to-one comparison against Bitcoin Core 31.1. The Knots release notes separately describe a RAM-aware dbcache default, sub-dust effective-fee policy, data-carrier policy changes, wallet and GUI additions, and networking changes.
Those facts belong to that release. They should not be rewritten as permanent product identities such as “Knots blocks X” or “Core always allows Y.” Defaults can change. Options can be removed. Upstream can later adopt similar functionality. Knots can rebase or backport changes.
Policy also has multiple stages. Mempool admission, relay to peers, and block-template selection can use related settings but are not necessarily identical. A configuration guide should state which stage an option affects and whether miners or downstream applications use separate logic.
Additional and retained features
Knots may include features proposed for Bitcoin Core, maintained elsewhere, or retained after upstream changes. Examples in a particular release can include extra RPCs, graphical controls, policy settings, wallet tools, or build options.
“Additional” does not mean “safer,” “more correct,” or “better.” It means the tagged Knots release includes behavior its project material identifies as Knots-specific, retained, or backported. Whether an exact Bitcoin Core release lacks the behavior must be checked directly against that Core tag. Every feature adds a review surface, maintenance burden, compatibility question, and possible operator benefit.
Likewise, absence is not proof of a deficiency. Bitcoin Core may decline or defer a feature because of scope, maintenance, interface stability, review capacity, architecture, or a different risk tradeoff. Technical comparison should state behavior and evidence rather than infer motive.
Data directories, wallets, and migration
Both projects descend from the same codebase and may support upgrades from older Bitcoin Core or Knots versions. The reviewed Knots release notes state that direct upgrades from very old versions are possible but may require data-directory migration, and that old wallet versions are generally supported.
That does not establish a universal safe downgrade or bidirectional switch between arbitrary releases. Databases can be migrated, indexes can change, wallet formats can change, and newer software can write state older software cannot interpret. A release note’s upgrade statement does not automatically authorize a rollback.
Before changing implementations, an operator should read both products’ release notes, back up wallet material using documented procedures, stop the old process cleanly, identify index and pruning requirements, and test the exact transition on copied data or regtest. Real funds should not be used for exploratory migration testing.
This guide does not claim that Core 31.1 and Knots 29.3.knots20260508 can safely share one live data directory or be alternated without migration. That requires direct documentation and testing for the exact pair.
Release verification and security updates
Knots publishes binaries and source through its official site, with SHA256SUMS and SHA256SUMS.asc for the reviewed release. A checksum can show that a downloaded file matches the listed digest. A signature can show that a key attested to the checksum file. Neither fact, by itself, proves that the software is free of defects or that the signer should be trusted.
Users need an independently obtained expectation for signer keys and an understanding of the project’s build and release process. A GitHub tag, a site download, a platform code signature, and reproducible-build evidence each answer different questions.
Security maintenance is also project-specific. A vulnerability fixed upstream may need to be incorporated into Knots, and a Knots-specific feature may need its own fix. Operators should follow the project’s official release and announcement channels and identify affected exact versions rather than relying on general Bitcoin news.
Maintenance and change entry
The Knots README says development generally occurs upstream and is merged into Knots for releases. It also provides a path for Knots-specific pull requests and expects accepted external branches to be maintained.
The official site identifies Luke Dashjr as the lead maintainer. That describes a project role, not control over Bitcoin or over independently operated nodes. Maintainers choose what enters their repository and releases; users choose what to run; network effects depend on deployed behavior.
A comparison should inspect both upstream review and Knots-specific review. A change copied from Bitcoin Core may carry upstream discussion and tests. A Knots-only change may have a separate review history. Shared code does not transfer all review evidence automatically when surrounding code, configuration, or release context differs.
How to compare versions responsibly
Use a claim-evidence table.
For each claimed difference, record:
- the exact Knots tag and commit;
- the exact Bitcoin Core tag and commit;
- the source file, help output, test, or release-note entry;
- whether the difference is consensus, policy, wallet, interface, default, build, or documentation;
- the configuration needed to observe it;
- whether cross-version migration or interoperability was actually tested;
- the review date.
For this guide, Core 31.1 and Knots 29.3.knots20260508 were not treated as equivalent-base competitors. The comparison establishes how to read lineage and boundaries. A product-selection decision would need an operator’s requirements plus a more closely matched version pair.
Limits of product-comparison claims
Node software should not be ranked by slogans such as “pure,” “correct,” “safe,” “unsafe,” or “the real Bitcoin.” Those terms hide the rule, feature, threat model, or operating requirement being discussed.
Popularity and node-share estimates do not prove correctness. Social-media sentiment does not prove a policy is harmful or beneficial. A maintainer’s opinion does not replace source and tests. An issue count does not measure security. A larger feature list does not establish reliability.
A useful comparison is narrow and reproducible: exact versions, exact behavior, exact evidence, and remaining uncertainty.