Bitcoin Node Relay Policy: Core vs Knots & Your Block Template
Your Bitcoin node’s relay and mempool policy is the concrete, configurable layer of “template sovereignty.” When you build your own block templates — through Stratum V2 job declaration or DATUM — your node’s policy decides which transactions are even eligible for your block. This matrix compares the Bitcoin node implementations by the exact default policy knobs that shape a self-built template: the datacarrier (OP_RETURN) default and size, multiple OP_RETURN outputs, bare multisig, the dust relay threshold, full-RBF, and whether inscriptions/ordinals are filtered.
This is the most-discussed live governance question in Bitcoin: Bitcoin Core relaxed its long-standing OP_RETURN size limit, while Bitcoin Knots keeps strict filtering — and node operators are voting with the software they run. Which node you run, and how you configure it, is a direct expression of what you want your own blocks to contain.
Read it honestly. These are policy (standardness) defaults, not consensus rules. Every setting is configurable, and a transaction that one node’s policy rejects is still perfectly valid and can be mined by anyone who accepts it. The values are a point-in-time snapshot; verify at each project’s release notes before relying on them.
Quick answer
When you run your own node and build your own block templates (via Stratum V2 job declaration or DATUM), your node's relay/mempool POLICY decides which transactions are even eligible for your block — this is the concrete, configurable layer of "template sovereignty." This matrix compares 6 Bitcoin node implementations by the exact default policy knobs that shape a self-built template: the datacarrier (OP_RETURN) default and size, whether multiple OP_RETURN outputs are standard, bare multisig, the dust relay threshold, full-RBF, and whether inscriptions/ordinals are filtered.
These are POLICY (standardness) defaults, not consensus rules — every one is configurable, and a block that violates another node's policy is still perfectly valid. The live 2025-2026 split is Bitcoin Core (which relaxed its OP_RETURN limit) vs Bitcoin Knots (which keeps strict filtering); which you run is a direct expression of what you want your own blocks to contain. Values are a point-in-time snapshot — verify at each project's release notes before relying on them.
Download CSV Download JSON REST API →
| Node | OP_RETURN (datacarrier) | Multi OP_RETURN | Bare multisig | Dust threshold | Full‑RBF | Inscription filter |
|---|---|---|---|---|---|---|
| Bitcoin Core v30.x Includes large and multiple OP_RETURN data (up to ~100 kB aggregate), bare multisig, TRUC/v3 packages and Taproot inscription/ordinal witness txs; excludes only true sub-dust and genuinely non-standard scripts. | Enabled (relayed) 100,000 B (v30; ~unlimited) | Standard (multiple) | Relayed | 3000 sat/kvB (~546 P2PKH) | On by default (v28+) | No — relays |
| Bitcoin Knots v29.3.knots (v29-based) Excludes inscriptions/ordinals, oversized or multiple OP_RETURN data (>83 B total), bare multisig and dust — a minimal-data-spam template of financial-looking transactions. | Enabled but capped 83 B (temporary; intent to revert to 42) | Non-standard (shared 83 B budget) | Not relayed | 3000 sat/kvB + sub-dust fee penalty | On (always) | Yes — filters |
| btcd v0.24.x (Go) Legacy-Core-style, by hardcoded standardness rather than a policy toggle: includes one <=80 B OP_RETURN and bare multisig; excludes large/multiple OP_RETURN and TRUC — more restrictive than Core v30. | Enabled (hardcoded) 80 B (fixed, no runtime knob) | Non-standard (1 max) | Relayed (<=3 keys) | 1000 sat/kvB min-relay (~546 P2PKH) | BIP125 opt-in only (no full-RBF) | No — relays |
| bcoin v2.2.x (JS; low maint.) Legacy-Core-style templates (one <=80 B OP_RETURN, bare multisig; no oversized data or TRUC). Low ongoing maintenance. | Enabled 80 B data / 83 B script (fixed) | Non-standard (1 max) | Relayed | 1000 sat/kB (~546 P2PKH) | Opt-in RBF, off by default | No — relays |
| Libbitcoin libbitcoin v4 (toolkit) A full-validation C++ library/node toolkit, not a Core-style relay-policy node: it validates and stores/relays blocks and fee-qualifying txs but exposes no OP_RETURN / dust / bare-multisig / RBF policy knobs, so it offers no configurable template policy. | N/A | N/A | N/A | N/A | N/A | N/A |
| Floresta v0.9.x (Rust / utreexo) A utreexo compact-accumulator validation client with an integrated Electrum server; as of v0.9.x it has no transaction relay or policy mempool, so it does not build or relay policy templates at all. | N/A | N/A | N/A | N/A | N/A | N/A |
Snapshot: July 2026. Policy (standardness) defaults only — all configurable; a policy-nonstandard transaction is still consensus-valid. Full fields (version, TRUC/v3, mempool size, sources) in the CSV/JSON. See also the node implementations comparison, the pool-level template sovereignty tracker, the node appliance comparison, and the Stratum V2 guide.
This is the node-level companion to the pool-level template sovereignty tracker (which pools let miners build their own blocks) and the node appliance comparison (which box to run one on). To actually mine toward your own templates, see the Stratum V2 guide.
Related products, repair, and setup paths
- how D-Central diagnoses ASIC repairs
- ASIC troubleshooting library
- ASIC manuals and repair guides
- replacement hashboards
- ASIC control boards
- ASIC power supplies
- S19 family replacement hashboard
- C52 replacement control board
- APW12 S19 power supply
- immersion cooling hub
- home immersion cooling guide
- ASIC miners for immersion planning
- ASIC cooling parts
- airflow shroud before immersion
- compare miner specs in the database
- ASIC repair support
Last reviewed July 17, 2026.