A Bitcoin transaction is an authorized instruction that spends specific earlier transaction outputs and creates new outputs. It moves from the sender’s wallet to the peer-to-peer network, where nodes check it under Bitcoin’s rules. If it is included in a block, it has a confirmation; later blocks add confirmations and increase confidence in its place in the chain, but do not provide an absolute guarantee against reversal.

What a Bitcoin transaction records

Bitcoin transactions use a model based on unspent transaction outputs, often shortened to UTXOs. A transaction input spends a specific output from an earlier transaction, identified by that transaction’s ID and the output’s index. The input must refer to an output that is still unspent and meet its spending conditions, including the required scripts and signatures. Outputs created by the new transaction remain unspent until a later input spends them.

This differs from a simple instruction to subtract money from one account balance and add it to another. The transaction consumes specified outputs and creates new ones. Its data and authorization support a proposed change to Bitcoin’s transaction history; the network’s validation rules determine whether the proposed spend is acceptable.

Digital signatures authorize transfers through a chain of signed ownership records. A signature is part of the authorization process, not the entire payment mechanism: the transaction’s inputs must also satisfy the applicable spending conditions and validation rules.

How blockchain bitcoin transactions move through the network

The sender provides the required transaction data and authorization, then broadcasts the transaction to peers. Broadcast means the sender has submitted it to the network. It does not mean that the transaction is already recorded in a block.

Nodes check a received transaction against Bitcoin’s rules. In the UTXO model, this includes checking that each input refers to an unspent output and satisfies that output’s spending conditions with the required scripts and signatures. This validation is a protocol function. A wallet’s display, a recipient’s decision, or a merchant’s order system is a separate matter.

A transaction may be relayed among peers after it is received. Its broadcast or relay does not itself establish that it has been included in a block. Inclusion happens when the transaction appears in a block that forms part of the chain recognized by the network. The sender’s action starts the process; the network’s validation and block record determine its protocol status.

The lifecycle can be summarized as follows:

  1. The sender provides transaction data and authorization.
  2. The sender broadcasts the transaction to peers.
  3. Nodes check it against applicable Bitcoin rules, including the inputs’ spending conditions.
  4. The transaction may be included in a block.
  5. Later blocks can build on the block containing it, adding confirmations.

The sequence explains the states, not a timetable. The evidence here does not establish that every broadcast transaction will be included or when inclusion will occur. A wallet or service may show a status, but that display is not itself the transaction’s block record.

Broadcast, unconfirmed, and confirmed are different states

These terms describe different stages:

  • Broadcast: The authorized transaction has been submitted to peers.
  • Unconfirmed: It has not yet been included in a block recognized by the network. It may have been broadcast, but submission alone is not inclusion.
  • Confirmed: It has been included in a block. That inclusion is its first confirmation.
  • Additional confirmations: Later blocks added after the transaction’s block increase the confirmation count.

“Confirmed” therefore does not mean “impossible to reverse.” Confirmations indicate increasing confidence in a transaction’s place in the chain, without providing an immediate or absolute guarantee against reversal. The degree of confidence depends on confirmations and operating conditions. These facts do not establish one confirmation count as a universal settlement policy.

What confirmation does—and does not—establish

A confirmation indicates that a transaction was included in a block in the chain being recognized. Subsequent confirmations provide increasing confidence in its place in that chain, but not an absolute guarantee. Anyone relying on transaction status for an operational decision should distinguish the protocol’s block record from the policy used by a wallet, recipient, or merchant to decide whether to act.

A Bitcoin transaction record also does not, by itself, establish that an external payment obligation has been legally discharged, verify the parties’ identities, or resolve disputes and errors. Those matters are not established simply by recording a transaction. A merchant’s or recipient’s acceptance policy is separate from Bitcoin’s transaction-validation and recording process.

Confirmation is about inclusion, not identity. A valid signature supports the conclusion that the transaction was authorized using the relevant key, but it does not by itself identify the human, organization, device, or service controlling that key. A transaction record should not be treated as proof of a particular person’s identity or of an agreement between parties.

How to read a transaction record responsibly

When considering a transaction’s progress, separate three questions: Was it authorized and accepted under the relevant spending conditions? Has it been included in a block? How many later confirmations are reported, and what operating conditions affect confidence in that chain position? These questions concern transaction mechanics and status; they do not answer identity, legal, or merchant-policy questions.

This explanation is limited to Bitcoin’s transaction lifecycle and the meaning of confirmation. It does not cover how to trace addresses, use an explorer, assess transaction privacy, or determine jurisdiction-specific obligations. The useful boundary is simple: a transaction record describes transaction data and its place in the chain. It does not, on its own, establish everything about the people, obligations, or decisions surrounding a payment.

Sources and references