You open a Bitcoin wallet, enter an address, choose an amount and press Send. Within seconds, a transaction may appear as pending. Later, it receives its first confirmation.
That simple interface hides a much more interesting process.
Bitcoin does not move from one wallet account to another through a central payment processor. Your wallet constructs a transaction that spends existing outputs, authorizes that spend with cryptographic signatures and broadcasts the transaction into a peer-to-peer network. Full nodes independently check it. Eligible transactions may wait in individual nodes' mempools. Miners can select transactions for candidate blocks, perform proof of work and broadcast a valid block back to the network, where nodes validate it again.
So what actually happens between pressing Send and seeing 1 confirmation?
Key Findings
- A Bitcoin transaction spends existing unspent transaction outputs (UTXOs) and creates new outputs rather than transferring coins between account balances.
- Your wallet typically selects spendable UTXOs, constructs the outputs, calculates a fee and signs the transaction using the keys needed to authorize the spend.
- Broadcasting does not mean confirmation. Full nodes independently validate transactions before accepting and relaying them according to their consensus and policy rules.
- There is no single global Bitcoin mempool. Individual nodes maintain their own views of eligible unconfirmed transactions.
- Miners select transactions for blocks, generally with economic incentives to prioritize transactions that contribute attractive fees, but miners cannot make an invalid transaction valid under the rules enforced by full nodes.
- A transaction receives its first confirmation when it is included in a block accepted into the active blockchain. Each subsequent block adds another confirmation.
- Bitcoin targets an average interval between blocks, but an individual transaction is not guaranteed to confirm in exactly 10 minutes.
How Does a Bitcoin Transaction Work?
A Bitcoin transaction can be understood as a chain of several distinct stages:
- Your wallet identifies Bitcoin outputs that it can spend.
- It constructs a new transaction with one or more inputs and outputs.
- The transaction is cryptographically authorized with the required signatures or witness data.
- The signed transaction is broadcast to one or more Bitcoin peers.
- Full nodes independently validate it before accepting and relaying it.
- Eligible unconfirmed transactions can enter each node's local mempool.
- Miners or mining pools select transactions when constructing block templates.
- Mining hardware searches for proof of work for a candidate block.
- A successfully mined block is broadcast and independently validated by nodes.
- If the block becomes part of the active chain, transactions inside it receive their first confirmation.
Each stage involves a different part of Bitcoin. Understanding those roles is important because wallets, nodes and miners do not perform the same job.
Step 1: Your Wallet Finds Bitcoin It Can Spend
The balance displayed by a Bitcoin wallet can make Bitcoin look like a conventional bank account. At the protocol level, that is not how the ledger is organized.
Bitcoin uses an Unspent Transaction Output model. A transaction output that has not yet been spent is called a UTXO. When you make a new payment, the transaction references one or more existing outputs as inputs and creates new outputs.
The Bitcoin Developer Guide's transaction documentation describes each input as spending satoshis from a previous output, while each newly created output remains available as a UTXO until a later transaction spends it.
In other words, your wallet's displayed balance is an abstraction over spendable outputs associated with the keys and scripts the wallet can satisfy.
Bitcoin Does Not Use Account Balances Like a Bank
Suppose your wallet controls two spendable UTXOs worth 0.006 BTC and 0.004 BTC. The interface may simply display a balance of 0.010 BTC.
If you want to make a payment, the wallet can select sufficient UTXOs as transaction inputs and create new outputs according to the payment being made. It does not edit a central account balance from 0.010 BTC to a lower number.
The ledger advances by spending old outputs and creating new ones.
Step 2: The Wallet Builds the Transaction
Once the wallet has selected suitable inputs, it constructs the transaction.
At a simplified level, the transaction specifies which previous outputs are being spent and which new outputs should be created. One output may pay the intended recipient. Another may return excess value to the sender as change.
Why Does Bitcoin Create a Change Output?
A UTXO is spent as an output, not partially edited in place.
Imagine a wallet selects a UTXO larger than the payment it needs to make. The transaction can create one output for the recipient and another output returning the remaining spendable value to a script controlled by the sender, after accounting for the transaction fee.
This is why a block explorer may show multiple outputs even when a user believes they made only one payment.
Step 3: The Transaction Is Cryptographically Authorized
Constructing a transaction is not enough. The spender must satisfy the conditions attached to the outputs being spent.
For common forms of Bitcoin ownership, this involves creating cryptographic signatures using the appropriate private keys. Those signatures allow other participants to verify authorization without revealing the private keys themselves.
The Bitcoin Developer documentation defines a private key as the private part of a keypair capable of creating signatures that can be verified with the corresponding public key. Its technical glossary describes signatures as values used in Bitcoin to authorize the spending of previously received satoshis.
The important point is that the network does not need to trust the wallet provider's statement that the sender is authorized. The transaction contains cryptographic evidence that nodes can verify according to Bitcoin's rules.
Step 4: The Wallet Broadcasts the Transaction
After the transaction is constructed and signed, it still is not part of the blockchain.
It first needs to reach the Bitcoin network.
A wallet may submit the transaction through its own node or through infrastructure operated by a wallet provider. From there, the transaction can propagate across Bitcoin's peer-to-peer network.
According to the Bitcoin P2P Network documentation, peers exchange transaction inventory and can request transaction data; a receiving peer can then forward a valid transaction onward. Full nodes verify blocks and transactions before relaying them to other nodes.
Broadcast Is Not the Same as Confirmation
This distinction causes a great deal of confusion.
A wallet can display a transaction almost immediately after broadcast, but that does not mean the transaction has been recorded in a confirmed block.
At this point, it is still an unconfirmed transaction.
Step 5: Full Nodes Validate the Transaction
A transaction does not become acceptable merely because a wallet broadcasts it.
Full nodes independently check transactions against the rules they enforce. Among other requirements, a node needs to determine whether the referenced outputs exist and remain unspent, whether the spending conditions are satisfied and whether the transaction violates applicable consensus rules. Nodes also apply local relay and mempool policies when deciding what unconfirmed transactions they will accept and forward.
This is an important part of Bitcoin's broader power structure. Miners produce blocks, but full nodes do not simply trust whatever a miner, wallet or other participant sends them.
If a transaction fails the rules a node requires, that node does not need to accept it merely because other participants want it processed.
Step 6: The Transaction May Enter the Mempool
A valid, policy-acceptable transaction that has not yet been confirmed may be stored in a node's mempool, short for memory pool.
It is tempting to imagine the mempool as one global waiting room where every Bitcoin transaction sits until a miner arrives. That model is convenient, but it is not literally how Bitcoin works.
There Is No Single Global Bitcoin Mempool
Each node can maintain its own set of unconfirmed transactions.
Nodes may receive transactions at different times, have different memory constraints or apply different policy settings. As a result, two nodes do not have to hold identical mempools at every moment.
This also means that being present in one node's mempool is not a permanent status granted by the Bitcoin protocol. Unconfirmed transactions can be removed from local mempools, replaced under applicable policy, confirmed in blocks or disappear from particular nodes over time.
Step 7: Miners Choose Transactions for Candidate Blocks
Now the transaction reaches the part of the process most people associate with Bitcoin mining.
Miners and mining pools construct block templates containing transactions they are willing to include. Transaction fees create an economic incentive to use scarce block space efficiently, so fee economics strongly influence transaction selection.
The Bitcoin mining documentation describes mining software obtaining new transactions from the network and constructing blocks from transaction data before hashing block headers in search of proof of work.
If you want to understand who performs this work in practice, our investigation into who really mines Bitcoin examines mining pools and how block-production hashrate is distributed.
Miners Do Not Get to Make Invalid Transactions Valid
Transaction selection should not be confused with unilateral control over Bitcoin's rules.
A miner can choose which eligible transactions to include, exclude or delay in its own candidate block. But if the resulting block violates the consensus rules enforced by full nodes, those nodes can reject the block.
Hashpower determines who succeeds in producing proof of work. It does not give a miner permission to make consensus-invalid data valid to nodes enforcing Bitcoin's existing rules.
Step 8: Miners Search for Proof of Work
After a candidate block has been assembled, mining hardware repeatedly hashes variations of the block header, searching for a result below the network's current target.
This is Bitcoin's proof-of-work process.
Finding a valid proof is computationally expensive and probabilistic. A miner cannot simply decide that its block should be next. It must find a header satisfying the required proof-of-work target.
When a miner finds a valid result, it can broadcast the completed block to the network.
Step 9: Full Nodes Validate the Block
Mining a block is not the final validation step.
Nodes receiving the block independently check it against the consensus rules they enforce, including its proof of work and the validity of the transactions it contains.
The Bitcoin blockchain documentation describes each full node as independently maintaining a blockchain containing only blocks that node has validated.
This creates an important division of labor: miners propose valid proof-of-work-backed blocks; full nodes independently determine whether those blocks satisfy the rules they enforce.
Step 10: The Transaction Gets Its First Confirmation
When a valid block containing your transaction becomes part of the active blockchain, the transaction has its first confirmation.
If another block is subsequently built on top of that block, the transaction has two confirmations. Another block makes three, and so on.
Additional confirmations place more accumulated proof of work on top of the block containing the transaction, making reversal increasingly difficult.
Does a Bitcoin Transaction Take 10 Minutes?
Not necessarily.
Bitcoin's block interval is a long-run target, not a countdown timer attached to each transaction.
The Bitcoin.org transaction FAQ notes that new blocks arrive approximately every 10 minutes on average, while individual block discovery is probabilistic. A block may therefore arrive much sooner or considerably later.
And even when a new block arrives, your transaction is not guaranteed to be inside it.
Confirmation time depends on factors including current demand for block space, the transaction's effective fee rate, transaction relationships and the selection policies used by miners or mining pools.
How Do Bitcoin Transaction Fees Work?
A common misconception is that the Bitcoin fee is primarily determined by how much BTC you send.
Instead, fee economics are closely related to the amount of block space a transaction consumes and the fee rate it offers for that space.
A transaction moving a very large amount of BTC can therefore be structurally smaller than another transaction moving far less BTC if the second transaction requires more inputs or otherwise consumes more block space.
When demand for block space rises, transactions offering more attractive fee rates generally have a stronger economic case for earlier inclusion. When demand falls, lower-fee transactions may become competitive.
What Happens If a Bitcoin Transaction Stays Pending?
A transaction can remain unconfirmed when miners continue filling available block space with other transactions, when its fee economics are unattractive relative to current demand or when network policy prevents it from propagating as widely as expected.
Unconfirmed should not be confused with failed. A transaction can remain valid while waiting for inclusion.
At the same time, an unconfirmed transaction does not have the same status as a transaction already buried in the blockchain. Bitcoin Core's documentation explicitly warns against assuming that the first version of an unconfirmed transaction seen by a node must ultimately be the version that confirms.
Can an Unconfirmed Bitcoin Transaction Be Replaced?
Under current Bitcoin Core mempool policy, transaction replacement is an important part of how unconfirmed transactions are handled.
Bitcoin Core changed the default mempoolfullrbf setting in version 28.0, and later removed the option as full replace-by-fee became standard behavior. Current Bitcoin Core mempool replacement policy documents the conditions under which conflicting transactions can replace transactions already in a node's mempool.
This is another reason not to treat an unconfirmed transaction as equivalent to a confirmed blockchain record.
What Happens to the Mempool After Confirmation?
Once a node accepts a block containing an unconfirmed transaction, that transaction no longer needs to remain in that node's mempool as an unconfirmed candidate.
The transaction is now represented in the blockchain state through the confirmed block.
Blockchain reorganizations add another layer of nuance. Transactions from blocks that cease to be part of the active chain may become eligible for mempool consideration again if they remain valid and are not confirmed by the replacement chain.
What Is a Bitcoin Transaction ID?
A transaction ID, usually shortened to TXID, is an identifier derived from transaction data. It allows wallets, nodes, block explorers and users to refer to a particular transaction.
Segregated Witness introduced an additional identifier called the wtxid, which incorporates witness data. BIP 141 defines the distinction between the traditional txid serialization and the witness transaction identifier.
For ordinary users, the TXID is most commonly encountered when looking up the status of a payment in a block explorer or providing a transaction reference to another party.
Does Bitcoin Actually Move Between Wallets?
Not in the same sense that money moves between two account balances at a bank.
Wallet software presents a user-friendly model of sending and receiving Bitcoin. Underneath that interface, transactions consume previous outputs and create new outputs subject to new spending conditions.
The wallet manages keys, constructs transactions and interprets blockchain data to calculate what value it can spend. The blockchain records transactions and their outputs; it does not contain a conventional account entry labeled with your name and a mutable Bitcoin balance.
Who Actually Confirms a Bitcoin Transaction?
The phrase “miners confirm transactions” is useful shorthand, but it hides an important distinction.
Miners perform proof of work and produce candidate blocks that can include transactions. Full nodes independently validate those blocks and transactions according to the rules they enforce. A transaction receives blockchain confirmations when it is included in a valid block on the active chain and additional valid blocks are built after it.
So confirmation is not a single actor pressing an approval button. It emerges from block production, independent validation and the chain's accumulated proof of work.
Bitcoin Transaction Lifecycle in One Sentence
A wallet spends existing UTXOs by constructing and authorizing a new transaction, broadcasts it to peers, full nodes independently validate and relay it, miners may include it in a proof-of-work block, nodes validate that block, and the transaction gains confirmations as additional blocks build on top of it.
That entire process happens without a bank, card network or central Bitcoin server deciding whether the payment should be recorded.
Frequently Asked Questions
What happens when you send Bitcoin?
Your wallet constructs a transaction spending existing UTXOs, creates new outputs, authorizes the spend with the required cryptographic data and broadcasts the transaction. Nodes validate it, eligible transactions may enter local mempools, and miners may include it in a block.
Is a Bitcoin transaction instant?
Transaction propagation can be fast, but blockchain confirmation is a separate event. A transaction does not receive its first confirmation until it is included in a valid block on the active chain.
How long does a Bitcoin transaction take?
There is no guaranteed confirmation time. Blocks are found probabilistically, and transaction inclusion also depends on block-space demand, fee economics and miner selection. The roughly 10-minute block interval is an average, not a promise that every transaction confirms within 10 minutes.
What is the Bitcoin mempool?
A mempool is a node's local collection of eligible unconfirmed transactions. Bitcoin does not have one authoritative global mempool shared identically by every node.
Do miners validate Bitcoin transactions?
Mining systems validate transactions they consider for blocks, but validation is not exclusive to miners. Full nodes independently validate transactions and blocks. A miner cannot force nodes to accept a block that violates the consensus rules those nodes enforce.
What does one Bitcoin confirmation mean?
One confirmation means the transaction has been included in a block on the active blockchain. Each additional block built on top of that block adds another confirmation.
Can a Bitcoin transaction be reversed?
Bitcoin does not provide a conventional chargeback mechanism. Unconfirmed transactions can have competing versions under applicable network policies, while confirmed transactions become progressively harder to reverse as additional proof of work accumulates on top of their block. The appropriate number of confirmations depends on the recipient's risk tolerance and circumstances.
Why is my Bitcoin transaction still pending?
A transaction may remain pending because it has not yet been selected for a block. Common factors include competition for block space, its fee rate relative to other transactions and transaction dependencies. Local node policies can also affect how an unconfirmed transaction propagates and remains in mempools.
Primary Sources and Further Reading
This article was researched primarily from Bitcoin's technical documentation and protocol specifications. Additional technical references include the Bitcoin Improvement Proposals repository and Bitcoin Core 29.0 release notes. Primary documentation is linked directly alongside the relevant technical claims throughout the article rather than duplicated here.
Editorial note: The Crypto Public focuses on how cryptocurrency systems actually work. Technical behavior can change as Bitcoin software and network policy evolve. This article distinguishes consensus rules from implementation and relay policy where that distinction materially affects the explanation.
Responses (0 )