Bitcoin Core minrelaytxfee Explained: Relay Policy Thresholds

This guide explains Bitcoin Core minrelaytxfee in plain English. It focuses on what the subject is, why it matters and what a beginner should remember.

Admission policy versus validity

Relay policy decides what a node accepts into its mempool and forwards. Consensus decides which blocks and transactions all validating nodes must accept. Raising a local threshold can reduce low-fee traffic but cannot redefine Bitcoin validity. Documentation, alerts and support replies should preserve this boundary.

Historical units and parsing

Core 0.12 described fee rates using BTC per kilobyte and parsed a decimal amount. Modern dashboards often use satoshis per virtual byte. Confusing bytes with virtual bytes, or BTC with satoshis, creates orders-of-magnitude errors. Convert explicitly and verify the effective startup value for the exact binary.

Dust and transaction creation

Historical minimum relay fee influenced the dust threshold and wallet transaction creation as well as network forwarding. Changing it could therefore alter which outputs the node considered uneconomic and what its wallet constructed. Later option separation means a modern guide cannot safely be projected backwards.

Mempool and replacement interactions

The baseline relay threshold operates alongside memory-pressure minimums, incremental replacement cost and standardness rules. A transaction above minrelaytxfee may still be rejected because the mempool minimum is higher or because another policy rule fails. Capture the actual rejection reason instead of labelling every refusal low fee.

Mining policy can differ

A miner may select transactions under a block-template minimum different from public relay policy, but it can only select transactions it get. A private submission path may bypass ordinary propagation. Document intentional differences and test that failover template nodes receive equivalent candidates without weakening public safeguards accidentally.

Wallet and payment operations

Fee estimation aims for confirmation targets, not merely the relay floor. Setting a wallet fee just above minrelaytxfee can still lead to long delays. Payment monitoring should model confirmation, replacement and conflicts independently. Never describe relay acceptance as a promise that a miner will confirm the transaction.

How specialists test it

Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.

Conclusion

minrelaytxfee is a local baseline with historically broad policy effects. Tune only with exact-version units and evidence, and never present the setting as a consensus fee or confirmation guarantee.