Full article
The wallet displays a balance; the shared record determines it
Bitcoin payments do not move a coin-shaped file from one phone to another. Bitcoin.org introduces a process involving a shared ledger, signatures, and mining: a wallet proposes a transaction and the network applies common validation rules. This distinction explains why deleting an application does not erase public transaction history. It also explains why a screenshot of a balance is insufficient evidence of current spending ability. A payment depends on available value and the ability to satisfy its spending conditions, rather than on the appearance of a particular screen.
A payment can produce both a receipt and change
The developer guide describes balances in terms of unspent transaction outputs, or UTXOs. Imagine an available output of 100,000 satoshis. A hypothetical payment sends 30,000 to the recipient, allocates 1,000 to the fee, and returns 69,000 as change. These figures explain the arithmetic; they are not a current fee estimate. The comparison with paying using a larger banknote is useful, provided the limits of the analogy remain clear. The change is a new recorded output under spending conditions, not an informal debt that the network promises to settle later.
A signature authorizes; it does not interpret the purchase
Digital signatures allow authorization to be checked without distributing the private key itself. They cannot determine whether the selected recipient matches an agreement outside the system. Imagine two addresses that look similar on a screen and a user approving the wrong one. A mathematically valid signature can still authorize a payment that fails to match that person’s intention. Correct authorization and correct destination are therefore separate checkpoints. Network validation cannot infer which shop was intended from a conversation or invoice that its rules do not evaluate.
Broadcasting and confirmation describe different stages
After a transaction is sent, it still needs inclusion in a valid block, which other nodes check against the rules. A sent indicator therefore describes a stage in the process, not necessarily the level of certainty a recipient needs before delivery. Consider a hypothetical comparison between a low-cost digital download and an expensive physical shipment. Their tolerance for delay and payment uncertainty may differ. Choosing a confirmation requirement involves that trade-off. It should not be reduced to a universal number of seconds or a promise that every payment will finish by a fixed deadline.
Verification reduces dependence on the sender’s story
The practical benefit of the shared record is that a recipient can assess a payment using verifiable information rather than relying only on the sender’s statement. Address, amount, fee, and confirmation status still describe different aspects of that assessment. Suppose someone provides a real transaction identifier: the recipient must still establish whether the transaction pays the intended address and amount. Existence alone does not make it the expected payment. Our interpretation is that separating these roles explains everyday payment behavior more clearly than reducing the whole system to the idea that mining creates coins.