BTC Blockchain: What Happens After You Send Bitcoin?

After you send bitcoin, the signed transaction is announced to peers, checked against network rules, and held as unconfirmed data until a miner includes it in a valid block. Nodes then verify that block independently. Additional blocks built after it create more confirmations. The blockchain records accepted transactions; it does not turn an invalid payment into a valid one simply because somebody broadcast it.

A wallet constructs a spending request

A Bitcoin wallet identifies spendable transaction outputs associated with its keys. To pay someone, it creates new outputs for the recipient and usually for change back to the sender. The transaction inputs point to older unspent outputs, and a digital signature satisfies the conditions required to spend them.

The amount selected from earlier outputs can be larger than the payment. If the wallet spends an input worth 0.01 BTC to make a 0.006 BTC payment, it might create a second output returning most of the difference as change. The remaining difference between inputs and outputs becomes the transaction fee. This is why an explorer can show more than one output even for a simple purchase.

The Bitcoin developer transaction guide describes this UTXO model. Thinking in spendable outputs is more accurate than imagining that a node edits one account balance in place.

Broadcast is the start, not confirmation

Once signed, the transaction is sent to connected peers. Each receiving node applies its own validation rules before relaying it. A valid-looking transaction can spread across the peer-to-peer network and enter nodes’ pools of unconfirmed transactions, commonly called mempools.

Mempools are local. Two nodes can temporarily hold different sets because they received data at different times or follow different policies for relaying unconfirmed transactions. A payment appearing in one explorer’s mempool shows that its data source has seen it; it does not mean the transaction is already in the blockchain.

Bit.Fan’s guide to how transactions enter the Bitcoin blockchain places this relay stage before block inclusion. That order helps diagnose an absent payment. First ask whether a transaction was created and broadcast. Then look for block confirmation.

Miners select transactions and build candidates

Miners assemble candidate blocks from transactions they know about. Fees can influence selection when block space is in demand, but a high fee cannot make an invalid transaction acceptable. The candidate also includes a coinbase transaction, which can claim the allowed block subsidy and the fees from included transactions.

Mining is a proof-of-work competition over block headers. Finding a header hash that meets the network target allows a miner to announce a candidate. It is still a proposal. Other nodes check the proof of work, the block structure, and every included transaction before accepting it.

This separation limits a miner’s discretion. A miner can choose among valid transactions for its candidate, yet nodes need not accept a block that creates too much subsidy or spends an output twice.

The first confirmation changes the status

When a valid block containing the transaction becomes part of the active chain, the payment has one confirmation. A block built on top gives it two, and the count continues in that fashion. Confirmations measure how deeply the transaction sits under subsequent proof of work.

A recent chain tip can occasionally be replaced when competing valid blocks reach different parts of the network. Software follows the chain selected by Bitcoin’s consensus rules, so a transaction from a displaced tip may become unconfirmed again before appearing in a later block. This is one reason recipients choose a confirmation threshold based on value and risk instead of treating every appearance as equally settled.

There is no universal threshold that fits every payment. A small retail purchase and a large irreversible delivery can justify different policies. The recipient, rather than the Bitcoin protocol, decides when to act on the confirmation evidence.

Fees affect priority but do not buy a deadline

Fees are usually discussed as a rate relative to transaction size in virtual bytes. A large transaction can therefore pay more total satoshis than a small one while offering a lower fee rate. Miners comparing candidates generally care about the block-space return, making fee rate a more useful field than total fee alone.

Demand for block space changes. A rate that was competitive when a wallet first estimated it may later sit behind other transactions. Some wallet techniques can replace or supplement a transaction with more fees, but availability depends on how the original was created and on wallet support.

Avoid interpreting the roughly ten-minute target between blocks as a delivery guarantee. Actual intervals vary, and inclusion depends on valid block discovery plus transaction selection.

Trace the process with the right identifier

A transaction ID, or TXID, is the most direct lookup key. In a block explorer, verify the network, outputs, inclusion status, block height, and confirmation count. Do not infer the recipient’s real identity from an address alone, and never expose private keys or recovery words to search a public ledger.

If no explorer sees the TXID, return to the sending wallet and check whether it actually broadcast the transaction. If the TXID is visible but unconfirmed, review its fee rate and mempool status. If it is confirmed, compare the receiving output rather than an unrelated change output. Following these stages turns a mysterious pending label into a specific place in Bitcoin’s transaction lifecycle.