In January 2009, a transaction in block 170 of the Bitcoin mainnet appeared that is well-suited for analysis.
It had only one input but created two outputs: the input referenced a previous 50 BTC output; the new transaction wrote 10 BTC into one new spending condition and the remaining 40 BTC into another. The input and output amounts were equal, so this early transaction carried zero fees. [1]
If you think of Bitcoin as adjusting balances between bank accounts, this structure looks strange.
Why not simply subtract 10 from account A and add 10 to account B? Why must the original 50 be spent as a whole, only to create two new objects of 10 and 40?
Because Bitcoin's underlying state is not a ledger of account balances, but a set of unspent transaction outputs.
Wallets are responsible for combining these outputs, nodes are responsible for checking transactions, the mempool is merely each node's own temporary collection, and blocks write a batch of transactions into a history that can still be reorganized. The "balance" on your screen is a view that the wallet computes on top of these underlying objects.
I. UTXOs Are Not Account Balances
UTXO stands for unspent transaction output.
A transaction creates outputs. As long as they have not been consumed by a later valid transaction, they are UTXOs; once successfully spent, they are removed from the current set of available outputs.
Each output contains at least two types of information:
An amount denominated in satoshis; A script condition specifying how it can be spent.
Nodes do not maintain a global account record of "how much balance a certain address has." Instead, they track which outputs are still available, along with each output's amount and spending condition. Formal research and Bitcoin Core's UTXO implementation both center on whether an output exists in the current state. [2]
UTXOs are a bit like cash, but not like paper bills.
Paper bills have fixed denominations and physical carriers; UTXOs are digital objects in the ledger, can hold any amount the protocol allows, and can be encumbered by a single public key, multisignature, time locks, hash locks, or Taproot paths.
When a node identifies a UTXO, it uses the coordinate pair of "the transaction ID that created it + the output index."
The block 170 transaction perfectly illustrates "whole-output spending": the old 50 BTC output cannot be reduced by 10 on the original object, leaving 40. The new transaction must consume the entire old output, then create two new outputs of 10 and 40.
Figure 1 | UTXO changes in the block 170 transaction. The input references an old output, not a debit from an account; the old 50 BTC output is consumed in its entirety, and 10 BTC and 40 BTC become two new spendable objects. Drawn by the author based on raw block data.
The 10 BTC is typically interpreted as a payment, and the 40 BTC as change.
But "change" is not a label that exists in the consensus data itself. It requires wallet construction records or external evidence to confirm; relying only on on-chain heuristics can lead to incorrect conclusions.
II. Transactions and Wallets: From Old Outputs to New State
An ordinary Bitcoin transaction mainly consists of fields such as version, inputs, outputs, and locktime. [3]
Inputs tell the node: "which old outputs I intend to spend."
Outputs tell the node: "if this transaction is valid, which amounts and spending conditions should be created next."
There is no natural-language field in a transaction that a system can understand, saying "this is payment for goods," "this is a loan," or "this is change."
Inputs also do not directly store the amount being spent. The node must follow the previous transaction ID and output index to find the old output, obtain its amount and script, and then confirm it has not yet been spent.
This explains why the following three statements are completely different:
The transaction bytes can be parsed; The signature or script condition is satisfied; The transaction is valid in the context of a full block.
A string of bytes can be well-formed yet reference outputs that do not exist; it can reference real UTXOs yet provide incorrect signatures; or it can satisfy consensus rules yet fail a node's local policy for what it is currently willing to accept into its mempool.
Conservation of amount is also not "outputs must equal inputs." The total input amount must not be less than the total output amount; the difference between the two is the fee. The fee is not a special output, but rather the difference that a block producer can claim in a legitimate coinbase reward. [4]
In the block 170 example, 50 splits exactly into 10 and 40, so the difference is zero.
Wallets Do Far More Than "Hold Balances"
When a user enters recipient information and an amount, a wallet typically performs four tasks.
First, selecting UTXOs.
To pay 0.6 BTC, the wallet can spend a single 0.7 BTC output or combine several smaller outputs. Coin selection affects fees, privacy, change, and how funds can be spent later, but consensus does not dictate a single correct method.
Second, creating payment and change outputs.
Change usually goes to a new script controlled by the wallet, but there is no universal "change" marker on-chain.
Third, generating the signatures, witnesses, or scriptSig required to satisfy the spending conditions.
A signature only proves that, under a specific hash, script rules, and context, some signing capability was used for this spend.
It cannot automatically prove which natural person pressed the key, that internal organizational authorization is valid, or that the signer legally owns the assets. Cryptographic control, real-world identity, organizational authorization, and legal ownership must be kept separate. [5]
Fourth, submitting the transaction to a node.
The node may be on the user's own device or belong to a wallet service provider. The so-called wallet balance is a result computed by the wallet based on descriptors, key ranges, recognized scripts, confirmation depth, and node state.
Output Script Descriptors can more precisely describe which scripts a wallet should watch and how keys are derived, but descriptors are still not proof of real-world identity or legal ownership. [6]
So, a wallet is not an account object on-chain.
It is more like a set of keys and script observation rules, plus software for coin selection, transaction construction, and state interpretation.
III. Nodes Face Three Different Kinds of Questions
After a wallet hands over a transaction, "whether the node accepts it" is still not a single switch.
1. Consensus Validation
Consensus validation asks: if the transaction is placed in a candidate block, given a parent block, UTXO state, and activation rules, can it become part of valid history?
Nodes must check format, amount ranges, whether inputs exist and are unspent, whether scripts or witnesses succeed, and block-level limits.
Without the parent state, one cannot simply verify a signature and declare a transaction "valid."
2. Local Policy
Policy asks: even if this transaction could legitimately be written into a block, is this node willing to put it into its own mempool right now and relay it to peers?
Standardness, minimum fee rates, unconfirmed ancestor and descendant structures, replacement rules, node version, and configuration can all affect the answer.
Policy can vary; it is not a network-wide consensus rule. Bitcoin Core also keeps standardness, mempool acceptance, and full block validation in separate code paths. [7]
3. Wallet View
The wallet view asks: does the current wallet recognize certain outputs as its own, and does it display transactions as pending, confirmed, conflicting, or removed by a reorganization, and how do these states feed into the balance?
These three sets of questions cannot substitute for one another.
Local mempool acceptance does not mean confirmation; a node's policy rejection does not mean a consensus violation; and entering a block does not prove that all wallets have synchronized to the same state.
Figure 2 | A transaction passes through multiple layers of state, not a single "success/failure" switch. Wallet construction does not guarantee node acceptance; mempool acceptance does not guarantee propagation or confirmation; and confirmation does not guarantee absolute irreversibility. Drawn by the author.
Figure 3 | Consensus, policy, and wallet view are three different judgments. The most common misreading is to substitute local mempool results for full consensus validation, or to treat wallet labels as on-chain identity facts. Drawn by the author.
IV. The Mempool Is Not a Network-Wide Waiting Room
The mempool is a node's local data structure for temporarily storing unconfirmed transactions.
The "waiting room" analogy is intuitive, but it easily leads people to think all nodes see the same queue.
In reality, node A may have already received a transaction; node B may not have received it yet; node C may reject it due to fee or structural limits; and node D may be keeping a conflicting transaction instead.
BIP 35 allows peers to request a node's mempool inventory, and BIP 133 allows nodes to filter transaction announcements to specific peers based on fee rates. These protocols themselves demonstrate that "one node knows" cannot be rewritten as "the whole network has it." Node churn research has also observed that transaction sets can differ between nodes, though the exact degree is limited by period, version, and measurement methods. [8]
Propagation is also usually not a matter of pushing full transactions unconditionally to everyone.
A node can first announce transaction identifiers, and peers request the data on demand; modern nodes may also negotiate to announce SegWit transactions using wtxid. Connection topology, fee filtering, restarts, bandwidth, and local policy all affect propagation. The best-effort broadcast described in the whitepaper likewise emphasizes that messages need not arrive at all nodes simultaneously. [9]
Therefore, seeing a zero-confirmation transaction only means that some propagation path has brought it to the current observation point.
It may not have reached any block producer yet, it may conflict with another transaction, or it may leave the local mempool after replacement, restart, or policy changes.
V. Blocks Commit a Batch of Transactions, Not a Permanent Seal
A block places a batch of transactions into a shared context.
Traditional transaction IDs are aggregated via a Merkle tree into a Merkle root, which enters the block header; the header also contains the previous block hash, timestamp field, difficulty target encoding, nonce, and other information.
Changing the transaction set typically changes the Merkle root, which in turn changes the block header and block hash.
SegWit added a witness commitment.
txid does not include the witness serialization; wtxid covers the full serialization including the witness. The traditional Merkle root uses txid, while witness data enters the block commitment through the witness commitment in the coinbase. [10]
Figure 4 | Transaction identifiers and block commitments. After SegWit, txid, wtxid, the traditional Merkle root, and the witness commitment each cover different byte ranges; "same or different hash" must first specify what is being computed. Drawn by the author.
When a node receives a block, it does not skip transaction validation just because the proof of work is correct.
It still applies the transactions on top of the parent block state, confirming that inputs exist, are not double-spent, scripts pass, and amount and block-level rules hold. A valid block removes old UTXOs from the set and adds new outputs to it.
This is the key step in which a transaction moves from "candidate" to part of a valid branch.
VI. Confirmation Is Not Absolute Finality
Wallets typically call the block containing a transaction the first confirmation; each additional block on top adds one more confirmation.
It expresses how deeply the transaction is covered by subsequent work on the current best chain, not an irrevocable certificate issued by a central clearing institution.
If a node later sees a valid branch with more cumulative work, it may switch to it.
Transactions in the old branch may also exist in the new branch, may return to the mempool, or may lose their confirmed status because they conflict with transactions in the new branch. The whitepaper already described parallel branches and subsequent switching in its network steps; Bitcoin Core's wallet and mempool also handle transaction recovery and conflicts after block disconnects. [11]
So, "six confirmations" is a common risk convention, not a constant of legal finality that applies to all amounts, attackers, and business scenarios.
The deeper the confirmation, the more difficult a competing rewrite usually becomes; how long to wait also depends on transaction value, attacker motivation, current chain state, risk tolerance, and off-chain remedies.
VII. Upgrades Did Not Eliminate UTXOs, and Roles Did Not Merge
From early public-key scripts to P2SH, SegWit, and then Taproot, Bitcoin's transaction encoding and spending conditions have continued to evolve.
SegWit moved witness data into a separate structure, introducing wtxid and the witness commitment; Taproot allows outputs to commit to an aggregate public key and an optional script tree, which can be spent via the key path or the script path. [12]
But they did not turn Bitcoin into an account system.
A Taproot output is still a transaction output with an amount and spending conditions; spending it still requires referencing the old outpoint, creating new outputs, and having nodes validate according to the corresponding rules.
Nor can you determine the actual spending path just by looking at the address prefix. P2SH can wrap SegWit; a Taproot output may use the key path or reveal a script path. Accurate classification requires looking at the script of the output being spent and the actual input witness.
Who Validates, Who Controls, Who Can Remedy
Behind any transaction, there are at least five types of actors:
Wallet users and wallet software: coin selection, output construction, invoking signing capabilities; Validating nodes: checking transactions and blocks according to local software and current chain state; Peer nodes: deciding whom to connect to, and which objects to announce and request; Block producers: selecting candidate transactions, ordering them, and proposing blocks; Block explorers, remote nodes, custodial wallets, and exchanges: providing visibility and convenience on behalf of users, but also potentially re-centralizing operational control.
These roles can be held by the same entity or distributed across different parties.
Running your own wallet and full node can reduce reliance on others "telling you the rules and history"; but it does not automatically solve device security, real-world identity, counterparty risk, or legal recourse.
When keys are leaked, funds are mispaid, or fraud occurs, validity at the protocol layer does not mean the real-world dispute is resolved. Software has no network-wide customer service button that can undo a transaction already confirmed according to the rules. Recourse, compensation, and negotiation belong to a different set of institutions.
What the block 170 transaction ultimately offers is not the simple story of "account A transferred 10 BTC to account B."
What actually happened underneath is: a 50 BTC output was referenced and its spending conditions were satisfied, the old state was consumed, and two new states of 10 and 40 were created; nodes validated it under a specific history and rules, a block included it in the proof-of-work chain, and wallets and later researchers then attached interpretations of payment, change, and participant relationships to those bytes.
Once this path is understood, the question for the next article truly emerges: since transactions and blocks must be validated by different nodes and compete for inclusion, why would anyone be willing to expend hashing power and energy? How do difficulty, block rewards, halvings, and fees together constitute Bitcoin's economic security?
Key Takeaways
Bitcoin's underlying state is a set of UTXOs, not a ledger of account balances. Transactions consume entire old outputs and create one or more new outputs; the difference between inputs and outputs is the fee. Wallets handle coin selection, change, signing, and display, but wallet labels are not on-chain identity. Consensus validation, local policy, and wallet view are three different judgments. The mempool belongs to individual nodes, not a network-wide shared queue. txid,wtxid, Merkle root, and witness commitment cover different byte ranges.Confirmations build confidence but do not constitute absolute or legal finality. SegWit and Taproot changed encoding and spending conditions but did not eliminate the UTXO state model.
References and External Links
[1] Bitcoin mainnet block 170, block id 00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee, Blockstream raw block, Blockchain.com hex; the 50 BTC prior output referenced by its input is available via the Blockstream transaction endpoint (accessed: 2026-08-24).
[2] Nicola Atzei et al., "A Formal Model of Bitcoin Transactions," Financial Cryptography and Data Security, 2018, DOI; Bitcoin Core contributors,