How blockchain
really works

The first misconception to drop: a cryptocurrency is not a folder of coin files sitting on your computer. There are no coins anywhere. There is only a ledger — a running list of who paid whom — and "your balance" is just what that list adds up to for your name. Every question about how crypto works is really one question: how do thousands of strangers keep identical copies of one ledger honest, with no bank in the middle?

If that sounds abstract, it has a very concrete precedent. On the Micronesian island of Yap, money was rai — stone discs, some the size of a car, far too heavy to move. So they didn't move. When a stone changed hands, the island simply agreed on the new owner; the stone stayed put. One famous rai sank to the sea floor during transport, and the islanders agreed the owner still owned it — it kept being spent, underwater, for generations. The lesson is the whole of this guide: the ledger is the money. Bitcoin just replaced a village's shared memory with cryptography. (The economist Milton Friedman told this story in "The Island of Stone Money.")

A shared ledger with no owner creates exactly two problems, and the rest of this guide is the two solutions:

That second problem has a name — the double-spend problem. Digital things copy for free; money must not. If I can spend the same coin twice by showing two people two different versions of history, the money is worthless. A bank solves it by being the single source of truth. A blockchain has to solve it with no single source at all.

Cryptographic hash — a fingerprint for data. A hash function like SHA-256 takes any input — a word, a file, an entire library — and produces a fixed 256-bit output (64 hex characters). Four properties make it the load-bearing wall of the whole system, and each one exists because the ledger needs it:

Deterministic — the same input always gives the same hash, on every machine on Earth. Two nodes an ocean apart can confirm they hold the identical ledger by comparing 32 bytes instead of gigabytes. Avalanche — flip a single bit of input and about half the output bits flip, unpredictably; tampering is never subtle, it's a klaxon. One-way — you cannot run it backwards to recover the input; a hash commits you to data without revealing it. Collision-resistant — nobody can find two different inputs with the same hash. The output space is 2²⁵⁶ ≈ 1.2 × 10⁷⁷ possibilities — within a few orders of magnitude of the number of atoms in the observable universe (~10⁸⁰). That is the honest scale of "nobody can find a collision."

The avalanche property is the one to feel, not just read. Type into both boxes below — the second starts one keystroke away from the first — and watch how a change too small to matter to a human rewrites the fingerprint completely:

Digital signature — unforgeable handwriting. This is the second primitive, and it answers "who authorized this?" You hold a key pair: a private key that only you know, which signs things, and a public key that everyone can see, which lets anyone verify your signature. Your crypto "account" is a key pair — your address is derived from your public key. A transaction is just a small record — to, amount, a reference number — plus a signature computed over all of it with your private key.

The consequences are worth stating one by one, because together they solve the forgery problem:

• Nobody can forge a payment from you without your private key — not miners, not exchanges, not the people who wrote the protocol.
• Anyone on Earth can verify your payment using only your public key — verification is open to all, signing is exclusive to you.
• Change one bit of a signed transaction and the signature verifiably breaks (avalanche, again) — you can't tamper with a payment after it's signed.
• The dark side: lose the private key and the money is gone forever. There is no "forgot password," no support line. This is what "not your keys, not your coins" means.

The specific math is ECDSA over the secp256k1 curve for Bitcoin and Ethereum accounts — worth knowing the name if you want to dig, but the elliptic-curve details don't change the mental model: secret to sign, public to check.

Transactions aren't stored one by one. They're batched into blocks, and a block is two parts: a header and the list of transactions it contains. The header is small and fixed-shape:

struct BlockHeader {
    prev_block_hash    // 32-byte hash of the previous header — the chain link
    merkle_root        // one hash committing to every tx in this block
    timestamp          // when the block was assembled
    difficulty_target  // how hard the puzzle was      → Guide 2
    nonce              // the number miners vary to win it → Guide 2
}

Most of those fields are bookkeeping. One is the entire trick. prev_block_hash is the hash of the previous block's header — so every block's identity includes its parent's fingerprint. And the parent's fingerprint included its parent's, all the way back. The newest block therefore commits, transitively, to the complete history behind it. That's why it's a chain: not blocks sitting in a row, but each block cryptographically welded to the one before it.

Here's what that buys you. Tamper with a transaction in an old block and its merkle_root changes, so the block's header hash changes, so the next block's prev_block_hash no longer matches — and that mismatch cascades all the way to the tip. You cannot quietly edit one page of the ledger. To make a forged edit "fit," you'd have to re-forge every block after it, in every copy, faster than the whole network keeps extending the real chain. Try it — edit any transaction and watch the break spread:

That cascade is the reason a blockchain is called immutable: not because editing is forbidden by some rule, but because a single change invalidates everything downstream and is instantly visible to every other copy. The re-chain button papers over it locally; on the real network, re-linking means redoing work the rest of the world isn't going to wait for.

Merkle trees, briefly. How does one merkle_root commit to a thousand transactions? Pair them up, hash each pair, then pair up those hashes, and repeat until a single root hash remains. The payoff is efficiency: you can prove "my transaction is in this block" with about log₂(n) hashes — roughly 10 hashes for 1,000 transactions, not 1,000. That's how a wallet on your phone can verify a payment without downloading the entire chain.

The lifecycle of a payment. Your wallet signs a transaction → it's broadcast to peer nodes → it waits in each node's mempool (the waiting room of unconfirmed transactions) → a block producer picks it up and includes it in a block → the block propagates to everyone → and each further block built on top is one more confirmation that it's settled.

Here's that guarantee as the code every node runs — notice that "who produced the block" appears nowhere in it:

def validate_chain(blocks):          // every full node runs this, independently
    for b in blocks:
        if b.prev_hash != hash(b.parent):   // 1. is the link intact?
            return REJECT                     //    one tampered tx breaks every child
        if hash(b.header) > b.target:       // 2. was the work actually done? → Guide 2
            return REJECT
        for tx in b.transactions:           // 3. is every payment legitimate?
            if not verify_signature(tx):     //    forged? rejected — no matter who mined it
                return REJECT
            if double_spent(tx):            //    coin already spent? rejected
                return REJECT
    return ACCEPT                          // rules enforced at the edges, not by the powerful

One more distinction you'll meet everywhere. Chains disagree on what the ledger tracks:

Two copies of the ledger can both be internally flawless and still contradict each other. Alice signs two perfectly valid transactions spending the same coin — one paying Bob, one paying herself back — and shows each half of the network a different one first. Both are properly signed. Neither is a forgery. The network just has to agree on which happened first, because only one can stand. This is the double-spend problem in its true form: not forgery, but ordering.

Computer science has studied this for forty years as the Byzantine generals problem: armies encircling a city must agree on a single plan — attack or retreat — by messenger, while some messengers may be traitors delivering contradictory orders. The classic results all assumed a known, fixed set of participants who could vote. The open internet offers neither.

Why "just vote" fails — the Sybil attack. On the internet, identities are free. Anyone can spin up a million "nodes" for pocket change. So any one-node-one-vote scheme is instantly won by whoever runs the most virtual machines — democracy is meaningless when you can mint a billion citizens. This single fact is why blockchains look so strange: they can't count identities, so they have to count something that can't be faked.

How disagreement actually resolves — fork choice. Suppose two block producers find a valid block at nearly the same instant. The network briefly splits, some nodes building on one, some on the other. No committee convenes. Each side just keeps building, and whichever branch attracts the next block first becomes the longest (heaviest) chain — and by a rule every node follows, everyone abandons the shorter branch and switches to it. The stranded block is orphaned; its transactions fall back into the mempool to be included later. Agreement is not negotiated; it emerges from one greedy rule applied identically by everyone.

Which means "final" is a probability, not a fact. A transaction one block deep can still be undone if a competing branch overtakes it. Six blocks deep, an attacker would have to out-produce the entire honest network for about an hour straight to rewrite it — possible in theory, absurdly expensive in practice. So confirmations don't make a payment certainly irreversible; they make reversing it exponentially more expensive with each block. (Hold that thought — Guide 3 shows how proof-of-stake replaces this probabilistic finality with a mathematical one.)

Everything above is the machine. These pods are the truths the machine's design implies but rarely states out loud — including the one that finally answers "how can something with no owner be legitimate?"