Lesson 4 — The Cryptographic Foundation
How Does Blockchain Actually Work?
Learning Material
1 pagesLesson 4 — The Cryptographic Foundation
Understanding the Complex: How Does Blockchain Actually Work?
Alice wants to send Bob 0.1 Bitcoin.
Let's follow that transaction from the moment Alice decides to send it — through the cryptography — to the point where the network accepts it as legitimate. This is the technical core of what blockchains do, and it becomes concrete very quickly.
Step 1: Alice's keys
When Alice set up her Bitcoin wallet, software generated two mathematically related numbers: a private key and a public key.
The private key is a random 256-bit number — essentially a very large integer. Think of it as a secret only Alice knows. The public key is derived from it through a mathematical operation called elliptic curve multiplication: a one-way process, meaning you can compute the public key from the private key, but not the reverse. Alice's Bitcoin address — the string of letters and numbers she shares with others to receive funds — is derived from her public key through two successive hash functions.
Here's the crucial security property: even if you know Alice's public key and her Bitcoin address, you cannot reconstruct her private key. The mathematics is structured so that reversing the derivation would require more computational work than all the computers on Earth could perform in the lifetime of the universe.
Step 2: The transaction message
When Alice initiates the transfer, her wallet software creates a transaction record containing:
- The source of the funds (which previous transaction sent Bitcoin to Alice's address)
- The destination (Bob's Bitcoin address)
- The amount (0.1 BTC)
- A small fee for the miners who will process the transaction
This transaction record is a plain text message. Anyone can read it. It contains no passwords.
Step 3: The digital signature
Before broadcasting the transaction, Alice's wallet software signs it with her private key.
The signing process works like this: the wallet computes the SHA-256 hash of the transaction message — a 256-bit fingerprint. It then applies a mathematical operation using Alice's private key to that hash, producing a digital signature. This signature is attached to the transaction message.
Anyone — any node on the Bitcoin network — can now verify the signature using Alice's public key, which is derived from her address. The verification confirms: yes, this signature could only have been produced by someone who controls the private key corresponding to this public key. Alice authorized this transaction.
What makes this remarkable is that Alice never reveals her private key. The signature proves she controls the key without exposing it — the way a wax seal proves a letter came from a particular sender without revealing the stamp itself.
Step 4: The hash function's role
Why sign the hash of the message rather than the message itself? Two reasons.
First, practical: digital signature algorithms work on fixed-length inputs. The hash function converts any message — one word or one million — into a standard 256-bit block.
Second, security: the avalanche effect means that any modification to the transaction — even changing the amount from 0.1 BTC to 0.11 BTC — produces a completely different hash, which invalidates the signature. An attacker can't intercept the transaction and change the amount without Alice's private key to re-sign it.
This is what the avalanche effect means in practice. Run the sentence "Alice sends Bob 0.1 Bitcoin" through SHA-256 and you get a particular hash. Change one character — "Alice sends Bob 0.2 Bitcoin" — and the hash is completely different, with no resemblance to the original. There's no gradient, no incremental change. It's a cliff edge.
Step 5: What the network checks
When Alice's signed transaction reaches other Bitcoin nodes, each node independently verifies:
- Signature validity: Does the digital signature match the transaction content and the public key?
- Ownership: Does the referenced input transaction actually send funds to Alice's address?
- No double-spending: Has Alice already spent these funds in another transaction that's been confirmed?
If all three checks pass, the transaction is valid and gets forwarded to other nodes. Eventually it reaches miners, who collect it along with thousands of other pending transactions, bundle them into a block, and compete to add that block to the chain.
The chain itself
Each block in the blockchain contains a header with — among other things — the hash of the previous block's header. This creates the chain: block 500 contains the hash of block 499's header, which contains the hash of block 498's header, and so on back to block 0 (the "genesis block" Nakamoto mined on January 3, 2009).
If someone wanted to retroactively alter a transaction in block 450, they would need to:
- Recompute block 450's hash (easy)
- Recompute block 451's hash, because it contains block 450's hash (easy)
- Continue recomputing all subsequent blocks — currently over 800,000 of them
- Do this faster than the rest of the network is adding new blocks (not easy)
The chain structure, combined with the computational cost of adding blocks (more on this in the next lesson), is what makes the blockchain immutable in practice.
The cryptography here is not exotic. Hash functions and digital signatures existed decades before Bitcoin. What Nakamoto's design did was combine them in a specific architecture — a chain of cryptographically linked blocks, transactions signed with private keys — and add a clever mechanism for distributed nodes to agree on which chain is the valid one.
That agreement mechanism — consensus — is the subject of the next lesson. It's where the real engineering innovation lies.
Next lesson: Consensus — how thousands of independent computers agree on which version of the blockchain is true, what mining actually is, and why Bitcoin uses as much electricity as some countries (deliberately).
Reading time: approx. 9–10 minutes