On the morning of 7 November 2026, Bitcoin block 974,913 was found at 08:47:42 UTC. The next one took until 09:39:07: 51 minutes without a single block. Then blocks 974,915 and 974,916 arrived six seconds apart, at 09:40:40 and 09:40:46 UTC.
Meanwhile, at 09:46 UTC, the node behind mempool.space held 55,358 transactions that nobody had yet put in a block, enough to fill more than twelve blocks, most of them offering a tenth of a satoshi per virtual byte. So what is the mempool? It is that pile: the valid transactions a node has received but not yet seen confirmed. And the fee you attach decides where you stand in it.
Both facts are ordinary, and together they explain a payment’s timing better than any average: blocks come at random, and the queue is sorted by price. Our guide to how crypto transactions work, from Send to final follows a payment step by step and shows how to unstick it with RBF or CPFP. This lesson stays inside the waiting room: how each node fills and empties it, how the fee auction clears, why a fee estimate is a guess and where the six-confirmation habit comes from.
The life of a transaction, from your wallet to six blocks deep
The first two steps happen before the mempool. Your wallet picks coins as inputs, writes the outputs (the recipient and, usually, your change) and signs. Whatever the inputs hold and the outputs do not claim is the fee: no field in a Bitcoin transaction says “fee”. The signed transaction then goes to a few peers, which check it and pass it on, the gossip described in our lesson on peer-to-peer networks. Within seconds most listening nodes hold a copy, though not all at the same moment, and not necessarily all of them.
Every full node that accepts the transaction stores it in memory, in its mempool, and announces it onward. Acceptance is a local decision, made against two sets of rules explained in the next section.
Inclusion is the miner’s move. A mining blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool builds a block template from its own mempool, choosing the transactions that pay the most per unit of space, up to the consensus ceiling of 4,000,000 weight units set by BIP 141, which works out to about one million virtual bytes. If the pool finds a valid proof of work for that template, the block spreads across the network. Every node that accepts it removes the included transactions from its mempool, along with anything that conflicts with them.
From then on the transaction has one confirmation. Each block mined on top adds one more. Miners’ own rewards follow a stricter rule: according to the Bitcoin Wiki’s page on confirmations, freshly mined coins cannot be spent for 100 blocks. For everyone else, the number of confirmations to wait for is a choice made by the receiver, and six is a convention whose origin is traced further down.
What is the mempool in practice: one per node, never a single queue
Explorers talk about “the mempool” as if it were one public queue, and most answers to the question of what is the mempool stop there. It is not one queue. Each node keeps its own, filled by what its peers sent it and pruned by settings its operator chose. Two nodes started at different times, with different memory limits or different relay rules, hold different sets of waiting transactions. mempool.space shows one company’s nodes; a miner’s template comes from that miner’s own view.
Most of the time these views overlap heavily, because most of the network shares the default settings. They are never guaranteed to match, which explains a transaction visible on one explorer and missing on another, or a payment that vanishes from a wallet’s “pending” list without ever being rejected by the blockchain.
Consensus rules versus relay policy
A node checks two layers. Consensus rules decide whether a transaction could ever be valid: correct signatures, coins that exist and are not already spent, outputs that do not exceed inputs. Break one and any block containing that transaction is invalid for every node on the network.
Policy rules, also called standardness rules, decide only whether this node will keep and relay the transaction. Bitcoin Core’s source code sets the main ones: a maximum standard transaction weight of 400,000 units (a tenth of a block), a dust threshold computed at 3 satoshis per virtual byte, a minimum relay fee rate and limits on groups of linked transactions. A transaction that breaks policy is simply not passed on. A miner who receives it some other way may still put it in a block, and that block is valid.
The clearest recent example concerns data. Bitcoin Core 30.0, released on 10 October 2025, raised the default size allowed for OP_RETURN data outputs to 100,000 bytes, which its release notes say “effectively uncaps the limit”, and allowed several such outputs per transaction. The change set off a long dispute among node operators, and one proposal tried to turn a data limit into a consensus rule: BIP-110, which its specification page now lists as Closed after a chain split with stalled mining in August 2026, a story for our coming lesson on forks.
Bitcoin Core’s mempool defaults in 2026: 300 MB, 14 days, 0.1 sat/vB
Bitcoin Core is the most widely run node software, so its defaults shape most mempools. These are the values in the current releases and source code, checked on 7 November 2026.
| Setting | Default | Since / note |
|---|---|---|
| -maxmempool | 300 MB of memory | Long-standing; measured as memory used, not bytes of raw transactions |
| -mempoolexpiry | 336 hours (14 days) | Unconfirmed transactions older than this are dropped |
| -minrelaytxfee | 0.1 sat/vB (100 sat/kvB) | Lowered in 29.1 (4 September 2025) |
| -incrementalrelayfee | 0.1 sat/vB | Lowered in 29.1; minimum extra fee rate for a replacement |
| -blockmintxfee | 0.001 sat/vB | Lowered in 29.1; floor a miner applies to its templates |
| Full replace-by-fee | Always on | Default since 28.0 (2 October 2024); off switch removed in 29.0 (14 April 2025) |
| Cluster limits | 64 transactions, 101 kvB | Introduced in 31.0 (19 April 2026), replacing ancestor and descendant limits |
| Dust relay fee | 3 sat/vB | Outputs too small to be worth spending at this rate are non-standard |
The 300 MB figure is often misread. It caps the memory the pool uses once transactions are unpacked into the node’s data structures, which is larger than their size on the wire, so a full 300 MB mempool holds fewer than 300 MB of serialized transactions. The 0.1 sat/vB floor is recent: since Bitcoin Core 29.1 a node relays transactions paying a tenth of a satoshi per virtual byte. The 29.1 notes warned that such transactions might not propagate unless the new defaults spread; on 7 November 2026 the median fee rate of several blocks was 0.12 or 0.13 sat/vB, so they had.
Four ways a transaction leaves the mempool without being mined
Being confirmed is the normal exit. There are four others, and none of them moves your coins.
- Expiry: a transaction that has waited 336 hours on a default node is removed from that node’s pool.
- Eviction: when the pool reaches its 300 MB limit, the node throws out the transactions with the lowest fee rate and raises its own entry price, reported as mempoolminfee, so a cheap transaction can disappear from many nodes during the same rush.
- Replacement: a conflicting version spending the same coins with a higher fee arrives, and with full replace-by-fee now standard in Bitcoin Core the node keeps the better payer.
- Conflict: a block confirms another transaction that spends the same coins, which makes yours invalid from then on.
In the first two cases nothing is lost: only a block moves coins, and the wallet can broadcast the transaction again or build a new one with a better fee. “Dropped from the mempool” means “forgotten by some nodes”, not “refused by Bitcoin”.
Paying by the virtual byte: weight, vbytes and sat/vB
A Bitcoin fee does not depend on the amount sent. Moving 0.001 BTC or 100 BTC costs the same if the two transactions are the same size. What you buy is space in a block, so the price is quoted per unit of space: the fee rate, in satoshis per virtual byte (sat/vB).
Virtual bytes come from the SegWit rules. BIP 141 defines a transaction’s weight as its base size times three plus its total size, which amounts to counting each byte outside the witness (the signatures and related data) as 4 weight units and each witness byte as 1. Virtual size is the weight divided by four, rounded up. A block may weigh at most 4,000,000 units, hence the round figure of one million virtual bytes per block. The mempool.space projected blocks on 7 November 2026 were each between 997,900 and 998,000 vB.
Here is an example, with figures labelled as such. A common payment with one native SegWit input and two outputs (recipient and change) is about 141 vB. At the next-block rate mempool.space quoted at 09:55 UTC on 7 November 2026, 2.507 sat/vB, it costs about 353 satoshis, roughly 27 US cents at the site’s price of 76,021 dollars per bitcoin at 09:46 UTC (about 24 euro cents or 20 pence). At the 0.1 sat/vB floor the same payment costs about 14 satoshis, around one cent. At the median rate of the halving block on 20 April 2024, 200 sat/vB, it cost 28,200 satoshis, about 18 dollars at that day’s price of 63,849 dollars.
Each extra input adds bytes, and so fee. How wallets choose coins, and why consolidating them when fees are low can pay off later, belongs to the next lesson of this path, on the UTXO and account models. A detail for those who read node output: since 32.1, Bitcoin Core’s mempool commands report both the raw BIP 141 virtual size and a sigop-adjusted size used for policy, its notes conceding that the old “vsize” field had been described wrongly.
The fee market: an auction for one million virtual bytes
Every ten minutes or so, a miner sells about one million virtual bytes. The bidders are all the transactions waiting in its mempool, and the rule is simple: each pays exactly what it offered, with no refund if it overpaid. A pool that wants the most revenue takes the highest fee rates first and keeps going until the block is full.
When fewer transactions are waiting than one block can hold, anything above the floor gets in at the next block, and paying more buys nothing. When the queue stretches over many blocks, the price of the next one climbs, because only the top million virtual bytes of bids clear. Bitcoin fees are therefore set by the length of the queue, not by the network’s costs.
mempool.space shows this by cutting its own mempool into the blocks it expects next, sorted by fee rate. At 09:46 UTC on 7 November 2026 its projected blocks were eight. The first held 4,393 transactions with a median of 0.14 sat/vB, a range from 0.12 to 99.77 sat/vB and 0.01186 BTC of fees in total. Blocks two to seven had medians falling from 0.12 to 0.10 sat/vB, and the eighth “block” was the remaining 5.6 million vB, all at 0.10 sat/vB. In other words, the auction was barely an auction that morning: the cheapest possible bid cleared within a few blocks.
Cluster mempool: how nodes and miners now rank transactions
Transactions are not always independent. A child that spends an unconfirmed parent’s output can only be mined together with, or after, that parent. Until 2026 Bitcoin Core handled these links with limits on ancestors and descendants. Version 31.0, released on 19 April 2026, replaced that system. According to its release notes, the mempool “no longer enforces ancestor or descendant size/count limits” and instead limits each cluster of connected transactions to 64 transactions and 101 kB of virtual size.
Inside the pool, transactions are now ordered by the fee rate at which they are expected to be mined, computed over the “chunk” of transactions that would go into a block together, a parent and its child for instance. That is the mechanism behind child-pays-for-parent: a high-fee child lifts the chunk’s rate and pulls its cheap parent up the queue. The same ordering decides eviction when the pool is full and the content of block templates.
Replacements follow the same logic. A replacement is accepted only if the mempool’s fee rate diagram becomes strictly better than before, which the notes say removes all known cases where a replacement left the pool worse off. The old “CPFP carve-out”, an exception that let one extra small child bypass the descendant limit, was removed. Two new RPC commands, getmempoolcluster and getmempoolfeeratediagram, let node operators see clusters and the whole fee curve.
All of this sits on top of full replace-by-fee. Bitcoin Core 28.0 turned it on by default and 29.0, on 14 April 2025, removed the option, its notes saying users “no longer benefit from disabling it”. How to bump a fee, and why this makes an unconfirmed payment risky to accept, is in the transactions guide. For the mempool, it means every waiting transaction on a default Core node is an open bid its sender can raise, judged by the cluster rules above. The coming lesson on the double-spending problem returns to zero-confirmation payments.
How wallets guess the right fee
A fee estimate is a forecast of what miners will do in the next few blocks, made before those blocks exist. Bitcoin Core’s estimatesmartfee command, described in the RPC reference (written for an older release), learns from history: it tracks how long transactions at each fee rate took to confirm and returns the rate likely to get in within a target of 1 to 1,008 blocks (a target of 1 is treated as 2). Its conservative mode looks at a longer history and tends to answer higher, which is safer but slow to follow a drop in fees; the economical mode reacts faster. The result is given in BTC per kilo-virtual-byte, so 0.00001 BTC/kvB means 1 sat/vB.
Version 32.1, released on 27 October 2026 (its notes explain that 32.0, although tagged, was never fully announced or released), adds a second estimator built from the current content of the mempool. According to the 32.1 release notes, it only produces an estimate when recent blocks indicate a healthy mempool, and falls back to the higher of the minimum relay fee rate and the mempool’s minimum fee rate when the pool is too sparse. estimatesmartfee now returns the lower of the two estimators’ results, so the new one can only lower the old figure, never raise it. A new option lets the caller pick one estimator or the combination, which is the default.
Explorers work the other way round. mempool.space takes a snapshot of its own mempool and simulates the next blocks, as shown above. At 09:46 UTC on 7 November 2026 its rounded recommendation endpoint gave 1 sat/vB for every speed, from fastest to economy. Nine minutes later, after a block had been found, its precise endpoint gave 2.507 sat/vB for the next block, 1.313 for half an hour, 0.59 for an hour, 0.2 for economy and 0.1 as the minimum. The next-block figure went from 1 to 2.5 sat/vB in nine minutes on the same site.
Estimates fail for two reasons. Blocks arrive at random, so a “next block” fee can sit through a long gap while better bids pile up ahead of it. And the queue keeps growing after you send. The remedies, raising the fee of the transaction itself or of a child spending its change, are in the transactions guide.
Bitcoin transaction fees on 7 November 2026, and the days they exploded
The table gathers the fee picture on the morning this lesson was written, from the mempool.space public API: one node’s view on one morning, a dated photograph rather than a forecast.
| Measure, 7 November 2026 | Value | Time (UTC) |
|---|---|---|
| Chain tip | Block 974,916, mined by SECPOOL | 09:40:46 |
| Transactions waiting (mempool.space node) | 55,358 | 09:46 |
| Their total virtual size | 12.57 million vB, about 12.6 blocks | 09:46 |
| Total fees offered by all of them | 0.0238 BTC (2,384,330 satoshis) | 09:46 |
| Next-block fee rate (precise estimate) | 2.507 sat/vB | 09:55 |
| Economy and minimum rates | 0.2 and 0.1 sat/vB | 09:55 |
| Median fee rate of the last eight blocks | 0.12 to 4.06 sat/vB | 08:16 to 09:40 |
| Average fees per block, 7 November so far | 0.0224 BTC against a 3.125 BTC subsidy, about 0.7% | 09:46 |
| BTC price on mempool.space | 76,021 dollars, 68,260 euros, 56,913 pounds | 09:46 |
The last eight blocks tell the auction story in miniature. Block 974,913, mined by TrustPool with 6,953 transactions, had a median fee rate of 0.13 sat/vB. The next one, mined by Foundry USA after the 51-minute gap, held 4,074 transactions at a median of 4.06 sat/vB, the highest of the eight: during the wait, better-paying transactions had arrived and gone to the front.
Fees under 1% of what miners earn is also a fact about Bitcoin’s security budget. Since the April 2024 halving the block subsidy is 3.125 BTC, and on quiet days like this one fees add almost nothing to it. A future lesson on the halving looks at what that means as the subsidy keeps shrinking.
Quiet periods alternate with violent ones. The daily averages of fees per block published by mempool.space show the gap between a calm month and a rush.
| Date | Context | Fees |
|---|---|---|
| 22 December 2017 | Bull-market congestion | 9.65 BTC per block on average that day |
| 1 May 2023 | Before the inscription wave | 0.38 BTC per block on average |
| 8 May 2023 | BRC-20 token inscriptions | 4.64 BTC per block on average, about 132,000 dollars at roughly 28,400 dollars per BTC |
| 20 April 2024 | Halving day, Runes protocol launch | 9.67 BTC per block on average, the highest daily average in the series |
| 20 April 2024, 00:09:27 UTC | Block 840,000, mined by ViaBTC, 3,050 transactions | 37.63 BTC of fees against a 3.125 BTC subsidy; median 200 sat/vB, minimum 100 sat/vB |
| October and early November 2026 | Quiet market | 0.012 to 0.031 BTC per block on average |
The May 2023 rush followed a wave of BRC-20 tokens, which are recorded as inscriptions on individual satoshis and filled blocks with small data transactions, as CoinDesk reported on 8 May 2023. The April 2024 record had two causes in the same block: it was the halving block, and the Runes specification states that the protocol activates on block 840,000, so people competed to be among the first to create runes there. Its fees were worth about 2.4 million dollars at the day’s price of 63,849 dollars, twelve times the subsidy. In the same series, the top five days are 20 April 2024 and four days of late 2017.
Ethereum’s txpool: nonces, a burned base fee and a separate blob market
Ethereum has the same idea under another name. Each node keeps a transaction pool, the txpool, with its own limits. In geth, one of the main execution clients, the documented defaults are 5,120 slots for executable transactions across all accounts, 16 guaranteed per account, 1,024 slots for non-executable ones, a three-hour lifetime for those queued transactions and a 10% minimum price bump to replace one.
“Non-executable” points at the main difference from Bitcoin. Ethereum accounts number their transactions with a nonce, and geth parks a transaction whose earlier nonce is missing in that queued section, where it waits for the gap to fill and is dropped after three hours by default. A stuck nonce 7 therefore holds back nonce 8 and every later one, however well they pay. The transactions guide explains the same-nonce replacement; the next lesson, on account models, goes further into nonces.
The fee works as the transactions guide describes: a burned base fee plus a tip for the validator. For the pool, one detail matters. In ethereum.org‘s words, the base fee “acts as a reserve price”: a transaction offering less per unit of gas than the current base fee cannot be included, and waits until the base fee falls, by 12.5% per block at most. Our glossary entry on gas fees has examples; a future lesson on gas and EIP-1559 covers the mechanism.
Etherscan’s gas tracker showed how low that was on 7 November 2026 at 09:48:41 UTC: a base fee of 0.046 gwei, low, average and high prices of 0.046, 0.047 and 0.05 gwei, priority fees from 0 to 0.004 gwei. A plain ether transfer uses 21,000 gas, so at 0.047 gwei it cost 987 gwei, or 0.000000987 ETH, about 0.2 US cents at the page’s price of 2,244.65 dollars.
Since EIP-4844, rollups post their data in “blobs” that have a fee market of their own: the proposal gives blob gas its own targeting rule, independent of normal gas, and nodes keep blobs for about 18 days. That separate market is one reason layer 2 fees stay low, as our comparison of layer 1 and layer 2 networks explains.
The public txpool is also incomplete. Some wallets and traders send transactions straight to block builders to avoid being front-run, as our guide to MEV protection and proposer-builder separation describes, so an explorer’s list of pending Ethereum transactions misses part of the queue.
Why six confirmations: what Nakamoto actually calculated
Our summary of the Bitcoin white paper gives the headline figures. Section 11 of the paper is worth reading on its own terms. It imagines an attacker who controls a share q of the hash power, while honest miners hold p = 1 – q. The merchant waits until the payment is z blocks deep. The attacker, mining a secret chain in which the payment never happened, must catch up from z blocks behind.
Satoshi models the attacker’s progress during that time as a Poisson variable with an expected value of z times q/p, adds the probability that he can still catch up from each possible deficit, and gives a short C program to compute the total. His comment on the output: “Running some results, we can see the probability drop off exponentially with z.”
For an attacker with 10% of the hash power, one confirmation leaves a 20.5% chance of success, three confirmations 1.3%, six 0.024% and ten 0.00012%. The paper then turns the question around and asks how many blocks keep the risk under 0.1% for each attacker size.
| Attacker’s share of hash power (q) | Blocks needed for a success chance under 0.1% (z) |
|---|---|
| 10% | 5 |
| 15% | 8 |
| 20% | 11 |
| 25% | 15 |
| 30% | 24 |
| 35% | 41 |
| 40% | 89 |
| 45% | 340 |
That table is where six comes from. The Bitcoin Wiki recalls that the classic client showed a transaction as “n/unconfirmed” until it was 6 blocks deep, on the two assumptions the transactions guide discusses: an attacker below 10% of the hash rate, and a risk under 0.1% judged acceptable. Read against the table, six is one block more than the five that answer q = 10%. Against an attacker with a third of the hash rate it is far too few. Against a thief with no mining power at all, it is far more than needed.
Later work refined the calculation. Meni Rosenfeld’s Analysis of Hashrate-Based Double Spending, posted in February 2014, studies the random processes behind typical attacks and their probabilities of success. Cyril Grunspan and Ricardo Pérez-Marco, in Double spend races (2017), correct the race analysis of the white paper, derive a closed-form formula and find that more confirmations are needed than Nakamoto’s figures suggest. The shape of the answer stays the same: the risk falls fast with each block, and the right number depends on how much hash power an attacker could rent or own and on what the payment is worth to him.
How long does a Bitcoin transaction take? Honest numbers
The honest answer comes first: about ten minutes for the first confirmation on average, but any single wait can last a few seconds or more than an hour, as the 51-minute gap of 7 November 2026 showed. Add the confirmations the receiver requires. And if the fee is below what the market is paying, the wait can stretch to hours or days, until default nodes drop the transaction after 14 days.
Block discovery behaves like a lottery drawn many times per second, so the time between blocks follows an exponential distribution; the transactions guide gives the odds for a single block. Taking a ten-minute mean as a model, not a promise, the same arithmetic says more about the waits that matter once a payment pays enough for the next block:
- A single gap of more than an hour happens about 0.25% of the time, roughly once in 400 blocks, or about ten times a month.
- Three confirmations take more than an hour about 6% of the time.
- Six confirmations take 60 minutes on average. About 30% of the time they arrive within 45 minutes; 11.6% of the time they take more than 90 minutes, and 2% of the time more than two hours.
Real blocks drift from the model when the hash rate changes between two difficulty adjustments. In the period running on 7 November 2026 they averaged 625.8 seconds, about 10.4 minutes, and the next adjustment, due at height 975,744, was projected that morning to lower difficulty by about 4%.
Few businesses actually wait for six. Kraken’s deposit processing page, last updated on 22 October 2026, says it credits Bitcoin deposits after three confirmations. Each receiver sets its own threshold, weighing the amount at stake against the cost of rewriting two or three blocks. A café selling a coffee may accept a payment with no confirmation at all and take the small risk of a replaced transaction. Someone selling a house would reasonably wait for more than six. No one can promise a time; a receiver can only choose a level of risk.
Ethereum answers the question differently. A payment lands in a 12-second slot, and the checkpoint above it is normally finalized about two epochs later, around 13 minutes, as the transactions guide works out. Reverting it would, according to ethereum.org, cost an attacker at least one third of all staked ether. A coming lesson on finality and chain reorganisations compares these models in depth.
Network fees and your tax return in the US and the UK
Fees matter at tax time, and the rules differ by country. In the United States, the IRS virtual currency FAQ says the cost basis of crypto you buy includes fees, commissions and other acquisition costs, and that moving coins between your own wallets or accounts is not a taxable event. The Treasury regulation on digital assets, 26 CFR 1.1001-7, defines transaction costs as amounts paid in cash or property, including digital assets, to effect a sale, disposition or acquisition, and lists transaction fees among them. Our guide to crypto taxes in the United States covers the reporting side.
In the United Kingdom, HMRC’s Cryptoassets Manual lists transaction fees paid for having a transaction included on the distributed ledger among the costs allowable when computing a gain, under section 38 of the Taxation of Chargeable Gains Act 1992. Our guide to crypto taxes in the UK gives the rest of the calculation. In both countries the practical habit is the same: keep the transaction ID and the fee in satoshis of every payment, since any block explorer can prove them later.
A short checklist before you pick a fee
- Look at the projected next blocks on an explorer, rather than at a single recommended number, and note the time: estimates change within minutes.
- If the queue is shorter than a block, the minimum relay rate of 0.1 sat/vB is enough for nodes running Bitcoin Core 29.1 or later; older nodes still refuse anything under 1 sat/vB.
- If you are not in a hurry, bid low with replace-by-fee available and raise the fee later if needed; recent Bitcoin Core nodes accept any replacement that pays enough more.
- Ask the receiver how many confirmations it requires before you promise anyone a time.
- If your transaction disappears from the explorer, check whether the coins are still in your wallet before doing anything else: a dropped transaction can be sent again.
- On Ethereum, check that no earlier nonce of the same account is still pending before blaming the fee.
The next lesson in this path looks at what a transaction actually spends: Bitcoin’s unspent outputs against Ethereum’s accounts, and why that choice changes the size, and so the fee, of the same payment.
