Bitcoin transaction fees and mempool data: a verification guide

Chapter 01

The mempool is a local node cache, not a central queue

A frequent point of confusion among cryptocurrency users is the idea that the Bitcoin network has a single, centralized mempool where pending transactions wait in line. In reality, each validating node running on the network maintains its own independent in-memory pool (mempool) of unconfirmed transactions that meet its local validation and relay criteria.

Because peer-to-peer network propagation takes time and individual node operators can configure different limits—such as the -maxmempool parameter (defaulting to 300 megabytes in Bitcoin Core)—two nodes may hold slightly different sets of transactions. When a node's mempool reaches its memory limit, it does not crash; it dynamically increases its minimum fee filter (minrelaytxfee) and evicts the transactions with the lowest fee density. A transaction that has disappeared from one public block explorer may still reside in the mempool of a mining pool or another node.

Chapter 02

Measure fee density in satoshis per virtual byte, not flat dollars

Transaction fees in Bitcoin are not priced as a percentage of the transferred value, nor are they priced as a flat dollar charge. Miners prioritize transactions to maximize the total fee collected within the protocol's block weight limit (4,000,000 weight units, or roughly 1 megabyte to 4 megabytes depending on witness data). Consequently, miners evaluate fee density: satoshis per virtual byte (sat/vB).

A transaction that transfers $10,000,000 from a single Native SegWit input to two outputs consumes roughly 140 virtual bytes. A transaction that consolidates twenty unspent transaction outputs (UTXOs) from legacy addresses to spend $50 may consume over 2,500 virtual bytes. Even if both pay the exact same fee in dollars, the consolidation transaction offers a far lower fee rate (sat/vB) and will wait much longer during periods of block space competition. Understanding transaction weight prevents users from overpaying or underpaying when structuring payments.

Chapter 03

Accelerating a pending transaction: RBF versus CPFP

When block space demand surges, a low-fee transaction can remain pending in node mempools for hours or days. Rather than abandoning the transaction, protocol standards provide two deterministic mechanisms to accelerate confirmation:

1. Replace-By-Fee (RBF, BIP 125): If the original transaction was broadcast with opt-in RBF signaling (sequence numbers below 0xffffffff - 1), the sender can broadcast a replacement transaction spending at least one of the same inputs. The replacement transaction must pay a higher absolute fee and a higher fee rate than the original, compensating miners for relay bandwidth. 2. Child-Pays-For-Parent (CPFP): If RBF was not signaled or the sender cannot modify the inputs, the receiver can create a new transaction spending an unconfirmed output from the stuck parent transaction. By attaching a sufficiently high fee to the child transaction, miners are incentivized to mine both the parent and the child together in the same block to claim the combined fee package.

Chapter 04

Distinguishing block space competition from network degradation

Headlines regularly describe a crowded mempool as congestion or network breakdown. In network engineering terms, a full mempool indicates that demand for immutable block space exceeds the 10-minute supply. The Bitcoin protocol continues to process blocks at its target rate regardless of whether there are 1,000 or 200,000 transactions in mempools.

High fee environments occur during periods of market volatility, exchange rebalancing, or heavy usage of data-embedding protocols such as Inscriptions. Rather than signaling protocol vulnerability, a robust fee market is an intentional component of Bitcoin’s long-term security budget as block subsidy halvings continue. What matters for participants is matching their operational urgency with appropriate fee estimation algorithms instead of blindly accepting wallet defaults.

Chapter 05

Operational checklist before broadcasting an onchain payment

Before submitting a transaction to the network, follow these practical steps:

• Inspect current mempool block clearing bands: identify the fee rate currently clearing the next block versus the next six blocks.
• Enable BIP 125 opt-in RBF in your wallet software before signing; this retains the option to bump the fee if urgency changes.
• Avoid consolidating small UTXOs during peak fee spikes; schedule consolidation during weekend or low-demand periods.
• Distinguish between transaction broadcast (propagation across peers) and inclusion (mined into a block).
• Check node release hygiene by reviewing our Bitcoin Core 31 node operator guide and our parent Bitcoin research desk.

Chapter 06

Fee estimation algorithms and Replace-by-Fee (RBF) mechanics

Modern Bitcoin transaction fee management relies on dynamic feerate estimation based on localized mempool depth rather than static per-transaction satoshi fees. Bitcoin transactions consume block capacity measured in virtual bytes (vB), where one virtual byte corresponds to four weight units under Segregated Witness (BIP-141) accounting rules.

Feerate is calculated as: Feerate (sat/vB) = Total Fee (Satoshis) / Virtual Size (vB)

When an urgent transaction becomes stuck in the mempool due to sudden demand spikes, senders can utilize opt-in Replace-by-Fee (BIP-125) to accelerate confirmation. Under BIP-125 rules, a replacement transaction must signal replaceability by having at least one input with a sequence number strictly below "0xfffffffe". Furthermore, the replacement must pay an absolute fee greater than the sum of all transactions it directly replaces, while also paying a feerate that exceeds each replaced transaction and covers the bandwidth cost of broadcasting the new transaction across the network.

Chapter 07

Step-by-step transaction feerate verification query

To independently verify whether a broadcasted transaction is priced appropriately for target block inclusion, operators can query their local Bitcoin node via CLI or inspect raw mempool buckets:

1. Query transaction details and feerate using "bitcoin-cli getmempoolentry <txid>". 2. Query smart fee estimates using "bitcoin-cli estimatesmartfee 6 CONSERVATIVE". 3. Calculate the satoshi-per-vbyte feerate from the transaction weight units.

The output of "getmempoolentry" exposes the exact fee paid, transaction virtual size, ancestor count, and descendant count. Ancestor feerate is critical for transactions that spend unconfirmed outputs: miners evaluate transaction packages holistically under Child-Pays-For-Parent (CPFP) rules. If a parent transaction pays 5 sat/vB and its child transaction pays 50 sat/vB, mining algorithms compute the combined package feerate to decide whether to include both transactions simultaneously in the next block template. Understanding this package feerate relationship allows users to unstick incoming payments without needing access to the sender's private keys.