TL;DR: A Bitcoin transaction is a cryptographically signed message that transfers bitcoin from one set of unspent outputs (UTXOs) to another. Your wallet constructs the transaction, your private key signs it, and the signed transaction propagates across the network through connected nodes until a miner includes it in a block. Each additional block mined on top of that block makes the transaction exponentially harder to reverse.
Bitcoin transaction: A signed data structure that consumes one or more existing unspent transaction outputs (UTXOs) and creates new ones. The signature proves the sender controls the private key associated with each input, the network validates that the inputs exist and haven't already been spent, and miners include the transaction in a block to finalize it. Transactions are the fundamental unit of value transfer on the Bitcoin network.What Is a Bitcoin Transaction?
Every time bitcoin moves from one owner to another, a transaction records that transfer. But a Bitcoin transaction is not an account balance update. There are no accounts. There is no central ledger that tracks how much bitcoin belongs to which user. Instead, Bitcoin uses a system of individual outputs, each locked by a specific cryptographic condition, that can only be unlocked (spent) by whoever holds the right key.
A transaction is a message broadcast to the entire Bitcoin network that says: "Here are the outputs I'm spending. Here is the proof that I'm authorized to spend them. And here are the new outputs I'm creating for the recipients". The network verifies every piece of that message before accepting it.
The UTXO model gives Bitcoin several properties that account-based systems lack. Every transaction is independently verifiable: any node can confirm that the inputs exist, the signatures are valid, and no bitcoin is being created or double-spent. No trust in any third party is required.
A bank transfer requires the bank to update its internal database. A Bitcoin transaction requires cryptographic proof, verified by thousands of independent nodes, recorded permanently in a shared data structure that anyone can audit.
Transaction Components
A Bitcoin transaction is a structured data object with a few core components. Each one has a specific role in the system.
Inputs
Every transaction input is a reference to a previous transaction's output that the sender is spending. It contains three pieces of information:
- Transaction ID (txid): The hash of the previous transaction that created the output being spent.
- Output index (vout): Which specific output from that previous transaction is being consumed. A single transaction can have multiple outputs; the index identifies the exact one.
- Unlocking script (scriptSig or witness): The cryptographic proof, typically a digital signature and a public key, that satisfies the spending conditions set by the previous output.
Think of an input as a receipt plus a key. The receipt says "here's where my bitcoin came from" and the key proves "I'm authorized to spend it". A transaction can have any number of inputs. If you're paying someone 0.5 bitcoin and your wallet holds three UTXOs of 0.2, 0.15, and 0.2 bitcoin, the transaction will consume all three as inputs, totaling 0.55 bitcoin.
Outputs
Transaction outputs define where the bitcoin goes. Each output contains:
- Amount: The value in satoshis (the smallest unit of bitcoin; one bitcoin equals 100,000,000 sats).
- Locking script (scriptPubKey): A set of conditions that must be met to spend this output in the future. For a standard transaction, this condition is: "provide a valid signature from the private key corresponding to this public key hash".
In the example above, 0.55 bitcoin went in through three inputs. The transaction would create two outputs: 0.5 bitcoin to the recipient's address, and the remainder (minus the transaction fee) back to the sender as change. That change output is a new UTXO controlled by the sender's wallet.
UTXOs: The Building Blocks
The UTXO model (Unspent Transaction Output model) is the accounting system that makes Bitcoin work. Every piece of bitcoin in existence is held in a UTXO. Your wallet balance is not a number stored somewhere; it is the sum of all UTXOs that your private keys can unlock.
When a transaction is confirmed, its inputs destroy existing UTXOs and its outputs create new ones. A UTXO can only be spent once, in its entirety. If you have a UTXO worth one bitcoin and want to send 0.3 bitcoin to someone, you must spend the whole UTXO and create two new outputs: 0.3 bitcoin to the recipient and 0.7 bitcoin (minus fees) back to yourself.
The global UTXO set, the collection of all currently unspent outputs across the entire Bitcoin network, is what every full node tracks. As of early 2026, the UTXO set contains roughly 170 million individual outputs. When a new transaction arrives, nodes check it against this set: do the referenced UTXOs exist and are they unspent? This is the core mechanism that prevents double-spending.
UTXO management matters for fees. A wallet with many small UTXOs will need more inputs to construct a transaction, which means a larger transaction size, which means a higher fee. Consolidating UTXOs during periods of low fees is a common optimization.
Script: Bitcoin's Transaction Language
Bitcoin transactions are programmable. Each output contains a small program written in Bitcoin Script, a stack-based language with a deliberately limited set of operations called opcodes. The locking script sets the spending conditions; the unlocking script provides the data to satisfy them.
The most familiar script type, and the classic teaching example, is Pay-to-Public-Key-Hash (P2PKH): "to spend this output, provide a public key that hashes to this value and a valid signature from the corresponding private key". But Script supports more complex conditions:
- Multisig: Require signatures from two of three keys (or any m-of-n combination).
- Timelocks: Prevent spending until a specific block height or timestamp.
- Hash locks: Require revealing the preimage of a specific hash (used in Lightning payment channels and atomic swaps).
Script is intentionally limited. It is not Turing-complete, meaning it cannot loop or run indefinitely. Every Bitcoin node must execute every script, so the language is deliberately constrained to operations that are fast, deterministic, and safe to verify. The trade-off is reduced expressiveness in exchange for predictable execution and security. The full set of available opcodes is defined in Bitcoin Core's script/script.h, with each opcode assigned a specific byte value (e.g., OP_CHECKSIG = 0xac, OP_HASH160 = 0xa9).
Modern Bitcoin transactions typically use Pay-to-Witness-Public-Key-Hash (P2WPKH, defined in BIP 141) or Pay-to-Taproot (P2TR, defined in BIP 341) output types, introduced by the Segregated Witness (SegWit) and Taproot upgrades respectively. These newer formats are more space-efficient and offer better privacy properties, but the underlying concept remains the same: a locking script that defines conditions, and an unlocking script that satisfies them.
How Transactions Are Signed
Creating a Bitcoin transaction is a two-step process: constructing the transaction data and signing it. These steps can happen on the same device or on separate devices for security.
Transaction Construction
Your wallet software handles transaction construction. It selects which UTXOs to use as inputs (coin selection), creates the outputs (destination address and amount, plus a change output if needed), and calculates the appropriate fee based on current network conditions. The result is an unsigned transaction: a complete data structure that specifies what bitcoin is being spent and where it's going, but with no proof of authorization yet.
The Signing Process
Signing is where the private key comes in. The wallet takes the unsigned transaction data, runs it through the Elliptic Curve Digital Signature Algorithm (ECDSA, or Schnorr for Taproot transactions), and produces a digital signature using the private key associated with each input's UTXO.
This signature has two properties:
- It proves authorization. Only the holder of the private key could have produced this specific signature for this specific transaction.
- It is bound to the transaction data. If anyone changes even a single byte of the transaction after signing, the signature becomes invalid. This prevents tampering.
Anyone on the network can verify the signature using the corresponding public key, but no one can work backwards from the signature to derive the private key.
Signing With a Hardware Wallet
In a standard software wallet, the private key exists in memory on an internet-connected device. This is convenient but creates a risk: malware, keyloggers, or compromised operating systems could extract the key.
A hardware wallet solves this by keeping the private key on a separate, dedicated device. The workflow changes slightly:
- The wallet software constructs the unsigned transaction on the computer or phone.
- The unsigned transaction is transferred to the hardware wallet (via USB, Bluetooth, or QR code).
- The hardware wallet displays the transaction details on its own screen for the user to verify.
- The user confirms, and the hardware wallet signs the transaction internally.
- The signed transaction is sent back to the wallet software, which broadcasts it.
The private key never leaves the hardware device. A hardware wallet like the Jade Plus handles the signing step on a dedicated device with air-gapped QR code communication, so the private key never touches an internet-connected computer. The Jade Plus uses its camera and screen to exchange transaction data through QR codes, eliminating the need for USB or Bluetooth connections during the signing process.
Under the Hood: Transaction Serialization
Before a transaction can be signed or broadcast, it must be serialized into a precise byte sequence. The serialization format (defined in Bitcoin Core's primitives/transaction.h) follows a strict structure: a 4-byte version field, a variable-length count of inputs, each input's data (32-byte txid, 4-byte vout, scriptSig, and 4-byte nSequence), a variable-length count of outputs, each output's data (8-byte value in satoshis and scriptPubKey), and a 4-byte locktime field.
For SegWit transactions (BIP 144), the serialization includes a marker byte (0x00) and a flag byte (0x01) after the version, followed by witness data appended after the outputs. This separation is what gives witness data its weight discount: the transaction ID (txid) is computed from the non-witness serialization, while the witness transaction ID (wtxid) covers the full serialized form including witness data.
The transaction's size in virtual bytes (vBytes) determines its fee cost. Virtual size is calculated as: (weight units) / 4, where weight = (non-witness bytes * 4) + witness bytes. A typical single-input, two-output P2WPKH transaction weighs about 561 weight units, or roughly 141 vBytes. Understanding this serialization structure explains why different transaction types have different fee profiles: the ratio of witness to non-witness data determines the effective discount.
Broadcasting a Transaction
A signed transaction is just a blob of data until it reaches the Bitcoin network. Broadcasting is the process of getting that data to the rest of the world.
Connecting to the Network
Your wallet connects to one or more Bitcoin nodes, either directly (if you run your own node) or through the wallet provider's node infrastructure. When you hit "send", the wallet transmits the raw signed transaction to these connected nodes.
Node Validation
Every node that receives a transaction runs it through a series of validation checks before relaying it further:
| Validation Check | What the Node Verifies | Failure Result |
|---|---|---|
| Structural validity | Transaction is properly formatted; data fields within expected size limits | Rejected immediately |
| Input existence | Referenced UTXOs exist in the current UTXO set | Rejected (missing inputs) |
| No double-spending | UTXOs have not been spent by another confirmed or pending transaction | Rejected (double-spend attempt) |
| Signature verification | Each input's unlocking script satisfies the corresponding UTXO's locking script | Rejected (invalid signature) |
| Value conservation | Total input value ≥ total output value (difference = miner fee) | Rejected (value mismatch) |
| Script execution | Script executes correctly and terminates with "true" on the stack | Rejected (script failure) |
| Fee threshold | Transaction meets the node's minimum relay fee (configurable per node; Bitcoin Core's default dropped to 0.1 sat/vB in version 30.0, though many nodes still enforce the long-standing 1 sat/vB) | Not relayed (below minimum) |
These checks are implemented primarily in Bitcoin Core's src/validation.cpp, which handles both mempool acceptance and block-level validation. If any check fails, the node rejects the transaction and does not relay it. A rejected transaction does not consume bitcoin or fees because it never enters the system.
The Gossip Protocol
Valid transactions propagate across the network through a mechanism called the gossip protocol, part of Bitcoin's base P2P messaging layer (refined in BIP 152 for compact block relay). When a node validates a transaction, it sends an inv (inventory) message containing the transaction's hash to its connected peers. Peers that haven't seen the transaction respond with a getdata message requesting the full serialized transaction, validate it independently, and then announce it to their own peers via their own inv messages. This cascading relay spreads the transaction across the global network within seconds.
The gossip protocol is decentralized and redundant. There is no single point of failure. Even if some nodes are offline or malicious, the transaction reaches the rest of the network through alternative paths. As of early 2026, the Bitcoin network has roughly 22,000 reachable nodes, with the total, including those running behind firewalls or on private networks, estimated at 60,000 or more.
The Mempool
Once a transaction passes validation and enters a node's awareness, it sits in that node's mempool (memory pool), the collection of all valid but unconfirmed transactions. Every node maintains its own mempool independently, so there is no single "the mempool" but rather thousands of slightly different views across the network.
Transactions remain in the mempool until one of two things happens: a miner includes the transaction in a block (confirmation), or the transaction expires from the mempool after a configurable timeout. Bitcoin Core's default mempool expiry is 336 hours (14 days), set by the -mempoolexpiry option.
The mempool is where fee competition occurs. During periods of high demand, miners prioritize transactions that pay higher fees per unit of data (measured in sats per virtual byte, or sat/vB). Transactions with lower fee rates may wait hours, days, or get dropped entirely. Wallet software estimates the appropriate fee by sampling current mempool conditions.
From Mempool to Confirmation
A transaction in the mempool is pending. Confirmation is what makes it final.
Miner Selection
Miners assemble candidate blocks by selecting transactions from their mempool. The primary selection criterion is fee rate: transactions that pay more sats per virtual byte get priority. Miners are economically incentivized to maximize the total fees in each block, so they pack the most profitable transactions first.
A standard block has a maximum weight of four million weight units (roughly equivalent to about 1.5-2 MB of raw data, depending on transaction types). During normal conditions, a block holds between 2,000 and 4,000 transactions. During high-demand periods, the backlog can grow to hundreds of thousands of pending transactions.
Block Mining
Once a miner has assembled a candidate block (selected transactions plus the coinbase transaction that pays the block reward), the mining process begins. The miner repeatedly hashes the block header, varying a nonce value, searching for a hash that falls below the current difficulty target. This is proof-of-work: a computationally expensive process that is trivial to verify but hard to produce.
On average, the Bitcoin network produces one block every ten minutes. When a miner finds a valid hash, it broadcasts the block to the network. Other nodes verify the block (checking the proof-of-work, validating every transaction inside it, and confirming the block follows consensus rules), and upon acceptance, add it to their copy of the blockchain.
At this point, every transaction in that block has one confirmation.
Confirmation Depth and Security
A single confirmation means the transaction is included in a valid block. But the security of that transaction increases with each subsequent block mined on top of it. Each new block adds another layer of proof-of-work that an attacker would need to redo to reverse the transaction.
| Confirmations | Time (approximate) | Security Level | Typical Use |
|---|---|---|---|
| 0 (unconfirmed) | Seconds | No proof-of-work protection | Monitoring only |
| 1 | ~10 minutes | Protected by one block of work | Small transactions |
| 3 | ~30 minutes | Reversal requires significant hashrate | Medium-value transfers |
| 6 | ~60 minutes | Reversal requires sustained majority hashrate attack | Industry standard for large settlements |
The six-confirmation standard is widely cited as the threshold for finality. To reverse a transaction buried under six blocks, an attacker would need to control more than 50% of the network's total hashrate and sustain that control long enough to rebuild six blocks of work faster than the honest network extends the chain. With Bitcoin's hashrate exceeding 800 exahashes per second in early 2026, this is an astronomically expensive proposition.
The Complete Transaction Lifecycle
To see how all these pieces fit together, follow a single transaction from creation to final settlement.
Step 1: Intent
Alice wants to send 0.1 bitcoin to Bob. She opens her wallet and enters Bob's Bitcoin address and the amount.
Step 2: Construction
The wallet scans Alice's UTXO set and selects a 0.15 bitcoin UTXO as the input. It creates two outputs: 0.1 bitcoin to Bob's address and 0.0499 bitcoin back to Alice as change. The remaining 0.0001 bitcoin (10,000 sats) is the implicit transaction fee.
Step 3: Signing
The wallet signs the transaction using Alice's private key, producing a valid ECDSA signature that proves she controls the UTXO being spent. If Alice uses a hardware wallet, this step happens on the device.
Step 4: Broadcasting
The wallet sends the signed transaction to a connected Bitcoin node. The node validates the transaction (checks UTXO existence, signature validity, value conservation) and relays it to peers.
Step 5: Propagation
Through the gossip protocol, the transaction spreads across the network within seconds. It enters the mempool of thousands of nodes worldwide.
Step 6: Mining
A miner includes Alice's transaction in the next candidate block. After expending computational work, the miner finds a valid proof-of-work and broadcasts the block.
Step 7: First Confirmation
Nodes around the world receive the block, validate it, and add it to their chain. Alice's transaction now has one confirmation. Bob's wallet detects the incoming 0.1 bitcoin.
Step 8: Settlement
Over the next hour, five more blocks are mined on top. Alice's transaction is now buried under six blocks of proof-of-work. The 0.15 bitcoin UTXO that Alice spent has been removed from the global UTXO set. Two new UTXOs exist: 0.1 bitcoin controlled by Bob's key and 0.0499 bitcoin controlled by Alice's key.
You can follow every step of a transaction's lifecycle on Blockstream Explorer. Paste a transaction ID to see its inputs, outputs, fees, and confirmation status in real time. The explorer displays the raw transaction data, the script conditions, the fee rate in sat/vB, and the current confirmation count, giving full visibility into exactly what happened and when.
What Can Go Wrong
Most transactions complete without issues. But understanding failure modes clarifies how the system works.
Stuck Transactions
If a transaction's fee rate is too low relative to current mempool demand, it can sit unconfirmed for an extended period. The transaction is valid, but miners consistently choose higher-fee transactions first. Solutions include:
- Replace-by-fee (RBF): If the original transaction was flagged as replaceable (which is the default in modern wallets), the sender can broadcast a new version with a higher fee. Nodes replace the old transaction in their mempool.
- Child-pays-for-parent (CPFP): The recipient (or sender, using the change output) creates a new transaction that spends the unconfirmed output with a high enough fee to make both transactions profitable for miners to include together.
Invalid Transactions
A transaction that fails any validation check is rejected by nodes and never enters the mempool. Common causes include referencing a UTXO that has already been spent, providing an invalid signature, or constructing a malformed transaction. No bitcoin is lost because the transaction simply never executes.
Chain Reorganizations
In rare cases, two miners find valid blocks at roughly the same time, creating a temporary fork. Nodes follow the chain with the most accumulated proof-of-work. When one branch extends further, the shorter branch is abandoned, and transactions in the orphaned block return to the mempool for re-inclusion. This is why waiting for multiple confirmations matters: each additional block makes reorganization exponentially less likely.
Transaction Types and Advanced Patterns
The basic single-input, two-output transaction described above is the most common pattern. But Bitcoin's scripting system supports several other configurations.
Batched Transactions
A single transaction can include dozens or hundreds of outputs, sending bitcoin to many recipients simultaneously. Exchanges and payment processors use batching to reduce the total number of transactions (and therefore total fees) needed to process withdrawals.
Multisig Transactions
Multisig outputs require multiple signatures to spend. A 2-of-3 multisig, for example, requires any two of three designated keys to sign the spending transaction. This enables shared custody arrangements, corporate treasury management, and inheritance planning without trusting any single keyholder.
Time-Locked Transactions
Bitcoin supports both absolute timelocks (prevent spending before a specific block height or timestamp) and relative timelocks (prevent spending until a certain number of blocks have been mined after the UTXO was created). These are used in payment channels, vaults, and other advanced protocols.
SegWit and Taproot Transactions
SegWit moved signature data to a separate section of the transaction, reducing effective size and fixing the transaction malleability bug. Taproot, activated in November 2021, introduced Schnorr signatures and Merklized Abstract Syntax Trees (MAST), enabling complex spending conditions that look identical to simple single-signature transactions on the blockchain. This improves both efficiency and privacy.
For Institutions: Transaction Workflows at Scale
Approval Processes and Policy Engines
Institutional Bitcoin holders do not sign transactions the way individual users do. Institutions implement policy engines that enforce rules before any transaction can be signed: spending limits per transaction and per time period, required approvals from multiple authorized personnel, whitelisted destination addresses, and time-of-day restrictions. These policies are enforced programmatically, not by individual judgment.
A typical institutional transaction workflow looks like this:
- An authorized user initiates a withdrawal or transfer request in the organization's treasury management system.
- The policy engine evaluates the request against configured rules (amount limits, destination whitelist, required approvals).
- If the request requires additional approvals, the system routes it to the appropriate signers based on the organization's governance structure.
- Once all required approvals are collected, the system constructs and coordinates the signing of the transaction.
- The signed transaction is broadcast, and the system logs an audit trail of every approval, signature, and action taken.
Multi-Party Signing and Key Ceremonies
Institutional custody typically uses multisig configurations (such as 2-of-3, 3-of-5, or higher thresholds) to ensure that no single person can move funds unilaterally. Key generation follows strict procedures called key ceremonies, where each keyholder generates their key on a dedicated device in a controlled environment, often with witnesses and documented procedures.
Qualified custodians manage the signing process with segregation of duties: the person who initiates a transaction is not the same person who approves it, and neither is the same person who holds the signing keys. This separation prevents both internal fraud and single points of compromise. Platforms like Blockstream Enterprise provide the infrastructure for these workflows, including role-based access controls, configurable policy engines, and complete audit trails designed for regulatory compliance.
Compliance and Audit Considerations
Every institutional transaction generates a paper trail. The Bitcoin blockchain itself provides an immutable record of when the transaction was confirmed, but institutions also maintain internal records of who requested the transaction, who approved it, which keys signed it, and the business justification. This dual record, on-chain and off-chain, supports regulatory requirements for financial controls and reporting.
Frequently Asked Questions
How long does a Bitcoin transaction take to confirm?
The Bitcoin network targets one block every ten minutes on average, so a single confirmation typically takes around ten minutes. However, the actual time depends on when a miner includes your transaction, which is influenced by your fee rate relative to other pending transactions. During high-demand periods, low-fee transactions can wait hours or longer. Six confirmations (about 60 minutes) is the widely accepted standard for settlement finality.
What happens if I set the fee too low?
Your transaction will sit in the mempool, waiting for a miner to include it. If mempool demand drops, it may eventually confirm. If demand remains high, the transaction could be dropped after the mempool expiry period (typically 14 days). You can increase the fee using Replace-by-Fee (RBF) if the transaction was flagged as replaceable, or use Child-Pays-for-Parent (CPFP) to incentivize miners by attaching a high-fee child transaction.
Can a Bitcoin transaction be reversed after confirmation?
Reversing a confirmed transaction requires an attacker to redo the proof-of-work for that block and every block mined after it, faster than the rest of the network continues extending the chain. With one confirmation, this is difficult. With six confirmations, it is practically impossible without controlling a sustained majority of the network's hashrate. Bitcoin transactions are designed to become more irreversible with each passing block.
What is the minimum amount of bitcoin I can send?
The smallest unit on the Bitcoin network is one satoshi (0.00000001 bitcoin). However, the practical minimum is determined by the "dust limit", a threshold below which transaction outputs are considered uneconomical because the fee to spend them would exceed their value. The dust limit depends on the output type and is typically around 546 sats for standard P2PKH outputs and 294 sats for SegWit outputs.
Do I need to run a full node to send a Bitcoin transaction?
You do not need to run a full node to create and broadcast transactions. Wallet software can connect to remote nodes or use simplified payment verification (SPV). However, running your own node provides the highest level of privacy and trustlessness because you verify transactions and blocks yourself without relying on any third party.
What is the difference between a transaction ID and an address?
A Bitcoin address is a destination: it encodes the spending conditions (typically derived from a public key) that define who can spend funds sent to it. A transaction ID (txid) is the unique hash of a specific transaction, computed as the double SHA-256 hash of the serialized transaction data (excluding witness data for SegWit transactions). Addresses are used to receive bitcoin. Transaction IDs are used to track and verify specific transfers on the network. You can look up any txid on Blockstream Explorer to see the full transaction details.