Policy vs. Consensus: Why Core and Knots Are Both Right (and Both Wrong)

A Bitcoin Echo Position Paper

Published: December 15, 2025

The Current Debate

In 2025, the Bitcoin implementation landscape faces a significant philosophical divide:

Bitcoin Core v30 removed the 80-byte OP_RETURN limit, aligning node mempool policy with observed miner behavior and reducing UTXO set bloat by encouraging data storage in OP_RETURN outputs rather than unspendable UTXOs.

Bitcoin Knots filters what it considers "spam" transactions—including Ordinals inscriptions, arbitrary data embeddings, and certain token protocols—to preserve Bitcoin's focus as a monetary network.

Both implementations claim to be preserving Bitcoin. Both are making policy choices. Neither is being entirely honest about what they're doing.

The Confusion

What Bitcoin Core v30 Claims

"We're just removing an arbitrary policy limit that doesn't match consensus rules. Miners decide what goes in blocks anyway, so node policy that differs from miner behavior just creates confusion and resource waste."

What Bitcoin Core v30 Actually Does

Sets a permissive default policy that treats all consensus-valid transactions as equally legitimate and worthy of relay. This is a value judgment: it assumes Bitcoin has no "purpose" beyond what consensus rules permit, and that financial transactions have no special status.

What Bitcoin Knots Claims

"We're filtering spam and abuse to protect Bitcoin's purpose as sound money. These data-embedding schemes exploit vulnerabilities and were never part of Bitcoin's design."

What Bitcoin Knots Actually Does

Sets a restrictive default policy that filters transactions based on a philosophical judgment about Bitcoin's "true purpose." This is also a value judgment: it assumes Bitcoin's legitimate use cases can be distinguished from illegitimate ones at the policy layer.

The Truth

Both are right that their policy serves their values and understanding of Bitcoin.

Both are wrong to claim neutrality while making value-laden choices about what Bitcoin "should" be used for.

The Architectural Mistake

The Core/Knots debate confuses two distinct layers:

Consensus Layer

What it does: Defines which blocks and transactions are valid according to protocol rules. Determines which chain has the most accumulated proof-of-work. Settles disputes about transaction history.

Who decides: The protocol itself, as implemented identically by all consensus-compatible nodes. Changes require broad ecosystem coordination (soft forks or hard forks).

Current state: Remarkably stable since 2009. Soft forks like SegWit and Taproot have tightened rules without invalidating old blocks.

Policy Layer

What it does: Determines which valid transactions a node will relay and temporarily store in its mempool. Affects network resource usage, DoS resistance, and user experience, but not consensus.

Who decides: Each node operator, based on their values, resources, and use case.

Current state: Falsely presented as having a "correct default" by both major implementations.

Why This Matters

When policy and consensus are confused, the debate becomes tribal rather than technical:

• "Core v30 will kill Bitcoin!" (Wrong—it's a policy change, not a consensus change)
• "Knots is censoring transactions!" (Wrong—filtering mempool != preventing inclusion in blocks)
• "There's one true Bitcoin implementation!" (Wrong—diversity at the policy layer is healthy; uniformity at the consensus layer is essential)

The confusion creates a false choice: pick a side in the implementation wars, or run software whose policy choices you don't actually agree with.

Bitcoin Echo's Approach

Bitcoin Echo separates consensus from policy architecturally, not rhetorically.

The Consensus Engine (Frozen)

The core of Bitcoin Echo implements block and transaction validation according to the protocol rules as of 2025, including all deployed soft forks. This component:

• Is pure computation (no I/O, no system calls)
• Can be tested exhaustively in isolation
• Will be frozen upon completion and audit
• Is identical for all Bitcoin Echo operators

Result: All Bitcoin Echo nodes agree on the valid chain, regardless of policy configuration.

The Policy Layer (Configurable at Compile Time)

The protocol layer implements mempool policy, peer management, and relay decisions. Core and Knots handle these through runtime flags. Bitcoin Echo makes them compile-time choices.

Core/Knots use runtime flags like:

• -datacarriersize=100000 (Core v30, effectively unlimited OP_RETURN)
• -datacarriersize=83 (Core pre-v30, 80 bytes of OP_RETURN data)
• -rejecttokens=1 (Knots, filter inscriptions/ordinals/Runes)
• -permitbaremultisig=0 (disable bare multisig relay)

Bitcoin Echo uses compile-time constants:

• POLICY_MAX_DATACARRIER_BYTES — How much OP_RETURN data to relay (0 to 100000 bytes)
• POLICY_FILTER_WITNESS_DATA — Whether to filter inscription patterns (0 or 1)
• POLICY_PERMIT_BARE_MULTISIG — Whether to relay bare multisig (0 or 1)
• POLICY_MIN_RELAY_FEE_RATE — Minimum fee rate in satoshis per 1000 bytes
• POLICY_DUST_THRESHOLD — Minimum output value to relay
• And several others for transaction size, sigops, mempool limits, RBF policy

No presets. No bundles.

Every operator sets every value based on their operational needs and philosophical beliefs. The configuration file is heavily commented with historical context and tradeoff explanations to help operators make informed choices.

Why Compile-Time Configuration?

Bitcoin Echo has no pre-built binaries. Every operator compiles their own node from source, configuring policy constants before compilation. This isn't a barrier—it's a feature.

Because policy is a value judgment, and we refuse to pretend otherwise.

There is no "neutral default" for mempool policy. Accepting everything is a choice. Filtering data-carrying transactions is a choice. Both reflect beliefs about what Bitcoin should be used for.

By forcing policy configuration at compile time, Bitcoin Echo makes the philosophical choice explicit and auditable. You're not running "Bitcoin Echo with the default settings"—you're running "Bitcoin Echo compiled for strict financial policy" or "Bitcoin Echo compiled for permissive consensus-only policy."

This is honest.

Precedent: The 2010 Bitcoin Development Philosophy

This separation isn't new. Early Bitcoin developers understood it clearly.

In discussions about transaction fees, relay policy, and micropayments circa 2010, Satoshi and developers like Gavin Andresen recognized that nodes could have different fee policies without fragmenting the network, because consensus remained intact.

The protocol defined what was valid. Policy defined what was relayed. These were understood as separate concerns.

Somewhere along the way, this distinction was lost. Implementations began claiming that their policy choices were "the right way" or "more faithful to Satoshi's vision," when in fact they were simply embedding their values into default configurations.

Bitcoin Echo returns to the original design philosophy: tight consensus, diverse policy.

What This Means for the Current Debate

For Bitcoin Core Supporters

You're right that mempool policy differing from miner behavior creates inefficiency. You're right that arbitrary restrictions on OP_RETURN size are just policy, not consensus.

But you're wrong to claim your permissive policy is "neutral." Treating all consensus-valid transactions as equally worthy of relay is a philosophical position—one that prioritizes protocol permissiveness over use-case filtering.

Bitcoin Echo lets you run that policy explicitly, without pretending it's the only legitimate choice.

For Bitcoin Knots Supporters

You're right that Bitcoin was designed primarily as electronic cash, and that data-embedding schemes may create long-term costs for node operators. You're right to want policy that reflects Bitcoin's monetary purpose.

But you're wrong to claim that filtering mempool transactions "preserves Bitcoin" in a consensus sense. Miners can include filtered transactions in blocks, and your node will still validate those blocks. Your policy is a preference, not a protection.

Bitcoin Echo lets you run that policy explicitly, without pretending it prevents data from entering the blockchain.

For Everyone Else

You don't have to pick a tribe. You can run the same consensus engine as everyone else while setting policy values that match your specific needs.

Open include/echo_policy.h. Read the comments. Uncomment each constant. Set each value based on:

• Your bandwidth and storage constraints
• Your beliefs about Bitcoin's purpose
• Your risk tolerance for spam, legal exposure, or resource exhaustion

No presets. No bundles. No "what we think you want."

Every operator makes explicit choices. Every node's policy is visible in its source code.

All configurations produce nodes that agree on the valid chain. The debate becomes what it should be: a technical discussion about operational tradeoffs, not a religious war about Bitcoin's soul.

The Path Forward

The health of Bitcoin doesn't depend on everyone running the same implementation with the same defaults. It depends on everyone running consensus-compatible implementations while having the freedom to set policy according to their needs.

Bitcoin Echo demonstrates this architecturally:

1. Consensus engine — Frozen, auditable, identical for all operators
2. Policy layer — Configurable, explicit, operator-controlled
3. Platform layer — Thin, replaceable, OS-specific

This isn't compromise. This isn't "trying to please everyone." This is correct software architecture applied to the consensus/policy distinction that has always existed in Bitcoin.

Show, Don't Tell: Our Implementation

Bitcoin Echo's configuration structure demonstrates architectural separation in code, not rhetoric.

Consensus Layer (Frozen, Never Changes)

echo_consensus.h — The consensus rules that all nodes must agree on:

/* Block subsidy halving interval (blocks) */
#define CONSENSUS_HALVING_INTERVAL 210000

/* Maximum block weight (weight units, post-SegWit) */
#define CONSENSUS_MAX_BLOCK_WEIGHT 4000000

/* Maximum script size (bytes) */
#define CONSENSUS_MAX_SCRIPT_SIZE 10000

/* Coinbase maturity (blocks before spendable) */
#define CONSENSUS_COINBASE_MATURITY 100

These values define what makes a block valid. They are FROZEN and identical for all Bitcoin Echo nodes.

Policy Layer (No Defaults, Operator Must Choose)

echo_policy.h — The relay and mempool rules each operator chooses:

Bitcoin Echo has NO policy defaults. All policy constants are commented out.

Operators must explicitly uncomment and configure policy before compilation:

/*
 * Data carrier (OP_RETURN) policy - POLICY_MAX_DATACARRIER_BYTES
 *
 * Your choice reflects belief about Bitcoin's purpose:
 * - 0: No data embedding allowed in relay
 * - 40-83: Minimal data for timestamping/commitments
 * - 100000: All consensus-valid data is legitimate
 *
 * UNCOMMENT ONE:
 */
// #define POLICY_MAX_DATACARRIER_BYTES 0       /* No data relay */
// #define POLICY_MAX_DATACARRIER_BYTES 80      /* Conservative */
// #define POLICY_MAX_DATACARRIER_BYTES 100000  /* Permissive */

/*
 * Witness data filtering - POLICY_FILTER_WITNESS_DATA
 *
 * UNCOMMENT ONE:
 */
// #define POLICY_FILTER_WITNESS_DATA 0  /* Accept all witness data */
// #define POLICY_FILTER_WITNESS_DATA 1  /* Filter inscriptions */

/*
 * Bare multisig relay - POLICY_PERMIT_BARE_MULTISIG
 *
 * UNCOMMENT ONE:
 */
// #define POLICY_PERMIT_BARE_MULTISIG 0  /* Reject bare multisig */
// #define POLICY_PERMIT_BARE_MULTISIG 1  /* Accept bare multisig */

If you leave all policy constants commented out:

• Policy enforcement code checks #ifdef POLICY_CONSTANT_NAME
• If undefined: the check doesn't exist, transaction is accepted if consensus-valid
• If defined: the policy restriction is enforced

This means: no policy = no restrictions beyond consensus rules.

Consensus defines what's valid. Policy optionally restricts what's relayed. If you don't define policy, you relay anything consensus allows.

To be clear: consensus-only as our baseline is a choice—we believe it's the honest one, because policy should restrict consensus, not define a parallel rule system. But we won't pretend this isn't a philosophical position. It is. The difference is we're explicit about it.

Nodes with different policies still agree on valid blocks. Policy affects relay, not consensus.

Platform Layer (Pragmatic, May Evolve)

echo_platform_config.h — Operational settings:

/* Maximum outbound connections */
#define PLATFORM_MAX_OUTBOUND_PEERS 8

/* Connection timeout (milliseconds) */
#define PLATFORM_CONNECT_TIMEOUT_MS 5000

/* Maximum log file size before rotation */
#define PLATFORM_LOG_MAX_SIZE_BYTES 10485760

These values affect performance and resource usage, not consensus or policy philosophy.

Why This Matters

Bitcoin Core and other implementations mix these concerns. Their configuration uses runtime flags like -datacarriersize=100000 that appear neutral but encode philosophical choices.

Bitcoin Echo makes the choice explicit and visible in the source code. An operator compiling Bitcoin Echo must uncomment and set POLICY_MAX_DATACARRIER_BYTES to their preferred value. All policy constants are commented out.

There are NO defaults.

The implementation uses #ifdef checks: if a policy constant is undefined, that restriction doesn't exist. The transaction is accepted if it's consensus-valid.

This is simple:

• Consensus defines what's valid
• Policy optionally restricts what's relayed
• No policy defined = no restriction = relay anything consensus allows

This is architectural honesty. Policy is an optional filter on top of consensus, not a required parallel configuration. The code structure itself enforces the separation we're advocating.

Conclusion

The Bitcoin Core v30 / Knots controversy is not about consensus. It's about values.

Should Bitcoin prioritize being useful for any purpose consensus permits? Or should it prioritize being useful specifically as money?

These are legitimate questions. They deserve honest debate. But they can't be resolved by pretending one policy choice is "more Bitcoin" than another.

Bitcoin Echo offers a different path: acknowledge that policy requires choice, make that choice explicit and auditable, and preserve consensus uniformity while enabling policy diversity.

If you believe in Bitcoin's decentralization, you should want multiple implementations with different policy philosophies—as long as they all implement consensus identically.

That's what we're building.

Bitcoin Echo

One consensus engine. Many policy choices. Frozen upon completion.

bitcoinecho.org

Further Reading

• Bitcoin Echo Manifesto — Why we freeze
• Bitcoin Echo Whitepaper — Technical specification
• Section 3.3.1: Policy Configuration — Detailed policy options

If you're a Bitcoin developer, node operator, or researcher interested in the consensus/policy separation, we want to hear from you. This is an architectural question with a technical answer—let's treat it as such.