How does the mechanism work?
Think of an output as an amount paired with a condition for spending it. It is identified by the transaction that created it and its position within that transaction. An input points to that specific output.
The network tracks which outputs remain unspent. A wallet can group many of them into the balance you see. That display does not turn them into an account that is reduced in place whenever you pay.
Outputs also explain why a payment can depend on another payment. If the output you plan to spend was created by an unconfirmed transaction, the new spend depends on that parent. Your interface might show both as pending, but the records still have a precise order. A node needs the parent’s output to evaluate the child. Confirmation of a valid block can resolve that dependency in the accepted history. It does not merge the records into an editable account. Tracing output references gives you a consistent explanation across confirmed receipts, unconfirmed parents and later spends of returned change.
What would you see in an example?
Suppose you control an output worth more than the payment you want to make. Your transaction spends the output in full. It creates a recipient output and normally a change output under your control. The fee is the difference between the input amount and the sum of the newly created output amounts.
How can you balance a concrete set of outputs?
Use satoshis to keep the arithmetic exact. One BTC represents 100,000,000 satoshis. In this invented example, you control separate outputs of 70,000 and 50,000 satoshis. Your displayed balance is 120,000 satoshis, but the chain contains separate spendable records. Spending one does not silently reduce the other. Each selected output becomes a referenced input.
Suppose you select both outputs for a payment of 90,000 satoshis. Assume the completed transaction has a virtual size of 210 vbytes and you choose an illustrative rate of 3 sat/vB. Its fee is 630 satoshis. The change is 120,000 - 90,000 - 630 = 29,370 satoshis. Add the two new outputs and the fee to recover the original input sum.
Now compare selection of only the 70,000-satoshi output. It cannot cover the 90,000-satoshi payment even before a fee is considered. A balance display alone does not explain which outputs will be selected. Input choice can affect transaction size, privacy and which outputs remain available for another payment. The offline builder lets you explore this arithmetic with invented coins.
An output reference combines a transaction identifier with an output index. The first output has index 0. Two outputs in the same transaction therefore share a transaction identifier but have different references. When one is spent, the other can remain unspent. This precise identity prevents a node from confusing equal-valued outputs or treating an address balance as the thing that is consumed.
Common misunderstandings
An input does not partially spend an old output. Its entire value enters the transaction’s accounting. Any returned remainder is a new output with a new reference. The word change describes its purpose for the sender, rather than a special consensus category.
A selected input is not reserved across the network merely because your interface selected it. Another conflicting transaction could reference it. Nodes must evaluate the spend against their accepted chain state, and their unconfirmed views may differ before a valid block resolves the conflict.
Check yourself
If you spend one of two outputs with equal values, is the other consumed too?
Reveal the answer
No. Each output has its own transaction identifier and index. Only the outputs referenced by the inputs are spent.
What does this diagram leave out?
The diagram shows a common payment shape, not a required template. A transaction can combine several inputs or create several outputs. Nodes must reject attempts to spend an output that is already spent in the chain they accept. A pending transaction is a separate case from a confirmed spend.
Which primary sources explain the rules?
Sources: Transaction developer reference.