One balance, two instructions
Imagine that Alice controls ten units of digital value. At almost the same time she signs a payment of ten units to Bob and another payment of the same ten units to Eve. These are not two payments backed by twenty units, but two conflicting proposals that consume the same source.
The same physical banknote cannot be in two tills at once without counterfeiting or theft. Digital messages, however, travel along different routes and computers may receive them in different orders. Without a common decision, both Bob and Eve might believe that their payment arrived first.
Why a valid signature is not enough
Alice can sign both instructions with a valid key. The signature proves her authorisation but does not tell the whole network which message should come first. A timestamp from the sender's clock is unreliable because clocks can be wrong and messages take different amounts of time to travel.
Traditional digital payments hand the dispute to a bank or token issuer. The administrator maintains balances or a list of used units and rejects the second payment. Earlier digital-cash proposals often retained a bank that checked a coin's serial number when it was received or identified repeated spending afterwards.
How Bitcoin selects a shared history
Bitcoin transactions are broadcast to the network. Nodes reject a transaction that spends an output already used in their valid state. Miners collect valid transactions into candidate blocks and search for proof of work. Each block refers to the previous one, gradually producing an ordered history.
If two valid branches appear temporarily, nodes follow the valid chain with the greatest accumulated proof of work. One conflicting payment may enter the accepted branch while the other becomes invalid. Blocks added above a payment increase the cost of rewriting its history, which is why larger payments commonly wait for more confirmations.
- a node checks signatures and whether inputs remain unspent
- proof of work gives proposed history measurable weight
- confirmations reduce reversal risk but do not create instant mathematical finality
The solution is neither magic nor absolute certainty
A payment that is not yet in a block may conflict with another, so the recipient must account for risk. Even after inclusion, assurance is probabilistic: the more work added above the block, the more costly it becomes to produce a stronger alternative history. The appropriate number of confirmations depends on value, circumstances and risk tolerance.
The model also assumes that an attacker does not sustain control of the decisive share of computing power and that the user verifies rules with trustworthy software. Bitcoin does not make fraud impossible under every condition; it creates an open system in which rewriting history becomes measurably expensive and publicly checkable.