Fee Filter (BIP 133)

What Is a Fee Filter?

A fee filter is a peer-to-peer network message defined in BIP 133 that allows a Bitcoin node to communicate the minimum relay fee it requires for transactions. When a node sends a feefilter message to a peer, it is effectively saying: "don't bother announcing transactions to me if their fee rate is below this threshold, because I will reject them anyway."

Before BIP 133, nodes had no way to know in advance whether a peer would accept a given transaction. A node would broadcast inventory (inv) messages for every transaction it accepted into its own mempool, only to have peers reject many of them because their fee was too low. This wasted bandwidth on both sides: the sender transmitted useless announcements, and the receiver spent resources processing and rejecting them.

BIP 133 was authored by Alex Morcos of Chaincode Labs and merged into Bitcoin Core in March 2016. It shipped with Bitcoin Core 0.13.0, the same release that introduced compact block relay (BIP 152) and SegWit support.

How It Works

The feefilter mechanism operates through a simple message exchange between connected peers. The process involves three stages: computing the fee threshold, sending it to peers, and filtering outbound transaction announcements based on received filters.

Message Format

The feefilter message has a minimal structure: a single 8-byte integer representing the minimum fee rate in satoshis per 1,000 virtual bytes (sat/kvB).

// feefilter message payload
// Field: feerate (int64_t, little-endian)
// Unit:  satoshis per 1000 virtual bytes (sat/kvB)

// Example: 48,508 sat/kvB ≈ 48.5 sat/vB
7cbd000000000000

// Example: 1,000 sat/kvB = 1 sat/vB (the traditional default floor)
e803000000000000

A value of 1,000 sat/kvB corresponds to 1 sat/vB, the traditional default minimum relay fee. Nodes only send or process feefilter messages with peers running protocol version 70013 or higher.

Computing the Fee Threshold

A node determines its feefilter value by taking the higher of two fee rates:

1. The static -minrelaytxfee setting, which defines the absolute floor for transaction relay
2. The dynamic mempool minimum fee, which rises above the static floor when the mempool exceeds its size limit and begins evicting low-fee transactions

Under normal conditions with an uncongested mempool, the feefilter value matches the static minimum relay fee. During periods of high congestion, it rises to reflect the actual fee rate needed to enter the mempool.

Privacy Protection

Broadcasting an exact mempool minimum fee could leak information about a node's mempool state, potentially aiding chain analysis or eclipse attacks. Bitcoin Core applies two countermeasures:

• Fee rate rounding: the raw fee rate is quantized into predefined buckets using a geometric progression, preventing peers from inferring the exact mempool state
• Randomized timing: feefilter messages are sent to different peers at independently randomized intervals, so an attacker monitoring multiple connections cannot correlate updates

Filtering Transaction Announcements

When a node receives a feefilter message from a peer, it stores the value and uses it as a gate before sending inv (inventory) messages. The filtering works as follows:

1. A new transaction enters the node's mempool and is queued for relay
2. Before generating an inv message for each peer, the node checks the transaction's fee rate against that peer's stored feefilter value
3. If the transaction's fee rate falls below the peer's feefilter, the inv is skipped entirely for that peer
4. Peers with higher feefilter values (congested mempools) receive fewer announcements, while peers with lower values continue receiving the full set

Interaction with Mempool Congestion

The feefilter mechanism is most valuable during periods of high fee market activity. When demand for block space surges, the following cascade occurs:

1. Users broadcast transactions with a wide range of fee rates
2. Mempools fill beyond the -maxmempool limit (default: 300 MB)
3. Nodes evict the lowest-fee transactions along with their in-mempool descendants
4. The dynamic mempool minimum fee rises to reflect the eviction threshold
5. Nodes broadcast updated feefilter messages to all peers
6. Peers stop announcing transactions below the new threshold

This feedback loop prevents the network from wasting bandwidth on transactions that no peer would accept anyway. Without feefilter, every node would still receive announcements for transactions its mempool would immediately reject, creating a flood of useless traffic precisely when the network is under the most load.

When congestion subsides, the dynamic minimum fee decays gradually (halving over hours) rather than dropping immediately. This prevents the mempool from instantly refilling with low-fee transactions, and the feefilter values decrease accordingly as nodes send updated messages to peers.

Nodes Behind on Blocks

Bitcoin Core applies a special feefilter behavior for nodes that are still catching up with the chain tip. When a node is more than 100 blocks behind, it sets a very high feefilter value (approximately 9,170,997 sat/kvB). This effectively tells peers to stop sending transaction announcements and prioritize block relay instead, since transaction data is irrelevant until the node is fully synced.

Use Cases

Bandwidth Conservation

The primary use case for feefilter is reducing wasted bandwidth. Each unnecessary inv message is 36 bytes (or 68 bytes with wtxid-based relay), and a node connected to dozens of peers can accumulate significant overhead from announcing transactions that will be rejected. During fee spikes, when the gap between the lowest-fee transactions in different nodes' mempools can be large, the savings are substantial.

Compact Block Efficiency

Feefilter indirectly improves compact block relay (BIP 152). Compact blocks work best when the receiving node already has most of a block's transactions in its mempool. By keeping mempools more consistent across the network (nodes share similar fee thresholds), feefilter increases the likelihood that compact block reconstruction succeeds without needing to request missing transactions. This reduces block propagation latency.

Fee Estimation Input

Lightning implementations like LND poll their connected Bitcoin node for peers' BIP 133 feefilter values to avoid broadcasting transactions with inadequate fee rates. By reading feefilter data from outbound peers (which are less likely to be attacker-controlled), wallet software can get a real-time signal about the network's current fee estimation floor.

Why It Matters

Fee filtering is a small but critical optimization for Bitcoin's peer-to-peer network. Without it, every period of high transaction demand would create a negative feedback loop: congestion causes mempool evictions, but peers keep flooding the network with announcements for transactions that will be immediately rejected, consuming bandwidth that could be used for relaying valid transactions and blocks.

The mechanism is particularly relevant as the fee market matures. In recent years, events like Ordinals inscriptions and Runes token minting have created extended periods of elevated mempool congestion. During these events, feefilter prevents the P2P layer from becoming a bottleneck. For Layer 2 protocols like Lightning and Spark, which rely on timely transaction relay for channel operations and on-chain settlements, an efficient relay layer is essential.

Recent Changes

In Bitcoin Core v29.1 (September 2025), the default -minrelaytxfee was lowered from 1,000 sat/kvB (1 sat/vB) to 100 sat/kvB (0.1 sat/vB). This change, authored by Gloria Zhao, reflected the fact that Bitcoin's price had risen several orders of magnitude since the original default was set, making the economic cost of the 1 sat/vB floor disproportionately high. The change directly affects feefilter values: upgraded nodes now advertise a lower base feefilter, allowing more low-fee transactions to be relayed during periods of low congestion. A deeper analysis of fee market dynamics explores how these policy changes ripple through the network.

Risks and Considerations

Not Enforced by Consensus

The feefilter is a relay policy hint, not a consensus rule. A node that receives a feefilter message may choose to honor it, but is not required to. Malicious or misconfigured peers could ignore feefilter values and continue sending low-fee transaction announcements. However, since the feefilter is designed as an optimization rather than a security boundary, this has minimal impact: the receiving node simply rejects the announced transactions as it would have before BIP 133.

Privacy Implications

Despite the rounding and timing mitigations, feefilter messages still reveal approximate information about a node's mempool state. A surveillance node connecting to many peers could potentially map mempool conditions across the network by collecting feefilter data. A 2025 study by Daniela Brozzoni scanned approximately 30,000 full nodes and found that most advertised the traditional default of 1 sat/vB, roughly 4% showed the new 0.1 sat/vB default, and about 8% sent no feefilter at all (suspected spy nodes).

Whitelisted Peer Bypass

Nodes running with -whitelistforcerelay bypass feefilter for whitelisted peers. While this is useful for miners or services that need to see all transactions regardless of fee rate (such as those using prioritisetransaction), it creates an asymmetry where whitelisted connections consume more bandwidth than standard peers.

Interaction with Package Relay

The feefilter evaluates transactions individually, which can cause problems for transaction packages where a low-fee parent is paid for by a high-fee child (CPFP). The parent transaction may be filtered out even though the package as a whole meets the fee threshold. Package relay proposals aim to address this by allowing nodes to evaluate transaction groups together, but until those are fully deployed, feefilter can interfere with fee bumping strategies that rely on CPFP.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.