A Bitcoin transaction is a signed message that reassigns ownership of specific coins from one address to another, broadcast to a public network that independently verifies it and records it permanently. No coins move. No bank clears anything. What actually travels across the network is a few hundred bytes of data carrying a mathematical proof that you control the funds you are trying to spend.
Most guides explain this to someone who has never sent bitcoin. This one is written for the more common situation: you have already pressed send, you are looking at a transaction that says "pending," and you want to know what is happening to your money.
Below, we follow a single payment from the moment your wallet builds it to the moment it becomes practically irreversible, and cover what to do when it stalls.
Use the multichain Bitcoin.com Wallet app, trusted by millions to safely and easily send, receive, buy, sell, trade, and manage the most popular cryptocurrencies. You can also connect to thousands of decentralized applications (dApps), from games to financial derivatives.
Key Takeaways
- A Bitcoin transaction is a signed message, not a transfer of physical or digital objects. Ownership is reassigned by updating a public ledger.
- Bitcoin has no account balances. Your wallet holds a collection of discrete chunks of bitcoin called unspent transaction outputs, and every payment consumes whole chunks and creates new ones.
- Fees are priced by data size, not by the amount you send. Moving $50 and $5 million costs the same if the transaction has the same structure.
- The typical wait is ten to sixty minutes for a first confirmation, but block timing is random and cannot be predicted precisely.
- Six confirmations is a convention adopted by exchanges and merchants, not a rule written into the protocol.
- Any unconfirmed transaction can be replaced by a higher-fee version. Since Bitcoin Core 28.0, senders no longer need to flag their transactions as replaceable for this to be possible.
- A stuck transaction is almost never lost. It either confirms eventually, gets replaced, or is dropped from the network's waiting area after about two weeks and the funds become spendable again.
What a Bitcoin Transaction Actually Is
There are no bitcoins in the sense of objects sitting in a container. There is no file on your phone that gets moved. What exists is a shared ledger, the blockchain, recording every transfer that has ever happened, and a set of rules that every participant enforces independently.
Satoshi Nakamoto put it directly in the Bitcoin whitepaper: "We define an electronic coin as a chain of digital signatures." Each owner passes value along by signing over the previous transaction to the next owner's public key. Follow any coin backwards through those signatures and you eventually arrive at the block where it was created by a miner.
So "owning bitcoin" means holding the private key that can produce a valid signature for coins recorded against a particular address. That is the whole of it. The Bitcoin project's own overview describes the blockchain as a shared public ledger that lets wallets calculate spendable balances and lets the network confirm that a sender is authorized to spend what they are spending.
This is why a Bitcoin transaction cannot be edited, cancelled once confirmed, or reversed by customer support. There is no ledger operator to appeal to. There is only the ledger.
The Bitcoin Transaction Process: Five Stages
Every payment follows the same path. The bitcoin transaction steps below are worth internalizing, because when something goes wrong, it goes wrong at an identifiable stage.
| Stage | What happens | Who does it | Typical duration | What can go wrong |
|---|---|---|---|---|
| 1. Construct | Your wallet selects which coins to spend, sets the amounts, and calculates a fee | Your wallet | Instant | Insufficient funds, fee set too low, amount below the dust threshold |
| 2. Sign | Your private key produces a cryptographic signature proving you control the coins | Your wallet, offline | Instant | Wrong key, corrupted backup, hardware wallet not approved |
| 3. Broadcast | The signed transaction is sent to connected nodes, which relay it onwards | Your wallet and the peer-to-peer network | Seconds | Poor connectivity, transaction rejected as non-standard, fee below the minimum relay rate |
| 4. Wait | The transaction sits in the mempool, a queue of valid but unconfirmed transactions | Every node on the network | Ten minutes to several days | Congestion, fee rate too low to be selected, eventual eviction after roughly two weeks |
| 5. Confirm | A miner includes it in a block, and later blocks build on top of it | Miners and nodes | Ten minutes per confirmation on average | Chain reorganization (rare, and usually only affects very recent blocks) |
Stages one and two happen entirely on your device. Nothing has left your phone or laptop at that point, and nothing is at risk. It is only at stage three that the transaction becomes public and, in practice, difficult to take back.
Inputs, Outputs, and Why Your Wallet Sends Money Back to You
This is the part that confuses almost everyone the first time they look at a transaction on a block explorer, so it is worth slowing down.
Bitcoin does not have account balances. Instead, your wallet holds a set of discrete chunks of bitcoin called unspent transaction outputs, usually shortened to UTXOs. Think of them as banknotes rather than a bank balance. You have a 0.6 BTC note and another 0.6 BTC note. You do not have 1.2 BTC in an account.
Notes must be spent whole. If you want to pay someone 1 BTC using two 0.6 BTC notes, you hand over both notes and receive change.
Here is that transaction in full:
| Component | Value | Explanation |
|---|---|---|
| Input 1 | 0.6 BTC | A coin received earlier, now being spent |
| Input 2 | 0.6 BTC | A second coin, also spent in full |
| Total in | 1.2 BTC | Inputs must always be consumed entirely |
| Output 1 | 1.0 BTC | Goes to the recipient's address |
| Output 2 | 0.199 BTC | Change, returned to an address you control |
| Total out | 1.199 BTC | |
| Fee | 0.001 BTC | The difference between inputs and outputs, claimed by the miner |
Notice there is no separate fee field. The fee is simply whatever you do not assign to an output. Miners collect the remainder. This is also why a transaction with a mistakenly enormous fee cannot be undone: the arithmetic is the instruction.
Two things follow from this that surprise people:
- Your own address appears as a recipient - That second output is your change coming back. It is not a duplicate payment and it is not a leak. Most wallets send change to a fresh address you control rather than the one you paid from, which is why the address may look unfamiliar.
- Your wallet balance is the sum of your notes, calculated on the fly - There is no stored balance anywhere. Your wallet scans the ledger for coins locked to keys it holds and adds them up.
Keys and Signatures: How the Network Knows the Coins Are Yours
Every Bitcoin address is derived from a pair of mathematically linked keys.
- The public key produces your address. You share it freely. It works roughly like an email address in that people need it to send you anything.
- The private key authorizes spending. It never leaves your device and it should never be shared with anyone.
A useful way to picture an address is a transparent safe. Anyone can look through the glass and see exactly what is inside, because the ledger is public. Only the holder of the private key can open it.
When you spend, your wallet uses the private key to produce a digital signature over the specific details of that transaction: which coins, which amounts, which destinations. Every node then checks that signature against the public key. If it verifies, the transaction is authentic and unaltered. If a single satoshi of the amount were changed in transit, the signature would fail and the whole transaction would be rejected.
Crucially, the signature proves ownership without revealing the private key. That is the property the entire system rests on.
Since the Taproot upgrade activated in November 2021, Bitcoin also supports Schnorr signatures alongside the original ECDSA scheme. For everyday users the practical effect is smaller transactions, which means lower fees, and better privacy for more complex spending arrangements like multi-signature wallets, which can be made to look identical to ordinary single-signature payments on the ledger.
What Happens the Moment You Press Send
Your wallet hands the signed transaction to a handful of nodes it is connected to. Each of those nodes runs its own independent checks before doing anything else:
- Does the transaction parse correctly and follow the expected format?
- Do the coins being spent actually exist and remain unspent?
- Do the signatures verify against the relevant public keys?
- Is anything here trying to spend a coin already committed elsewhere?
- Does the fee clear the node's minimum relay rate?
- Is the transaction within standard size limits?
Only if all of those pass does the node accept it and forward it to its own peers. Within a few seconds the transaction has propagated across most of the network. This is why no single party can block a Bitcoin payment: there are thousands of independent nodes, and any one of them will relay a valid transaction.
Accepted transactions land in the mempool, short for memory pool. This is the waiting area for valid but unconfirmed transactions. It is worth knowing that there is no single global mempool. Every node keeps its own copy in memory, which is why two different explorers can report slightly different queue sizes at the same moment.
Miners then build candidate blocks by selecting from their mempool, and they select on fee rate. This is where the wait begins.
Fees: You Are Buying Block Space, Not Moving Money
The single most useful thing to understand about Bitcoin fees is that they have nothing to do with how much you are sending.
Fees are priced per unit of data, measured in satoshis per virtual byte, written as sat/vB. A satoshi is one hundred-millionth of a bitcoin. A virtual byte is a unit of transaction size that accounts for the discount SegWit gives to signature data. Your total fee is simply the rate you choose multiplied by the size of your transaction.
Each block is capped at 4,000,000 weight units, which works out to roughly 1.8MB to 2.2MB of real transaction data depending on what kinds of transactions are in it. That cap is fixed, demand for it is not, and the resulting competition is the fee market.
What actually drives your transaction's size:
- The number of inputs: This is the dominant factor. Each additional coin you spend adds roughly 68 to 148 virtual bytes depending on address type. A payment assembled from twenty small amounts received over time is far more expensive to send than one assembled from a single large amount, even if the totals are identical.
- The address type: Older formats are bulkier than newer ones.
- The number of outputs: Minor by comparison, but batching several payments into one transaction is cheaper than sending them separately.
| Address type | Prefix | Relative size | Notes |
|---|---|---|---|
| Legacy (P2PKH) | 1... | Largest | Original format from 2009, still supported |
| Nested SegWit (P2SH) | 3... | Moderate | Compatibility bridge, widely supported |
| Native SegWit (P2WPKH) | bc1q... | Small | Roughly 141 virtual bytes for a standard one-input, two-output payment |
| Taproot (P2TR) | bc1p... | Smallest | Around 111 virtual bytes for the equivalent payment |
So a standard native SegWit payment at 3 sat/vB costs roughly 420 satoshis. At the time of writing that is a fraction of a US dollar, and it is the same fraction whether the transaction carries $50 or $5 million.
Fee conditions as of September 2026 have been unusually calm. Transaction fees accounted for well under one percent of total miner revenue through July and August 2026, with miners collecting around 0.02 to 0.025 BTC per block in fees. The mempool has been clearing within a block or two for long stretches. Bitcoin Core's default minimum relay fee rate now sits at 0.1 sat/vB, ten times lower than the old 1 sat/vB floor, a change that shipped with Bitcoin Core 31.0 in April 2026.
Calm conditions do not last indefinitely. Fee spikes have historically been triggered by sudden demand for block space, and they arrive without warning.
Bitcoin Transaction Confirmation: What "Final" Actually Means
A confirmation means your transaction has been included in a block. Each subsequent block built on top adds another confirmation.
New blocks are found roughly every ten minutes on average. Over the twenty-four hours before this was written, block times were averaging around nine minutes and fifty-six seconds. That average hides enormous variance. Mining is a probabilistic process, so two blocks can appear ninety seconds apart and the next can take fifty minutes. Nobody can tell you precisely when your transaction will confirm, and any service that claims otherwise is estimating.
Here is the part most explanations skip. Bitcoin's finality is probabilistic, not absolute. When two miners find a block at nearly the same moment, the network briefly holds two competing versions of the chain. Whichever side the next block builds on wins, and transactions in the losing block return to the mempool to be confirmed again. This is called a chain reorganization. It is normal, it almost always resolves within one block, and deeper reorganizations are extraordinarily rare because rewriting history requires redoing all the accumulated proof of work.
Each confirmation makes reversal exponentially less likely. That is why the guidance scales with what is at stake:
| Confirmations | Approximate wait | Reasonable for |
|---|---|---|
| 0 (unconfirmed) | Immediate | Nothing where the payment matters. See the next section. |
| 1 | About 10 minutes | Small everyday amounts between parties with some trust |
| 3 | About 30 minutes | Mid-size payments, common exchange deposit threshold |
| 6 | About 60 minutes | Large transfers. The long-standing industry convention. |
Six is a convention, not a protocol rule. Nothing in the Bitcoin software enforces it. It became standard because it offers a comfortable safety margin at a tolerable wait, and exchanges and merchants adopted it independently.
Why Bitcoin Transactions Get Stuck, and How to Unstick Them
A pending transaction is almost always one thing: your fee rate is below what miners are currently accepting, so your transaction keeps getting passed over.
The reassuring part is that your bitcoin is not gone. It is committed but unspent, visible to the network, and it will end up in one of three states.
- It confirms - Congestion clears, fee rates fall, and a miner picks it up. This is the most common outcome.
- It gets replaced - You or your wallet broadcast a higher-fee version that supersedes it.
- It gets dropped - Bitcoin Core nodes evict transactions that have sat unconfirmed for 336 hours, which is fourteen days. Once your transaction has been forgotten by the network, the coins it was spending become spendable again and you can start over.
If you do not want to wait, there are two established techniques:
Replace-by-fee (RBF) rebroadcasts the same payment with a higher fee, replacing the original in the mempool. The replacement must spend at least one of the same coins, must pay more in total fees than the transaction it replaces, and must cover its own relay bandwidth at the node's incremental relay rate, currently 0.1 sat/vB by default. Most modern wallets expose this as a "bump fee" or "speed up" button.
Child-pays-for-parent (CPFP) works from the other direction. You spend one of the stuck transaction's outputs in a new transaction carrying a high fee. Because a child cannot confirm before its parent, a miner wanting the child's fee has to include both. This is the option available to a recipient waiting on an incoming payment, since they control the output but not the original transaction.
There is one thing you cannot do: cancel a transaction outright. You can only replace it with a different transaction spending the same coins, which in practice means sending the funds back to an address you control at a higher fee rate.
Replace-By-Fee and Why Unconfirmed Payments Are Not Safe
This section corrects a claim that is still widely repeated, including on pages that currently rank well for this topic.
Replace-by-fee began as an opt-in mechanism. Under BIP 125, formalized in 2016, a sender had to flag a transaction as replaceable by setting a specific field. If the flag was absent, nodes would refuse to relay a replacement. Merchants leaned on this, treating unflagged unconfirmed transactions as reasonably safe to accept.
That is no longer how the network behaves. Bitcoin Core 28.0, released in October 2024, made full replace-by-fee the default mempool policy. Signaling is no longer required at all, and BIP 125 has since been marked obsolete. The current replacement policy documentation in the Bitcoin Core repository no longer references opt-in signaling as a condition.
The practical consequence is simple and worth stating plainly: any unconfirmed Bitcoin transaction can be replaced by a higher-fee version, regardless of how it was constructed. An unconfirmed payment is a proposal, not a settlement.
The change was arguably a correction rather than a policy shift. Bitcoin's consensus rules always permitted a miner to include whichever conflicting transaction it preferred. The old relay policy created an appearance of safety that miners were never obliged to honor. Making the policy honest about what the protocol actually allows removed a false assurance.
If you accept bitcoin for goods or services, wait for at least one confirmation on anything you cannot afford to lose. If you need instant settlement, that is what payment layers built on top of Bitcoin exist to provide.
What Changed in 2026: Cluster Mempool and Private Broadcast
Bitcoin Core 31.0 was published on April 19, 2026, and carries the most significant change to transaction handling in years. Most of it is invisible to ordinary users, but three parts matter.
The mempool was rebuilt - The new design, called cluster mempool, groups related transactions into connected sets rather than tracking each transaction's ancestors and descendants individually. Clusters are capped at 64 transactions and 101 kB of virtual size. Within a cluster, transactions are ordered by the fee rate at which they are realistically expected to be mined, accounting for the full group that would be included together. The practical benefits are better block templates for miners, more accurate fee estimation for wallets, and more reliable behavior for child-pays-for-parent, since a node can now reason properly about a parent and child as a unit. The cluster mempool proposal write-up covers the reasoning in detail.
Replacement rules got stricter - A replacement is now accepted only if it leaves the mempool's fee rate profile strictly better than before. This closes off cases under the previous rules where a replacement could make the mempool worse for miners. For simple standalone transactions the practical test is unchanged: pay a higher total fee and a higher fee rate than the transaction you are replacing.
Nodes can now broadcast privately - A new option routes transaction broadcast exclusively through Tor or I2P. Two things follow: the nodes receiving your transaction never learn your IP address, and two separate transactions you send are not linkable to each other, because each uses its own connection. For anyone whose threat model includes network-level observation, this is a meaningful addition. It is available to people running their own node, which you can download from the Bitcoin Core project.
Adoption takes time. Nodes upgrade at their own pace, so the network-wide effect of these changes will build over the months following release rather than arriving at once.
How to Read Your Own Transaction on a Block Explorer
Every transaction gets a unique identifier called a transaction ID, or TXID: a 64-character string of letters and numbers. Your wallet will show it. Paste it into a block explorer such as explorer.bitcoin.com and you can watch the whole thing yourself.
Here is what you are looking at:
- Transaction ID (TXID): The unique fingerprint. Share this when asking anyone about the status of a payment. It reveals nothing beyond what is already public.
- Status or confirmations: "Unconfirmed" or "pending" means it is still in the mempool. A number means it is in a block, and that many blocks have been built since.
- Block height: Which block included it. Blank until it confirms.
- Inputs (vin): The coins being spent, with the addresses they came from. More inputs means a bigger, more expensive transaction.
- Outputs (vout): Where the money went. Remember that one of these is usually your own change.
- Fee: Total paid to the miner, in satoshis or BTC.
- Fee rate: The figure that actually determines your wait, in sat/vB. If your transaction is stuck, compare this against current network rates.
- Virtual size (vsize): Transaction size in virtual bytes. Multiply by the fee rate and you get the fee.
- Timestamp: When the transaction was first seen or when its block was mined.
Two habits worth building. First, check the fee rate rather than the total fee when diagnosing a slow transaction, because the total tells you nothing on its own. Second, verify in a wallet or explorer you control rather than trusting a screenshot from a counterparty, which is trivial to fake.
What the Network Can See About Your Transaction
Bitcoin is public by design. Every transaction, amount, and address is permanently visible to anyone.
Addresses are pseudonymous rather than anonymous. They are not labelled with names, but they are stable identifiers, and analysis can link them together. The most common technique assumes that when several coins are spent as inputs to a single transaction, they were probably controlled by the same person. Do that repeatedly and clusters of related addresses emerge.
Some practical implications:
- Reusing an address exposes your history - Anyone you have ever given it to can look up its full balance and every transaction it has been part of. Use a fresh receiving address for each payment. Self-custody wallets generate them on demand at no cost.
- Consolidating many small coins links them together - Sweeping twenty small amounts into one transaction tells observers those twenty coins share an owner.
- Your IP address can leak at broadcast - The transaction itself does not contain it, but the node you first send to can observe where it came from. Running your own node, and using the private broadcast option added in Bitcoin Core 31.0, addresses this directly.
- Very small outputs may not be worth creating - An output so small that spending it would cost more in fees than it is worth is called dust. Wallets generally refuse to create these, which is why there is an effective minimum practical payment size.
Conclusion
A Bitcoin transaction is a signed message that reassigns specific coins to a new owner, verified independently by every node on the network and recorded on a ledger nobody can edit. Understanding inputs, outputs, and change explains most of what looks strange on a block explorer. Understanding that fees buy data space rather than payment volume explains most of what looks strange about cost. Understanding that confirmation is probabilistic explains the waiting.
As of September 2026 the network is running cheaply and clearing quickly, and Bitcoin Core 31.0 has made fee estimation and stuck-transaction handling more reliable than at any previous point. The mechanics described here have been stable since 2009 and the rules apply identically to everyone, which is the point.






