A Bitcoin transaction is a signed data structure that consumes one or more unspent transaction outputs (UTXOs) as inputs, creates new outputs assigning value to recipients and changes back to the sender, and pays the difference as a miner fee. All of this is validated by thousands of independent nodes before a miner includes it in a block.
This guide covers the full lifecycle of a Bitcoin transaction: the UTXO model and why it is not like a bank account, transaction anatomy (inputs, outputs, fees, change), the ownership proof mechanism (keys, signatures, scripts, SegWit witness data), fee calculation in satoshis per virtual byte, the path from broadcast to mempool to confirmed block, what to do when a transaction is stuck, privacy trade-offs built into UTXO structure, and how to read any transaction in a block explorer. It does not cover trading strategy, tax guidance, or Lightning Network payments (those are separate topics).
What is the UTXO model and why does it matter?
Bitcoin does not use account balances. When someone sends you bitcoin, that payment creates a discrete, spendable output locked to your key. That output sits unspent until you consume it in a new transaction. Your wallet balance is the sum of all outputs your key can spend. That sum is not stored anywhere as a single number.
This is the Unspent Transaction Output (UTXO) model. Every bitcoin in existence traces back to one or more UTXOs. When you spend, those UTXOs are consumed entirely and new ones are created.
Why this is different from a bank account: A bank maintains a running tally: one number per customer. Bitcoin has no central record-keeper, so it cannot maintain account balances. Instead, the blockchain records which outputs exist and whether they have been spent. Ownership is proven cryptographically at spend time, not registered at a central authority.
What your wallet balance actually is: If your wallet shows 0.15 BTC, you might hold three separate UTXOs: one for 0.08 BTC, one for 0.05 BTC, one for 0.02 BTC. The wallet sums them for display. None of those three values is a balance; each is a discrete spendable output.
The physical cash analogy: UTXOs resemble cash bills. A 0.05 BTC UTXO is like a specific banknote with that denomination. You cannot spend half a note. If a payment requires less than a UTXO's full value, you hand over the whole UTXO and receive change. Unlike cash, UTXOs carry no fixed denominations and have cryptographic ownership conditions rather than physical identity.
What this analogy misses: Cash has no built-in spending conditions. A UTXO has a locking script, a set of mathematical conditions that must be satisfied to spend it. Typically that condition is: "provide a valid signature from the private key corresponding to this public key." The UTXO model also allows parallel transaction processing since each UTXO is independent; spending one does not affect another.
For a full treatment of the UTXO data structure and how it relates to the blockchain ledger, see our guide on UTXO explained and how it fits within how the Bitcoin blockchain works.
What is inside a Bitcoin transaction?
A bitcoin transaction consumes one or more existing UTXOs (inputs) and creates one or more new UTXOs (outputs), with any leftover value becoming the miner fee.
There are no "coin objects" travelling through a pipe. A transaction is a data structure, a signed message that instructs the network to retire specific old outputs and register specific new ones.
Inputs
Each input references a previous transaction output by its transaction ID (txid) and an index number (vout). It also includes an unlocking proof (typically a digital signature and a public key) demonstrating that you hold the key authorized to spend that output. Inputs are not "from addresses." They point to specific outputs by their location in the transaction graph.
Outputs
Each output specifies an amount in satoshis and a locking script (scriptPubKey) defining what proof is required to spend it. Once a transaction is confirmed, each output becomes a new UTXO, spendable by whoever holds the matching key.
The fee
Bitcoin transactions carry no explicit fee field. The fee is implicit: total input value minus total output value. Whatever satoshis remain unassigned to any output become the miner's fee. A miner collecting a block assembles these implicit fees from every transaction in the block.
Worked example with real numbers
Alice holds one UTXO worth 0.10 BTC (10,000,000 satoshis).
She sends 0.07 BTC (7,000,000 satoshis) to Bob.
Current fee rate: 5 sat/vB. Her transaction is approximately 140 vB (native SegWit, 1-input 2-output).
Fee: 5 × 140 = 700 satoshis.
Change back to Alice: 10,000,000 − 7,000,000 − 700 = 2,999,300 satoshis (0.02999300 BTC).
The network sees: one input consuming Alice's 0.10 BTC UTXO, one output of 0.07 BTC to Bob, one change output of ~0.02999300 BTC back to Alice. The 700-satoshi difference is never assigned to an output; the miner collects it implicitly when building the block.
Change outputs and why they go to a new address
You cannot partially spend a UTXO. The entire UTXO must be consumed, and any excess returns to you as a change output. Most modern wallets generate a fresh address for each change output. This is a deliberate privacy measure: reusing addresses makes it easier for blockchain analysts to cluster your transaction history. Your wallet manages many addresses, all derived from the same seed phrase (see what is a seed phrase); the wallet balance display aggregates them all.
How does ownership proof work? Keys, signatures, scripts, and SegWit witness data
The Bitcoin network verifies your right to spend an output through cryptographic proof. No bank approves the transfer. No identity document is checked. The math either passes or it does not.
Locking scripts (scriptPubKey)
When an output is created, it includes a locking script defining the spending condition. The most common form, P2WPKH (native SegWit), locks the output to a public key hash: "to spend this output, provide the public key that hashes to this value AND a valid signature from the corresponding private key."
Unlocking proof (scriptSig and witness)
When you spend an output, your transaction provides the proof that satisfies the locking condition. For P2WPKH this means:
Your public key (derived from your private key via elliptic curve multiplication)
A digital signature created by your private key signing a hash of the transaction data
Nodes check: does the public key hash to what the locking script specified? Is the signature valid for this public key and this transaction? If both checks pass, the transaction is authorized. Your private key never leaves your wallet. Only the signature, which cannot be reversed to recover the key, is broadcast.
SegWit and the witness section
The Segregated Witness upgrade (SegWit, activated in August 2017) moved signature and public key data into a separate "witness" section of the transaction. This matters for two reasons:
First, it fixed transaction malleability, a bug where signatures could be modified after broadcast, changing the txid without invalidating the transaction. Second, witness data receives a 75% weight discount when calculating transaction size for fee purposes. A transaction paying 5 sat/vB on 140 virtual bytes costs the same as a legacy transaction of 226 bytes at 3.1 sat/vB, despite having more raw bytes. SegWit transactions are therefore meaningfully cheaper in fee terms.
Taproot (P2TR)
The Taproot upgrade (November 2021) introduced Schnorr signatures and the P2TR output type. A basic single-sig Taproot spend is approximately 57.5 vB, the smallest input type available. Taproot also enables advanced spending conditions (multisig, timelocks, hash conditions) that are indistinguishable from simple spends when the cooperative path is taken, improving privacy. For a complete comparison of address formats, see Legacy vs SegWit vs Taproot explained.
How are Bitcoin transaction fees calculated?
Bitcoin fees depend on your transaction's size in virtual bytes (vB) multiplied by the current fee rate (satoshis per virtual byte, sat/vB). The bitcoin amount you send is irrelevant to the fee.
Sending 0.001 BTC can cost the same fee as sending 10 BTC if the transactions have the same structure. Miners care about how much fee they earn per unit of limited block space, not the payment amount.
What is a sat/vB?
Satoshi: the smallest bitcoin unit. 1 BTC = 100,000,000 satoshis.
Virtual byte (vB): a unit of transaction "weight" that accounts for the SegWit witness discount. Non-witness bytes count as 4 weight units; witness bytes count as 1 weight unit. Divide total weight by 4 to get virtual bytes. 4,000,000 weight units = 1,000,000 vB = maximum block capacity.
Fee rate = satoshis paid divided by virtual bytes. Higher fee rate = higher priority.
Typical transaction sizes (single-input, two-output):
Address type | Approximate vB |
|---|---|
Legacy P2PKH | ~226 vB |
Native SegWit P2WPKH | ~140 vB |
Taproot P2TR | ~57.5 vB (keypath spend) |
(Source: bitcoinops.org transaction size calculator, learnmeabitcoin.com)
Current fee environment (May 2026): As of May 6, 2026, the mempool is lightly loaded. The mempool.space API shows fastest confirmation at 3 sat/vB, economy confirmation at 1 sat/vB. During the 2024 Ordinals/Runes surge, rates briefly exceeded 200 sat/vB. The appropriate fee rate depends on the current mempool depth, which changes by the minute.
Why multiple small UTXOs increase fees
Each input your wallet selects adds approximately 68 vB (native SegWit) to the transaction. If your balance consists of 20 small UTXOs and a payment requires combining several, your transaction grows significantly. Consolidating UTXOs during low-fee periods (spending many small UTXOs in one transaction during quiet mempool conditions) saves money on future high-value sends.
When we monitor mempool.space on the Blofin team before publishing fee guidance, we watch both the fee rate histogram and the total mempool size in virtual bytes. A large, dense mempool with transactions clustered above 10 sat/vB means the queue is backed up; a sparse mempool with most transactions below 2 sat/vB means 1-2 sat/vB gets confirmed in the next block.
What happens after you press send? The transaction lifecycle
After broadcast, a bitcoin transaction passes through validation, mempool queuing, miner selection, block inclusion, and confirmation accumulation before it reaches irreversible finality.
Step 1: Wallet constructs and signs
Your wallet selects UTXOs as inputs (using a coin selection algorithm to minimize fees and preserve privacy), builds the output structure, calculates the fee rate based on current mempool conditions, and signs each input with your private key. The signed transaction is now a complete, self-contained data object.
Step 2: Broadcast to the peer-to-peer network
Your wallet sends the signed transaction to one or more Bitcoin nodes it is connected to. Within seconds, the transaction propagates to thousands of nodes globally via the peer-to-peer gossip protocol. The transaction has no official "sender" on the network; it simply exists and spreads.
Step 3: Node validation
Each receiving node independently verifies:
All input signatures are cryptographically valid
All referenced inputs are in the node's UTXO set (unspent)
Total output value does not exceed total input value
The transaction format is well-formed and follows consensus rules
The fee rate meets the node's minimum relay threshold (default: 1 sat/vB)
Invalid transactions are rejected and not relayed. Valid transactions enter the node's mempool. For the roles of nodes in validation, see Bitcoin nodes vs miners vs wallets.
Step 4: Mempool waiting
The mempool is each node's local queue of valid, unconfirmed transactions. It is not the blockchain. A transaction in the mempool is valid but not final. Nodes can drop low-fee transactions during extreme congestion to manage memory. The transaction sits here until a miner includes it in a block. Full mempool dynamics are covered in the Bitcoin mempool.
Step 5: Miner selection
Miners build candidate blocks by sorting mempool transactions by fee rate (highest to lowest) and filling up to the 4,000,000 weight unit block limit. A transaction at 1 sat/vB may wait many blocks if the mempool contains hundreds of megabytes of higher-fee transactions. During quiet periods, even 1 sat/vB transactions confirm in the next block. The competitive ordering is governed by proof of work and the 10-minute average block interval.
Step 6: Block inclusion (1 confirmation)
When a miner finds a valid block (solving the proof of work puzzle), they broadcast it. Full nodes verify the block and every transaction inside it. If valid, the block extends the chain. Your transaction now has 1 confirmation. From an exchange operator's perspective, this is the moment a deposit transitions from "detected" to "pending credit," though most platforms wait for additional confirmations before making the balance tradeable.
Step 7: Confirmation accumulation
Each subsequent block adds another confirmation. The double-spend risk drops exponentially with each block buried above your transaction:
0 confirmations: unconfirmed; technically replaceable or droppable
1 confirmation: low risk for small amounts; high-hashrate reversal theoretically possible but expensive
3 confirmations: exchange standard for deposits
6 confirmations: traditional threshold for high-value transfers; practical reversal cost exceeds billions of dollars at current hashrate
144+ confirmations (~1 day): institutional-grade finality
The confirmation model and why different services require different depths is covered in detail in Bitcoin confirmations explained.
What happens when a transaction gets stuck?
A transaction stuck in the mempool means your fee rate was too low for miners to include it given current mempool competition. Two tools exist to rescue stuck transactions: Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP).
Why transactions get stuck
If you broadcast at 2 sat/vB and the mempool fills with transactions at 10+ sat/vB, miners skip yours. During the Ordinals/Runes inscription events in 2024, rates regularly exceeded 200 sat/vB, stranding thousands of low-fee transactions for hours or days.
Replace-By-Fee (RBF)
RBF allows you to broadcast a replacement transaction using the same inputs but with a higher fee rate. The network accepts the replacement because the original transaction had the opt-in RBF flag set (a sequence number below 0xFFFFFFFE). Most modern wallets set this flag by default. The replacement transaction must increase the fee by at least 1 sat/vB above the previous version and must also cover the original transaction's bandwidth cost.
When to use RBF:
You sent the original transaction and your wallet supports fee bumping
The transaction is still unconfirmed (in the mempool, not yet in a block)
You are willing to pay the higher fee
Child-Pays-For-Parent (CPFP)
If you cannot use RBF (perhaps you are the recipient, or the transaction was not flagged as replaceable), you can create a new transaction (the "child") that spends an output from the stuck transaction (the "parent"). Set the child's fee high enough that the combined fee rate of parent plus child exceeds what miners would accept. Miners evaluating the child transaction see that it cannot confirm without the parent, so they include both.
CPFP works for:
Recipients who want to accelerate incoming funds
Senders who control a change output in the stuck transaction
Decision guide:
Can you RBF (you sent it, RBF-flagged, unconfirmed)? Use fee bump in your wallet.
Do you control any output in the stuck transaction? Create a high-fee child to CPFP.
Neither? Wait for the mempool to clear. During low-demand periods (typically weekends and overnight UTC), fees drop and stuck transactions often confirm. Alternatively, some services offer transaction acceleration for a fee.
Full tactical guidance on each method is in RBF vs CPFP explained and what to do with a stuck transaction.
What does your transaction reveal? Privacy and the UTXO ledger
Bitcoin is pseudonymous, not anonymous. Every transaction is permanently visible on the public blockchain. The UTXO model creates specific, predictable privacy trade-offs.
The public ledger problem
Anyone can observe every transaction ever made: input amounts, output amounts, and the addresses involved. Addresses are not names, but they are fixed identifiers. Once an address is linked to a real-world identity (through exchange KYC, a public payment request, or any other leak), every transaction involving that address becomes attributable.
How UTXO merging reveals relationships
When a transaction uses multiple inputs, analysts apply the "common-input ownership heuristic": all inputs to a transaction likely belong to the same wallet. If you spend five UTXOs from five separately received payments in one transaction, you have cryptographically confirmed to any observer that one entity controls all five.
Change output identification
Analysts use heuristics to identify which output is changed (returned to the sender):
The non-round amount is more often change; the round number more often payment
The output returning to a fresh address in the same wallet
Output ordering and address type mismatches provide additional signals
These are heuristics, not certainties. But combined with other data, they are effective.
Address reuse
Reusing a bitcoin address collapses privacy catastrophically. Every payment to a reused address is provably linked to the same entity. Never reuse addresses. Modern wallets generate new addresses automatically for this reason. Address reuse also has security implications in certain Taproot edge cases.
Privacy-preserving practices
Use a wallet that generates fresh addresses for every transaction and every change output
Avoid combining UTXOs from unrelated sources in a single transaction when privacy matters
Use native SegWit or Taproot addresses (better fee efficiency; Taproot also improves privacy in complex transactions)
Understand that Bitcoin privacy requires deliberate planning, not just using the network
Bitcoin's full pseudonymity, chain analysis techniques, and privacy tools are covered in the academy's article on Bitcoin public key vs private key security.
UTXO model vs account model: Why Bitcoin works differently than Ethereum
Bitcoin tracks discrete unspent outputs. Ethereum and similar blockchains maintain stateful account balances. Both approaches work but optimize for different goals.
Bitcoin's UTXO model:
Validates each input independently; transactions can be processed in parallel
No central "account state" to update; the UTXO set is the state
Change addresses provide natural address rotation, which aids privacy
Requires wallets to manage UTXO selection and change construction
Fee calculation depends on the number and type of inputs chosen
Prevents double-spending by checking that each referenced UTXO is in the current UTXO set
Ethereum-style account model:
Maintains a balance per address in a global state tree
Simpler to understand for users familiar with bank accounts
Sequential updates per account; fewer natural parallelism opportunities
More intuitive for smart contract patterns that read from a running balance
Requires explicit nonce management to order transactions from the same address
Bitcoin's choice was deliberate. Satoshi Nakamoto's UTXO model allows any node to validate any transaction without knowing the global account state. You only need the referenced UTXOs and the current UTXO set, not the full transaction history of each address. This design supports trustless verification by independent nodes with practical hardware.
For broader context on how Bitcoin differs from other cryptocurrencies and blockchain platforms, see Bitcoin vs crypto vs blockchain explained.
How to read a transaction in a block explorer
A block explorer like Mempool.space, Blockstream.info, or Blockchair translates raw blockchain data into a readable interface. Knowing what each field means lets you verify any transaction independently.
Step-by-step guide:
1. Find the transaction by txid
The transaction ID (txid) is a 64-character hexadecimal string, the SHA-256d hash of the transaction data (excluding witness data). Every transaction has a unique txid. Paste it into the explorer search bar.
2. Read the inputs section
Each input shows: the previous txid being spent, the output index (vout), and the address that controlled that output. Count the inputs. Many inputs = many UTXOs being consumed = a larger, higher-fee transaction.
3. Read the outputs section
Each output shows an address and amount. Identify the payment amount (often the round number) and the likely change output (often the non-round number returning to a new address). The explorer may label outputs as "OP_RETURN" for data-carrying outputs that carry no spendable value.
4. Calculate the fee
Sum all input values. Sum all output values. The difference is the fee. Divide by the transaction size in virtual bytes for the fee rate. A transaction with 10,000,000 satoshis in inputs, 9,999,300 satoshis in outputs, and 141 vB transaction size paid a fee of 700 satoshis at approximately 5 sat/vB.
5. Check confirmation status
The explorer shows whether the transaction is unconfirmed (mempool) or how many blocks deep it is. A transaction confirmed in block 895,000 that is currently at block 895,020 has 21 confirmations.
6. Read address types
Legacy: starts with "1" (P2PKH) or "3" (P2SH)
Native SegWit: starts with "bc1q" (P2WPKH or P2WSH)
Taproot: starts with "bc1p" (P2TR)
The address types visible in inputs tell you the format of the UTXOs being spent. A full tutorial on using explorers for verification is in how to use a Bitcoin block explorer.
Frequently asked questions
What is the difference between a transaction ID (txid) and a block hash?
A txid is the SHA-256d hash of a single transaction's data (excluding witness for legacy txid, including it for wtxid). A block hash is the SHA-256d hash of the 80-byte block header. Every transaction has a txid; every block has a block hash. Block explorers use txids to look up individual transactions and block hashes or heights to look up blocks. The two identifiers come from different data structures and should not be confused.
Can a Bitcoin transaction be reversed once confirmed?
No. Once a transaction has even one confirmation, reversing it requires a miner with majority hashrate to rebuild that block and every subsequent block faster than the rest of the network, a 51% attack scenario. After 6 confirmations at current hashrate (~963 exahashes per second as of May 2026), the computational cost of reversal is measured in billions of dollars. In practice, confirmed transactions are final. Unconfirmed (0-confirmation) transactions can theoretically be replaced via RBF, but once a block includes the transaction, reversal is economically irrational.
Why do some wallets show a "pending" transaction for a long time?
A pending transaction is sitting in the mempool waiting for a miner to include it. Common reasons for extended waiting: the fee rate you set is lower than the current competitive threshold; the mempool is congested; or the transaction was broadcast during a high-demand period (inscription surges, post-halving speculation spikes). Use your wallet's fee-bump (RBF) feature or CPFP if you control an output. If neither is available, wait for off-peak hours when mempool pressure typically drops.
What is a "dust" UTXO and why is it a problem?
A dust UTXO is one whose value is smaller than the fee required to spend it. Bitcoin Core's default dust threshold is 546 satoshis for P2PKH and 294 satoshis for P2WPKH. Wallets typically accumulate dust through split change outputs, micropayments, or airdrop-style transactions. Dust costs more to spend than it is worth, effectively freezing those satoshis until fee rates drop or UTXO consolidation becomes economical. Some wallets let you mark dust UTXOs as "do not spend" to avoid them being inadvertently merged with larger UTXOs.
How does a multisig transaction work compared to a standard transaction?
A multisig transaction requires signatures from multiple private keys to authorize spending, rather than just one. A 2-of-3 multisig output requires any two of three designated keys to sign. The UTXO structure is the same (inputs and outputs), but the locking script specifies multiple keys and a threshold. Taproot's key aggregation (MuSig2) allows multisig participants to produce a single Schnorr signature that looks identical to a single-sig Taproot spend, reducing transaction size and improving privacy compared to legacy P2MS multisig.
Does sending bitcoin to an exchange work the same way as sending to a personal wallet?
Mechanically yes. Your transaction creates an output locked to an address provided by the exchange. The exchange's infrastructure monitors that address and, after their required confirmation count (typically 3 confirmations for most exchanges), credits the deposit to your exchange account. The difference is what happens next: you no longer hold the private key for that bitcoin; the exchange does. You have an exchange IOU, not direct UTXO ownership. For the custody implications, see what Bitcoin is and our guide to Bitcoin nodes vs miners vs wallets.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. All facts independently verified.
Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.