Compare Bitcoin node implementations
Bitcoin Core, Bitcoin Roots, and Bitcoin Knots share a common code lineage, but they differ in policy, configuration, release process, wallet tools, and, for some releases, consensus behaviour.
This page does not rank the projects. It identifies differences that matter when choosing which software and network rules to run.
Versions reviewed
- Bitcoin Roots: v29.4-roots.2
- Bitcoin Knots feature lineage: v29.3.knots20260507
- Bitcoin Core direct base: v29.4
- Current Knots consensus note: v29.4.1.knots20260508
- Date last verified: 28 September 2026
Bitcoin Roots v29.4-roots.2 starts directly from Bitcoin Core v29.4 and applies a reviewed Roots patch. The patch preserves selected behaviour whose historical lineage includes Bitcoin Knots v29.3.knots20260507; Knots is not an upstream dependency and its full feature set is not imported. The table compares the matched v29.4 Core base and the Knots lineage release for feature presence. It mentions Knots v29.4.1 separately where that later release changes consensus.
Comparison
Scroll horizontally to compare all three projects.
| Feature | Bitcoin Roots | Bitcoin Knots | Bitcoin Core |
|---|---|---|---|
| Project and consensus | |||
| Role and lineage | Bitcoin Core v29.4 plus a reviewable Roots patch carrying selected Knots-lineage behavior | A separate Bitcoin Core-derived implementation with a broader feature set | The upstream reference implementation and the direct Roots base |
| Bitcoin Core-compatible consensus | Yes. Required for every Roots release. | Yes in the reviewed 29.3 lineage; no in v29.4.1.knots20260508 | Yes. Reference behavior. |
| RDTS / BIP-110 enforcement | Excluded | Not enforced by the reviewed 29.3 lineage; enforced by v29.4.1 | Not included |
| Project-specific consensus changes | Excluded | Present in v29.4.1, including BLAKE2b proof-of-work and a temporary 800 kWU limit | Not included |
| Transaction and mining policy | |||
| Embedded-data relay controls (-datacarrier, -datacarriersize) | Included | Included | Included |
| Configurable embedded-data cost (-datacarriercost) | Included from the Knots lineage | Included | Not included in v29.4 |
| Extended replacement policy modes (-mempoolreplacement) | Included from the Knots lineage | Included | Standard Core replacement policy; no equivalent mode selector |
| Coin-age and maturity relay filters (-minrelaycoinblocks, -minrelaymaturity) | Included from the Knots lineage | Included | Not included in v29.4 |
| Sub-dust effective-fee penalty (-subdustfeepenalty) | Included from the Knots lineage | Included | Not included in v29.4 |
| Bare multisig policy toggle (-permitbaremultisig) | Included | Included | Included |
| Mining weight and minimum-fee controls (-blockmaxweight, -blockmintxfee) | Included | Included | Included |
| Coin-age priority mining reserve (-blockprioritysize) | Included from the Knots lineage | Included | Not included in v29.4 |
| Network resources and operator tools | |||
| Compact-block extra-transaction count bound (-blockreconstructionextratxn) | Included | Included | Included |
| Compact-block reconstruction memory bound (-blockreconstructionextratxnsize) | Included from the Knots lineage | Included | Not included in v29.4 |
| Orphan-transaction cap (-maxorphantx) | Included | Included | Included |
| Upload target and peer permissions (-maxuploadtarget, -whitebind, -whitelist) | Included | Included | Included |
| Collected mempool samples (getmempoolstats RPC) | Included from the Knots lineage | Included | Not included in v29.4 |
| Monotonic process-uptime reporting | Included from the Knots lineage | Included | The uptime RPC exists; v29.4 does not use the retained monotonic uptime source |
| RAM detection, memory-pressure response, and advisory I/O priority | Selected safeguards retained from the Knots lineage | Included | No equivalent combined facility in v29.4 |
| GUI peer-health view | Bounded live peer table and details; expanded and hardened in v29.4-roots.2 | Included, with additional Knots monitoring surfaces | Standard peer table and details |
| Wallet and desktop | |||
| Descriptor wallet and basic GUI coin control | Included through the Core base | Included | Included |
| Per-send Replace-By-Fee choice | Included; follows the wallet default and confirms the transaction's effective signaling | Included in the send dialog | Included in the send dialog; checked by default in v29.4 |
| Selected wallet database and signing hardening | Selected Knots-lineage fixes retained without changing wallet formats | Broader Knots wallet maintenance | Core v29.4 wallet behavior |
| Private-key sweeping | Excluded from v29.4-roots.2; future work only | Included as sweepprivkeys RPC and a GUI dialog | Not included in v29.4 |
| Advanced privacy-aware coin control | Not shipped. Planned work spans wallet-side data and transaction contracts plus the Qt workflow. | Basic coin control plus Knots-specific wallet and GUI behavior; not the planned Roots contract | Basic wallet coin selection and GUI coin control |
| QR receive-request image export | Included | Included | Included |
| Windows taskbar synchronization progress | Included when the Windows GUI build enables taskbar progress | Included | Not included in v29.4 |
| Selected build and dependency portability | Qt 5 or Qt 6 selection plus retained QR, external-signer, Tor, and platform integration support | Included in the broader Knots build matrix | Core v29.4 build and optional dependency support |
The table is a feature inventory, not a claim that similarly named controls have identical defaults or implementation details. “Included” means the reviewed version exposes the described capability. For exact defaults and accepted values, use that version's built-in help. It lists every operator-facing Knots-lineage capability maintained in the released Roots feature catalog; internal wallet, build, and platform hardening is grouped rather than presented as dozens of indistinguishable implementation rows.
Wallet scope
All three reviewed code lines include wallet-side coin selection and the Qt coin control dialog. Bitcoin Roots v29.4-roots.2 additionally makes the effective per-send RBF choice explicit and initializes it from the wallet default.
Private-key sweeping is deliberately not included in v29.4-roots.2. The planned Roots privacy-aware coin-control work is also not included. That future work is not GUI-only: the plan requires wallet-owned data and transaction contracts, with Qt presenting the choices and their consequences. Until reviewed code and tests ship in a later release, neither item is a Roots feature.
Sources
The table was checked against these primary sources:
- Bitcoin Roots v29.4-roots.2 release, feature catalog, and source tree
- Bitcoin Core v29.4 release and source tree
- Bitcoin Knots v29.3.knots20260507 release and source tree
- Bitcoin Roots initial lineage commit and its direct parent version metadata
- Bitcoin Knots v29.4.1.knots20260508 release and source tree
- BIP-110 specification
Which project may fit?
Bitcoin Core
The appropriate baseline for operators who want the reference implementation, its standard policy defaults, and the smallest number of project-specific differences.
Bitcoin Roots
Intended for operators who want Bitcoin Core-compatible consensus together with selected conservative policy, privacy, resource, and operational controls inherited from the Bitcoin Knots lineage.
Bitcoin Knots
An alternative implementation with additional policy and configuration choices. Version v29.4.1.knots20260508 is not consensus-compatible with Bitcoin Core v29.4. Operators should examine the consensus rules of the specific release before upgrading or deploying it.
Frequently asked questions
Is Bitcoin Roots a new cryptocurrency?
No. Bitcoin Roots is full-node software intended to follow the Bitcoin network and Bitcoin Core-compatible consensus. It does not introduce a new token.
Is Bitcoin Roots a network fork?
Bitcoin Roots is a source-code fork built directly on Bitcoin Core, with selected behavior retained from the Bitcoin Knots lineage. Its stated purpose is not to create a competing Bitcoin chain.
Does stricter policy change Bitcoin consensus?
No. Mempool and transaction relay policy govern unconfirmed transactions handled by the local node. They do not determine whether a block is valid.
Can a transaction rejected by Bitcoin Roots appear in a valid block?
Yes. A miner may include a consensus-valid transaction that Bitcoin Roots did not accept into its local mempool. Bitcoin Roots must accept the block if the block satisfies Bitcoin consensus rules.
Why preserve features from Bitcoin Knots?
Bitcoin Knots developed useful controls for transaction relay policy, resource use, privacy, and node operation. Bitcoin Roots preserves selected features where they remain compatible with its consensus commitment.
Why does Bitcoin Roots reject RDTS/BIP-110?
Bitcoin Roots does not consider subjective transaction policy a sufficient basis for changing Bitcoin consensus rules. It keeps conservative filtering at the node-policy layer while following Bitcoin Core-compatible block validity.
Does Bitcoin Roots guarantee “no spam”?
No. “Spam” is not an objective consensus category. Bitcoin Roots can apply conservative local relay and mempool policy, but it must still accept consensus-valid blocks.