How Bitcoin transactions work: UTXOs, signatures, mempool, and confirmations
A Bitcoin send spends prior unspent outputs, creates new outputs (including change), and becomes final as blocks confirm it.
How Bitcoin transactions work is simpler than most wallet UIs make it look: you spend old outputs, create new ones, sign, broadcast, then wait for miners to confirm. Once you can picture that pipeline, fees, delays, and “missing balance” moments stop being mysterious.
What a Bitcoin transaction is (plain-English model)
A Bitcoin transaction is not an “account transfer” that subtracts from one balance and adds to another. It is a signed data message that reassigns control of specific chunks of bitcoin to new owners, enforced by the network’s rules and verified by anyone running a node. BTC.network describes it as a signed message that reassigns ownership, and Bitcoin.com frames bitcoins themselves as a history of transfers rather than objects sitting in accounts.
The clean mental model is: Bitcoin tracks spendable pieces of value, and a transaction consumes some of those pieces and creates new ones. That’s why the Bitcoin whitepaper is often summarized as a chain of digital signatures, and why you can inspect every transaction on a public ledger with a block explorer. Nothing “moves” inside a bank database. Instead, the network updates a shared record of which outputs are unspent and who can spend them next.
Inputs, outputs, and UTXOs: the building blocks
Every Bitcoin transaction is built from inputs and outputs. Inputs point to previously created outputs that are still spendable. Outputs define new spendable chunks and the conditions required to spend them later. Multiple sources converge on this structure: BTC.network, Bitcoin.com, OKX, and Mt Pelerin all describe transactions as inputs spending prior outputs and creating new outputs.
Those spendable prior outputs are called UTXOs, short for unspent transaction outputs. Kraken explains that the UTXO model is the technique Bitcoin uses to track balances as they move between wallets, and both OKX and Mt Pelerin emphasize that wallets scan the blockchain or the UTXO set to find spendable outputs. Practically, your wallet “balance” is just the sum of UTXOs it can unlock.
The part that trips up new users is that UTXOs are typically spent in full. You do not usually spend “half” of a UTXO. If your inputs add up to more than the amount you want to pay, the transaction creates a change output back to an address you control. BTC.network, Kraken, OKX, and Mt Pelerin all describe this full-spend behavior and the resulting change output.
A concrete example matches what you see on-chain. If you control a single 0.05 BTC UTXO and you want to pay 0.03 BTC, your wallet will likely use that entire 0.05 BTC as an input, create an output of 0.03 BTC to the recipient, and create a second output back to you for the remainder as change, minus the fee. BTC.network walks through this exact pattern, and Bitcoin.com and Mt Pelerin describe the same “cash change” behavior with different numbers.
One special case matters for understanding where BTC comes from. Kraken notes that the only transaction type with no inputs is the coinbase transaction, which is the first transaction in a block and is where newly minted BTC is created as part of mining rewards.
Signing: how the network knows you’re allowed to spend
Inputs are not just pointers. They also carry the unlocking data that proves you are authorized to spend the referenced UTXOs. That authorization is cryptographic.
When you “own” bitcoin, what you really control is the private key that can produce a valid digital signature for the spending conditions on an output. Bitcoin.com, OKX, Mt Pelerin, BTC.network, and LearnMeABitcoin all describe this public-key cryptography setup: the private key is used to sign, and others can verify the signature using the corresponding public key information.
Two practical consequences fall out of this.
First, signatures are unforgeable without the private key. BTC.network and OKX both stress that the network can verify you’re allowed to spend without you revealing the private key itself.
Second, the signature binds to the transaction data. OKX explains that if transaction details are altered after signing, the signature no longer validates. LearnMeABitcoin describes transactions as data that “unlocks and locks” batches of bitcoin, where the unlocking typically involves a signature created from the private key corresponding to the public key in the output’s lock.
This is also why Bitcoin is often described as a chain of digital signatures. Bitcoin.com quotes the whitepaper’s description of each transfer signing the previous transaction reference and the next owner’s public key, creating a verifiable chain of ownership.
Broadcast, validation, mempool, mining, confirmations
Once your wallet constructs the transaction and signs it, it broadcasts the signed data to the peer-to-peer network. BTC.network, Bitcoin.com, OKX, and Mt Pelerin all describe this broadcast step and what happens next.
Nodes do not blindly accept what they receive. They validate. At a minimum, they check that signatures are valid, that the referenced UTXOs exist and are unspent, that outputs do not exceed inputs, and that the transaction follows protocol rules. BTC.network and Mt Pelerin explicitly describe signature checks and double-spend prevention as part of node validation.
Valid, unconfirmed transactions sit in the mempool, which is effectively the network’s shared waiting room. Bitcoin.com, OKX, Mt Pelerin, and BTC.network all use the same concept: transactions propagate, then wait in mempools until miners include them.
Miners then select transactions from the mempool and include them in a block. Bitcoin.com and OKX describe miners competing via Proof of Work to produce the next block, and Mt Pelerin notes that blocks are mined on average about every 10 minutes. OKX also states the same 10-minute average.
Your transaction gets its first confirmation when it is included in a mined block that the network accepts. Each additional block built on top adds another confirmation, making reversal increasingly difficult. BTC.network, Bitcoin.com, OKX, and Mt Pelerin all describe confirmations as accumulating with each new block and increasing security.
How many confirmations count as “final” is convention, not physics. BTC.network says many recipients treat 1–3 confirmations as enough for moderate amounts, while exchanges often require 3–6 for larger deposits. Bitcoin.com and OKX both describe a common practice of waiting for six confirmations to reduce reversal risk during temporary forks. The key point for traders is that “finality” is a risk threshold chosen by the receiver, and it varies by venue.
Fees and transaction size: why some sends are slow or expensive
Bitcoin fees are not a percentage of the amount you send. They are an auction for scarce block space.
The fee is implicit in the transaction: it is the difference between total input value and total output value. BTC.network and Mt Pelerin describe this directly, and OKX explains fees as driven by transaction size rather than the BTC amount.
Miners prioritize by fee rate, not absolute fee. BTC.network explicitly says miners prioritize transactions with the highest fee rate, commonly quoted in sat/vB (satoshis per virtual byte). Mt Pelerin also uses sat/vB and shows the basic math: fee rate multiplied by transaction size determines the total fee.
This is where UTXO management becomes a real-world cost driver. More inputs and outputs generally means more bytes or virtual bytes, which means a higher total fee at the same sat/vB. BTC.network, Bitcoin.com, OKX, and Mt Pelerin all tie fee cost to transaction size, and BTC.network calls out that consolidating small UTXOs during low-fee periods can reduce future transaction sizes.
That also explains why two transactions sending the same BTC amount can have very different fees. A wallet spending one large UTXO might produce a compact transaction. A wallet spending many small UTXOs to reach the same amount produces a larger transaction and pays more at the same fee rate. Bitcoin.com gives an intuitive version of this idea by noting that transactions with more inputs take more block space and can cost more, and Mt Pelerin makes the same point by linking byte size to how many UTXOs are consumed.
When a transaction is “stuck,” it usually means it is sitting in mempools with a fee rate that is not competitive for current demand. The protocol does not guarantee inclusion by time. It guarantees that miners can include valid transactions, and miners are economically incentivized to pick higher fee rates when block space is scarce.
How to inspect a transaction (and what’s inside one)
Bitcoin is transparent by design. After you send, your wallet will show a TXID, which is the transaction’s identifier. You can paste that TXID into a block explorer to see whether the transaction is unconfirmed or confirmed, how many confirmations it has, what fee it paid, and exactly which inputs and outputs it used. OKX and Mt Pelerin both describe using a block explorer with a TXID to track status and details.
If you want to go one level deeper, raw transactions have a defined field structure. LearnMeABitcoin breaks down the standard layout and highlights the key pieces traders actually run into when debugging. Inputs reference previous outputs using a transaction ID (TXID) plus an output index (VOUT). Outputs specify amounts and locking scripts. SegWit transactions add a witness field that carries unlocking data for inputs, and the transaction also includes fields like version and locktime. You do not need to memorize the byte-level format to use Bitcoin, but knowing that the transaction is structured data helps you interpret what explorers show you.
The practical payoff is simple: when something looks off, you can verify it yourself. If your wallet balance “drops” after a send, the explorer will usually show a change output returning value to you, which only becomes spendable once confirmed, as Mt Pelerin explains. If a deposit is delayed, the explorer will show whether it is still in the mempool and what fee rate it offered, which is often the real reason it is waiting.
The Take
I’ve watched traders waste hours arguing about “slow Bitcoin” when the chain is doing exactly what it was designed to do. How Bitcoin transactions work is a UTXO spend plus a signature plus a fee-rate bid for block space. Once you internalize that, you stop treating confirmations like magic and start treating them like probabilistic settlement that tightens with each block.
The only habit that consistently saves money and stress is thinking in inputs. If your wallet is full of dust-sized UTXOs, you are carrying future fee risk because more inputs usually means more vbytes and a higher total fee at the same sat/vB. BTC.network’s point about consolidating during low-fee windows is not theory. It is basic transaction mechanics showing up in your PnL.
