A concrete example
Seeing a transaction in an explorer’s mempool does not guarantee the next miner will include it.
In context
Nodes maintain their own pools of pending transactions; there is no single authoritative global mempool. A transaction included in the current tip has one confirmation. Each additional block increases the count, but the appropriate acceptance threshold depends on the payment and network conditions.
The related mechanism, visually
- 01Transaction size
- 02Multiply by sat/vB
- 03Total offered fee
- 04Inclusion remains uncertain
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
Bitcoin fees depend largely on transaction weight and competition for block space. Wallets commonly quote satoshis per virtual byte. A payment of a large amount can be smaller in data size than a small payment consuming many inputs. Fee estimates are forecasts of demand, not reservations guaranteeing a block.
Put the mechanism into context
A fictional transaction is 180 virtual bytes. Compare rates of 5 and 20 sat/vB. Calculate each total fee, then explain why neither calculation tells you an exact confirmation time. Do not confuse virtual bytes with the transferred bitcoin amount.
Apply it in the workshop →What this mechanism does not guarantee
Replacement policies and child-pays-for-parent can help some pending transactions, but support and eligibility vary. A replacement changes the transaction identifier and requires careful recipient tracking. A confirmation policy should also account for value and reorganization risk; paying more affects inclusion incentives rather than making invalid transactions acceptable.
Explore the full explanation
Bitcoin fees, mempool and confirmations
Fees are commonly quoted in satoshis per virtual byte.