Bitcoin transactions and confirmations: a beginner’s guide

Overview: what this guide covers

Qué cubre esta guía

This guide explains how to read a Bitcoin transaction and how confirmations work so you can answer questions like: Where is my txid? How did my wallet compute the fee? What is a UTXO and what is a change output? How many confirmations do I need, and why can settlement time vary?

All operational statements in this guide are drawn from Bitcoin.org and the Bitcoin Developer Guide (Transactions and Block Chain) and present canonical behavior of the Bitcoin protocol. Dynamic items such as current fee prices, guarantees of finality, or custody instructions that depend on your provider are intentionally excluded.

• Definition and structure of a Bitcoin transaction
• Inputs, outputs and UTXOs; how wallets compute balance
• What a txid and vout are and where to find them
• How fees are calculated from inputs minus outputs
• Mempool, block inclusion, confirmation depth and forks
• Practical worked example with hypothetical values
• Tools to inspect transactions and a comparison table of mechanisms
• Common FAQs about unconfirmed transactions and change outputs

What a Bitcoin transaction is (basic definition)

A Bitcoin transaction is a data structure that moves value by consuming previously unspent outputs and creating new outputs. Each transaction contains one or more inputs and one or more outputs. Inputs reference earlier outputs and prove the right to spend them; outputs designate new owners by including a script that will be required to spend that output in the future.

The Bitcoin Developer Guide calls the outputs that are currently spendable UTXOs (Unspent Transaction Outputs). A wallet’s displayed balance is the sum of the UTXOs it controls, not an abstract account balance.

Inputs, outputs and UTXOs: how value moves

Inputs: each input specifies the txid and output index (vout) of a previous transaction output being spent, and provides unlocking data (signature and public key or redeem script) that satisfies the previous output’s locking script.

Outputs: each output includes a value (in satoshis) and a script (scriptPubKey) that describes how the funds may be spent. Common output types include Pay‑to‑PubKey‑Hash (P2PKH) and Pay‑to‑Script‑Hash (P2SH).

UTXOs: when a transaction is confirmed in a block, its outputs become UTXOs until some later transaction spends them. Wallets track which UTXOs belong to keys or addresses they control; the spendable balance equals the sum of controlled UTXOs.

• An input must reference a specific previous txid and vout.
• Outputs become UTXOs after block inclusion.
• Wallets calculate balance by summing UTXOs they control.

Transaction identifier (txid) and output index (vout)

A transaction identifier (txid) is the hash of the raw signed transaction. It uniquely identifies the transaction as seen on the network and in blocks. When an input spends a previous output it references the previous transaction’s txid and the output’s index (vout) within that transaction.

To find the txid of a transaction you sent, use your wallet’s transaction details screen or a block explorer and look for the hex string labeled txid or transaction hash. The txid applies to the whole transaction; specific outputs are referenced by the pair (txid, vout).

• txid = hash of the signed transaction data
• vout = zero‑based index of an output inside the transaction
• spending reference = (txid, vout)

Signatures and script evaluation (how spending is authorized)

Spending an output requires satisfying the previous output’s locking script (scriptPubKey). The spending input provides data (scriptSig or witness) that, when combined with the previous script, evaluates to true under the Bitcoin scripting rules.

In the common P2PKH case the output stores a hash of the recipient’s public key; the input provides the public key and a signature. Nodes validate the combination by checking the signature against the public key and that the public key hashes to the stored value. For P2SH the output stores a hash of a redeem script; the spender supplies the redeem script and fulfilling data so nodes can confirm the hash matches and then evaluate the redeem script.

• Nodes run the input’s script and then the output’s script as a small stack program; success means the input can spend the output.
• Common script types are P2PKH and P2SH; newer types use SegWit witness data but follow the same principle of script evaluation.

How transaction fees are calculated (input–output difference)

Bitcoin transaction fees are implicit rather than an explicit field: the fee equals the sum of input values minus the sum of output values. The miner who includes the transaction in a block may claim that difference as a fee reward.

Example (hypothetical): if inputs total 150,000 satoshis and outputs total 149,200 satoshis, the fee is 800 satoshis (150,000 − 149,200 = 800). This is a hypothetical arithmetic example used only to show the calculation; it does not imply any current fee recommendation.

• Fee = sum(inputs) − sum(outputs)
• Outputs cannot exceed inputs: that would imply a negative fee and make the transaction invalid.
• Wallets usually compute a fee target based on size (vbytes) and desired confirmation speed and set outputs accordingly

Mempool, relay policies and why some transactions remain unconfirmed

When you broadcast a valid transaction it is propagated to peers and stored in nodes’ mempools awaiting inclusion in a block. Nodes enforce policy rules (standardness and minimum relay fee) before relaying transactions; non‑standard or policy‑violating transactions may be rejected or not relayed widely.

A transaction can remain unconfirmed because miners have not yet included it, because its fee is low compared to competing transactions, or because it violates local relay policies. Wallets typically create standard transactions to maximize relay and mining chances.

• Mempool hold = waiting for miner inclusion
• Local relay policies vary by node and can affect propagation
• Low‑fee transactions may be dropped from mempools if space is needed

Confirmations and confirmation depth: what each confirmation means

A confirmation is block inclusion. A transaction included in a mined block has one confirmation. Each additional block added on top of that block increases the transaction’s confirmation depth by one. Confirmation depth is the commonly used measure of settlement progress.

The Bitcoin Developer Guide explains that blocks are chained by headers and a block stores a merkle root of its transactions. Because of proof‑of‑work, altering a transaction in a past block requires redoing work for that block and all following blocks, making deep reversals increasingly costly.

• 0 confirmations = transaction not included in the current best chain (may be in mempool or not relayed)
• 1 confirmation = included in current best block
• n confirmations = included and n−1 blocks follow it in the best chain

Forks, chain reorganization and settlement risk

Competing blocks can be mined at similar times, creating temporary forks. Nodes adopt the chain with more cumulative proof‑of‑work; blocks on shorter forks become stale (or orphaned) when the network converges on the longer chain. Because of this, even a transaction with one confirmation can be reverted if a reorganized chain excludes the block that contained it.

Increasing the number of confirmations raises the computational work required to reverse the transaction; that makes reversals progressively less likely. The Developer Guide emphasizes that finality is probabilistic and depends on the cost of redoing work and the distribution of hash rate — it is not an absolute guarantee.

• Temporary forks can cause 1‑confirmation transactions to be reversed if a longer competing chain appears
• Each additional confirmation increases the computational cost for an attacker to reverse the tx
• Always treat finality as probabilistic rather than absolute

Change outputs and when they become spendable

Typical wallets create a change output sending leftover value back to an address the wallet controls. That change output becomes a UTXO and is spendable once the transaction creating it is included in a block (or available in the mempool if using unconfirmed spends, which wallet behavior varies on).

Spendability depends on the wallet’s policy: some wallets allow spending change outputs from unconfirmed parent transactions (creating chained unconfirmed transactions), while others require confirmations first. For coinbase (miner reward) outputs there is an enforced 100‑block maturity rule before they can be spent, per the Bitcoin protocol.

• Change becomes a UTXO when its creating transaction is in the best chain
• Wallets differ on allowing unconfirmed‑to‑unconfirmed spends
• Coinbase outputs require 100 confirmations (maturity blocks) before spending

How wallets compute balances and present fees

Wallet software usually represents three figures: total balance (sum of UTXOs), available or spendable balance (UTXOs that meet wallet policy for spending), and pending or unconfirmed balance (UTXOs from transactions in the mempool or recent blocks).

To present a fee value, wallets sum the input values used by the outgoing transaction and subtract the sum of outputs; the difference is displayed as the fee. Wallets commonly estimate a target fee rate and choose inputs/outputs to produce the desired fee given transaction size in virtual bytes.

• Displayed balance = sum of UTXOs the wallet believes it controls
• Spendable balance depends on confirmations and wallet policy
• Fee shown = sum(inputs) − sum(outputs) for the created transaction

Reading a transaction: a step‑by‑step worked example (hypothetical)

Step‑by‑step inspection

Below is a hypothetical, mathematically consistent example to show how to inspect a transaction and compute key values. The numbers are illustrative only.

Suppose a wallet spends two UTXOs it controls: UTXO A = 90,000 satoshis, UTXO B = 60,000 satoshis. The wallet builds a transaction with two outputs: recipient output = 120,000 satoshis, change output = 29,200 satoshis. Compute the fee and what each field represents.

• 1) Inputs: check the transaction inputs; each input lists (txid, vout) pointing to UTXO A and UTXO B and includes scriptSig or witness data proving spend rights.
• 2) Outputs: note output 0 = recipient 120,000 satoshis, output 1 = change 29,200 satoshis. The index number (vout) identifies each output when later referenced.
• 3) Fee calculation (hypothetical): sum(inputs) = 90,000 + 60,000 = 150,000 satoshis; sum(outputs) = 120,000 + 29,200 = 149,200 satoshis; fee = 150,000 − 149,200 = 800 satoshis.
• 4) txid: the transaction’s txid is the hash of the signed transaction; use your wallet or an explorer to find the txid and then search for the txid to see mempool status or block inclusion.
• 5) Confirmation check: if the transaction appears in a block, it has 1 confirmation; if additional blocks follow, confirmation depth increases accordingly.

Tools and steps to inspect a transaction yourself

To inspect a transaction’s details and confirmation status: open your wallet and locate the transaction details (your wallet typically shows txid, amounts, inputs/outputs and confirmations). If you need more detail, copy the txid and use a block explorer to view raw inputs, outputs, size and confirmation history.

When inspecting, check these items: txid, vout indexes, inputs’ referenced txids, output values and script types, the computed fee (inputs − outputs), mempool status if unconfirmed, and block height if confirmed. Remember that explorers and wallets may label things slightly differently but the underlying fields follow the protocol definitions in the Developer Guide.

• Use your wallet transaction details first
• For raw view use a block explorer and search by txid
• Confirm fee by summing inputs and outputs
• Check confirmation depth and block height when confirmed

Comparison of mechanisms and their limitations

Below is a compact comparison of mechanisms commonly discussed when reading transactions and assessing settlement. This table highlights purpose and practical limitations without assigning absolute security ratings.

Frequently asked questions

Q: How do I find the txid of a transaction I sent? A: Open your wallet’s transaction details; wallets normally display the txid (transaction hash). If your wallet does not show it, use the raw transaction export or a block explorer and search by address and timestamp to locate it.

Q: How does my wallet compute the fee I paid? A: The wallet sums the input values selected for the outgoing transaction and subtracts the sum of the outputs; the difference is the fee. The wallet chooses inputs and output amounts to reach a target fee rate based on size (vbytes) and your chosen confirmation preference.

Q: Why is my transaction unconfirmed in the mempool? A: Common reasons are low fee relative to current miner demand, local relay policy suppression if the transaction is non‑standard, or it simply has not yet been selected by a miner. Wallets typically create standard transactions to avoid relay issues.

Q: What does 0/1/6 confirmations mean for settlement risk? A: 0 means not in the best chain; 1 means included in a block and is vulnerable to short reorganizations; additional confirmations reduce the probability of reversal because redoing work becomes costlier. The exact number you require depends on your risk tolerance and context; the protocol provides probabilistic, not absolute, finality.

Q: When will my change output be spendable? A: The change output becomes a UTXO when the creating transaction is in the best chain. Wallet behavior varies: some will allow spending change from unconfirmed parents, others wait for confirmation. Note coinbase outputs require 100 blocks before spending.

Q: What makes a transaction non‑standard? A: Non‑standardness is a local policy applied by nodes to decide whether to relay a transaction; it can include unusual script forms, noncanonical encodings, or other deviations. Non‑standard transactions may not be widely propagated and thus have difficulty getting mined.

Conclusion and practical takeaways

Reading a Bitcoin transaction means inspecting inputs, outputs and the txid; computing the fee is a simple subtraction of outputs from inputs; UTXOs are the primitive units wallets track; confirmations reflect inclusion and depth in the block chain and increase settlement confidence but do not give absolute guarantees.

When a transaction is unconfirmed check the mempool status, the fee relative to your desired speed, and whether the transaction is standard. To inspect details use your wallet first and a block explorer for raw fields. Remember the Bitcoin Developer Guide and Bitcoin.org are the canonical protocol references for these behaviors.

• Always check txid and inputs/outputs to verify what was broadcast
• Compute fee as sum(inputs) − sum(outputs) to confirm what miners may claim
• Treat confirmation depth as probabilistic protection rather than absolute finality
• Wallet policies and node relay rules affect when and how a tx propagates and becomes spendable