Bitcoin is not trying to “issue coins.” It is trying to solve a harder problem: how can a group of mutually untrusted nodes agree on who spent what, without a central bookkeeper?
What Problem It Solves
The hard part of digital cash is not encryption. It is double-spending. If the same money can be copied and spent twice, it is no longer money, only data that can be resent.
In a centralized system, a clearing authority decides who spent first. In an open network, that authority does not exist. Nodes do not trust each other, messages may be delayed or lost, and forks may appear. At one moment, two transactions may both look valid.
Digital signatures can prove that a spend was authorized, but they cannot prove that the money was not also spent somewhere else. Broadcasting can spread transactions, but it cannot decide global ordering.
Bitcoin’s answer is direct:
- Ownership is proven by digital signatures
- Ledger order is decided by proof of work
- Historical disagreement converges through the longest-chain rule
- Participants do not need to know each other, only the same public rules
The Historical Constraint
The Bitcoin white paper appeared in 2008, in a typical open Internet environment: nodes could join and leave freely, network delay was unpredictable, there was no universal clock, and there was no central server everyone was willing to trust.
If you rely only on identity, you get Sybil attacks. If you rely on a timestamp server, you hand ordering back to a center again.
What was available at the time:
- Mature public-key cryptography
- Commodity machines that could hash and verify signatures
- Peer-to-peer networks that could broadcast messages
What was missing:
- A low-cost, publicly verifiable way to order a ledger without a central authority
Bitcoin did not invent “security.” It converted ordering and arbitration into a public, verifiable cost.
The Core Design in One Sentence
Bitcoin uses UTXO to represent ownership, digital signatures to authorize spending, and proof of work plus the longest-chain rule to decide history.
How One Transaction Becomes Valid
The wallet finds spendable outputs
Bitcoin uses the UTXO model, not an account-balance model. A wallet’s “money” is not one mutable balance field. It is a set of unspent outputs.
Each transaction input points to a previous output. Once spent, that output becomes unavailable.
This gives Bitcoin a very direct double-spend check: each output can only be spent once.
The wallet signs with a private key
After selecting inputs, the wallet signs them. The signature proves “I am allowed to spend this output,” not “I am who I say I am.”
The address is also not simply the public key. More precisely, an address is usually an encoding of a locking condition. The important mental model is: the UTXO stores the condition that must be satisfied later, not a person’s account balance.
The transaction is broadcast
Once broadcast, nodes verify it before deciding whether to relay it or keep it in their mempool.
- Does it fit the consensus rules?
- Does it match the current UTXO set and script rules?
- Does it satisfy the node’s relay policy?
Consensus asks whether a block containing this transaction would be accepted. Policy asks whether this node wants to store and forward it now.
Miners put transactions into blocks
Miners pick transactions from the pool, build a block, add a coinbase transaction, and then search for a block header that satisfies the target difficulty.
Nodes verify the rules, not the miner
Full nodes independently verify:
- Whether the block header meets difficulty
- Whether signatures are valid
- Whether inputs are really unspent
- Whether the block reward is within the rule
- Whether the Merkle root matches the transaction set
Bitcoin separates the writer of the ledger from the verifier of the ledger.
Confirmations are probabilistic, not instant finality
A transaction in one block has one confirmation. Each additional block makes rewriting it more expensive.
So “six confirmations” is not magic. It is a practical risk threshold that says the chain is probably deep enough for the use case.
Why the Design Looks Strange
Why UTXO
UTXO makes ownership concrete: every spendable output can only be used once. It also avoids a constantly changing global account balance.
A simple example:
- Alice receives 3 BTC as one UTXO
- Alice wants to pay Bob 1 BTC
- She spends that output in a new transaction
- The new transaction creates:
- 1 BTC to Bob
- 2 BTC as change back to Alice
The “balance” is just the sum of all unspent outputs you control.
Why Merkle trees
Blocks contain many transactions. A light client cannot always download and verify everything. A Merkle tree compresses all transactions into one root hash, so inclusion can be proven with a Merkle path.
Why proof of work
Bitcoin does not use identity voting. It binds writing rights to a publicly verifiable computation cost. If you want to rewrite history, you must redo the work.
Why forks and reorgs are tolerated
Bitcoin does not pretend the network is perfectly synchronized. Two miners may find blocks at the same time, and different nodes may temporarily see different branches. The system lets those forks resolve by accumulating more work.
Why light clients only know “part of the truth”
SPV clients keep only block headers and use Merkle paths and proof of work to get a weaker but useful validation model. They can check inclusion, but they cannot fully replace a full node.
Why fees fluctuate
Block space is scarce. When demand is high, users compete for inclusion with fees. When demand is low, fees fall. That is part of the design.