Crypto Ch1: Decentralized Ledgers

Chapter 1. Bitcoin: Why decentralized ledgers exist

1.1 The core problem: digital cash is hard

Digital information can be copied. That makes digital cash fundamentally difficult. If money is just information, how do you stop the same unit from being spent twice?

This is the double-spending problem.

The hard part is not storing balances. A spreadsheet can store balances. The hard part is establishing one accepted transaction history in a network where participants do not automatically trust one another.

1.2 Why ordinary databases are not enough

A normal database can maintain consistency if everyone accepts a central administrator. In banking or payment systems, the institution decides what the truth is. If two conflicting claims appear, the institution resolves the conflict.

Bitcoin attempts something more radical:

• No single administrator
• Open participation
• No need for prior trust
• A shared history of valid transfers

So Bitcoin is not simply a database. It is a consensus system for an adversarial open network.

The crucial difference is this:

• In a bank, the operator defines the official ledger.
• In Bitcoin, the network must converge on a ledger without any single trusted operator.

1.3 Bitcoin’s basic solution

Bitcoin allows transaction messages to propagate freely, but the network converges on one valid history. It does this through:

• Transactions: instructions to transfer value
• Signatures: proof that the spender controls the relevant private key
• Blocks: batches of transactions chained into history
• Proof of Work (PoW): a costly mechanism for deciding which block history the network accepts

A useful mental model is:

• Signatures determine who is allowed to spend.
• Proof of Work helps determine which ordered sequence of valid spends the network accepts.

1.4 What signatures solve vs what consensus solves

• Signatures answer: “Are you authorized to spend this?”
• Consensus answers: “Which history of valid spends does the network accept?”

This distinction matters because valid signatures alone are not enough. If the same coin is signed into two conflicting transactions, the network still needs a rule for choosing which one becomes part of accepted history.

1.5 Blocks, chain structure, and Proof of Work

Transactions are grouped into blocks. Each block references the previous block, forming a chain. That chain is not just a storage format. It is the evolving history of accepted state transitions.

Proof of Work makes block production costly. The system then prefers the chain with the most accumulated work.

That means Bitcoin does not try to prevent all conflicting messages from existing. Instead, it lets the network converge on one cost-backed history.

1.6 Confirmation and finality

Bitcoin finality is probabilistic, not absolute. A transaction becomes harder to reverse as more blocks are built on top of it.

So finality in Bitcoin means:

• Not “mathematically impossible to reverse”
• But “increasingly expensive and implausible to reverse”

This is very different from the intuition many people bring from ordinary database systems. In a typical database, a committed write is treated as final. In Bitcoin, “final enough” depends on how much work has been added after the transaction’s block.

1.7 UTXO model

Bitcoin does not primarily work like a bank account with a single mutable balance field. Instead, it uses the UTXO model:

• Old outputs are consumed
• New outputs are created

A transaction is best understood as:

• Spending existing outputs
• Creating fresh outputs with new spending conditions

This model is elegant for validation because each spend can be checked against a known set of unspent outputs. It also means that “balance” is not a primitive on-chain object in Bitcoin. A wallet balance is the sum of all currently controllable UTXOs.

1.8 Coin selection and why wallets matter

When a user spends Bitcoin, a wallet must select which UTXOs to use as inputs. This is called coin selection.

A wallet often tries to optimize among several goals:

• Sufficient value to fund the payment
• Fewer inputs to reduce fee cost
• Minimal dust and change fragmentation
• Better privacy in some cases

This is one reason Bitcoin’s underlying structure is less intuitive than an account model. The wallet hides a lot of complexity from the user.

1.9 Script in Bitcoin

Bitcoin scripting is not a general smart contract platform. It is best thought of as a spending condition language.

Typical conditions include:

• Single-signature spending
• Multi-signature spending
• Timelocks
• Hashlocks
• Basic conditional branches

Its goal is not general-purpose programmability, but reliable and constrained control over spending conditions.

That design matters. Bitcoin deliberately restricts expressive power in order to keep consensus simpler, attack surfaces smaller, and validation more predictable.

1.10 What Bitcoin optimizes for

Bitcoin prioritizes:

• Security
• Decentralized verification
• Long-term stability
• Simple, conservative monetary logic

It does not prioritize:

• Rich application logic
• High throughput at all costs
• General-purpose execution

This is why it is misleading to call Bitcoin “just an old slow chain.” Its architecture reflects a deliberate preference for robust settlement over expressive application complexity.

Key takeaway

Bitcoin is a decentralized settlement system designed to prevent double spending and preserve a hard-to-rewrite history of value transfer in an open, adversarial environment.

— Mar 20, 2026

Crypto Ch1: Decentralized Ledgers by Lu Meng is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available at About.