Between "transaction sent" and "transaction confirmed" lies a place few Bitcoin users ever consciously notice, even though practically every payment passes through it: the mempool, short for "memory pool," each node's own waiting area for transactions that are valid but still waiting to be included in a block. This post explains the rules that govern this waiting room, why some payments wait longer than others, and what you can do if your own transaction gets stuck.
Why Every Node Keeps Its Own Waiting Room Instead of Sharing One
A detail that looks inefficient at first glance actually makes sense on closer inspection: there is no single, global mempool, instead every individual node keeps its own local waiting area, with contents that can genuinely differ slightly in detail depending on when and through which neighbors it learned about which transactions. A single, shared waiting room would mean a central place where someone decides who waits and who doesn't, exactly the kind of control point Bitcoin is designed to avoid. Instead, the many local mempools across the network continuously converge on their own, simply because nodes keep passing transactions on to each other (see Part 5 on the network layer), without any single "truth" about the mempool's state ever having to be centrally recorded anywhere.
Not Every Valid Wish Gets Granted Immediately
An important shift in perspective compared to Part 2 of this series: everything described in this post is explicitly NOT a consensus rule. These are so-called "policy" rules: rules each individual node sets for itself to decide which transactions it accepts into its own mempool and forwards to its neighbors. A transaction that violates a pure policy rule but is otherwise completely valid could theoretically still be picked up directly by a miner and become part of a valid block, it just wouldn't get there via the usual route through every node's mempool.
When an Amount Counts as "Dust"
A particularly vivid policy rule is the dust limit. The idea behind it: a bitcoin amount so tiny that the future fee to ever spend it again would exceed its own value is economically pointless, and most nodes won't even relay it.
The source code (GetDustThreshold in src/policy/policy.cpp) calculates this fairly precisely: it estimates how large the future input needed to spend exactly this amount would be, and compares that against the current standard fee rate. Under the usual default settings (3,000 satoshis per kilobyte), that works out to a dust limit of about 546 satoshis for a classic Bitcoin address, and only around 294 satoshis for a more modern SegWit address, thanks to smaller, cheaper signature data. An interesting detail: for Taproot addresses, the limit could theoretically be set even lower (since a single Schnorr signature is enough to spend), but the code deliberately doesn't make that additional reduction, so as not to push the network's general dust threshold down even further.
A Look Inside the Waiting Room: How Fees Actually Come About
Picture the mempool as a waiting room with limited seats on the next "bus" (the next block, which departs on average every ten minutes and offers roughly 4 million weight units of space, see Part 2 of this series). When things are quiet, practically every transaction gets a seat without trouble, no matter how low its fee. But if more people want to ride at a given moment than there are seats (say, because a lot of people happen to want to move bitcoin at the same time), a simple but effective principle takes over: miners sort waiting transactions by fee per byte (more precisely, per weight unit) and pick up the highest payers first. This is ultimately a classic market mechanism: no official sets a fee, it emerges entirely on its own from supply (available block space) and demand (how many people currently want to pay).
How Your Wallet Knows What Fee Is Currently Appropriate
Most wallet apps automatically suggest an appropriate fee, without you having to do the math yourself. Bitcoin Core solves this with a built-in estimation mechanism (the CBlockPolicyEstimator class in src/policy/fees/). The basic idea: the node continuously observes which "fee bucket" a transaction lands in when it arrives in the mempool, and then keeps track of how many blocks later transactions from each fee bucket actually got confirmed. Over time, this builds up a fairly reliable picture: "transactions at this fee rate have been confirmed within three blocks 90% of the time over the past few weeks." Whether you want a payment to be especially fast or can afford to wait comfortably, your wallet draws on exactly this historically gathered data to make you an appropriate recommendation, with no one having to manually set a price at all.
Raising the Fee After the Fact: Replace-by-Fee
What if you sent a transaction with too low a fee and it just isn't confirming? That's exactly what Replace-by-Fee (RBF, officially BIP125) is for: the ability to replace a still-unconfirmed transaction with a new version carrying a higher fee.
Technically, the implementation is surprisingly simple: a transaction signals its own replaceability purely by having at least one of its inputs carry a specific internal number (nSequence) below a set threshold (MAX_BIP125_RBF_SEQUENCE, specifically the hexadecimal value 0xfffffffd). The corresponding check function in the code (SignalsOptInRBF in src/util/rbf.cpp) consists at its core of nothing more than a single number comparison per input. A nice example of how technically powerful features in the Bitcoin code are often implemented surprisingly compactly.
To prevent this option from being abused to deliberately push out a large number of unrelated, independent transactions from the mempool in one go, there's a built-in cap: a single replacement may affect at most 100 distinct, connected transaction groups at once (MAX_REPLACEMENT_CANDIDATES in src/policy/rbf.h), a deliberate safeguard against a kind of congestion attack on other nodes' mempools.
When One Payment Builds on Another: Chain Limits
Bitcoin transactions can build on each other before any of them is even confirmed, for example when you immediately forward an unconfirmed balance. To keep such chains of entirely unconfirmed transactions from growing unchecked and overloading the mempool, Bitcoin Core by default caps both the number of unconfirmed "ancestors" and unconfirmed "descendants" per transaction at 25 each (DEFAULT_ANCESTOR_LIMIT, DEFAULT_DESCENDANT_LIMIT in src/policy/policy.h).
That's also why a popular technique called "Child Pays For Parent" (CPFP), where a new, well-paying transaction is used to indirectly help a stuck earlier transaction confirm faster, doesn't work without limit: eventually, this chain cap kicks in.
A Concrete Example: The Child Helps the Parent
Suppose a few hours ago you sent 0.01 BTC to a friend, but with a fee that's now too low, and your wallet doesn't support Replace-by-Fee. Your friend herself can still act: she simply creates a new transaction of her own that uses exactly this still-unconfirmed payment as an input, and attaches a particularly high fee to this new transaction. A miner who wants to pick up this second transaction is forced to also include the original, first transaction in the same block, after all, they belong together. The high fee on the second transaction effectively "pulls" the first one along with it. That's exactly Child Pays For Parent (CPFP): the "child" pays for its "parent's" low fee, as long as the chain cap of 25 described above isn't exceeded.
When Many People Want to Pay at Once: Real Examples of Full Waiting Rooms
This principle isn't abstract theory. Bitcoin's history has repeatedly seen phases where demand for block space clearly outstripped supply and typical fees rose noticeably as a result, for example in December 2017, when a rapid surge of public interest in Bitcoin led to far more simultaneous transaction requests than usual, or in spring 2023, when a new, experimental use of block space for so-called "Ordinals" inscriptions briefly caused unusually full mempools. In both cases, exactly the mechanism described here kicked in: whoever wanted a fast confirmation had to pay a higher fee, whoever had time could simply wait for the waiting room to empty out again. No state of emergency, no system failure, just the mechanism described above under real load.
What This Practically Means for You as a User
A few practical takeaways for everyday use: first, an "unconfirmed" transaction isn't automatically lost, it's simply waiting, and modern wallets usually give you tools (RBF or CPFP) to help it along yourself instead of watching helplessly. Second, your wallet's suggested fee isn't a random guess, it's based on real, continuously updated observational data about what has actually worked in the recent past. And third: if a payment takes longer than usual during a heavily loaded period on the network, that's not a technical malfunction, it's simply an entirely ordinary supply-and-demand mechanism, the same one that sets prices for pretty much any scarce resource.
Conclusion: The Mempool Isn't Consensus, But It's Not the Wild West Either
The mempool nicely illustrates that "decentralized" doesn't mean "ruleless": every node formally decides for itself which transactions it accepts, but in practice the vast majority follow the same, carefully thought-out default rules, for good reason, since these rules protect every individual node equally against overload and abuse, without any central authority needing to enforce them.
Next up, Part 5: No Central Server, how Bitcoin nodes even find each other at all.
