Cryptography: Six Ideas + Two Kinds of Magic

1Hashing · Squish a Fingerprint

Why is "no way back" not just hard but actually impossible? Because a hash squishes something of any length down to a fingerprint of the same length. "Hi" and the whole of The Lord of the Rings both squish down to a fingerprint of the same length. Infinitely many different originals get crammed into the same-sized output — so lots of different originals must land on the same fingerprint. That means: given only the fingerprint, there's no single "right answer" to rebuild.

2Encryption · The Secret Code on the Battlefield

That's encryption: the same agreed-on secret code both locks the order (when sending) and opens it (when reading); an enemy without the code can only stare helplessly. So encryption naturally comes in pairs — where there's a lock there's an open, and both come from one secret code. An "encryption" you can't undo is pointless, because then even your own side can't read it.

This is where it clearly parts ways with hashing:

3Commitment · Seal It Now, Open It Later

Commitment isn't a new building block — it's one way of playing with hashing. Back to the guessing game you've played:

I secretly pick the number 42, then post its fingerprint hash(42) for you to see (that's the commitment). You guess. Only after you guess do I reveal the original 42; you squish the fingerprint again and compare — if it matches, I didn't cheat.

Notice one thing that's easy to miss: a commitment doesn't need to be "decrypted." The original is something I choose to show, not something dug out of the fingerprint — a hash can never spit out the original, but a commitment never asked it to.
So the very same "no way back" property is a fatal flaw for encryption, yet a core strength for commitment.

Trust radius: how far can this game reach?

The real power of a commitment is that it pushes "no cheating" farther and farther out, one layer at a time. Click the three lamps below to see how it goes from face-to-face all the way out to the whole world.

4Public / Private Keys · One Hidden, One Public

Step one: use a "piggy bank" to get the hang of it

Step two: one key can build countless banks

This is where the piggy bank explains things better than a "lock," and it's exactly how Bitcoin really works: your one key can build a whole pile of banks that all look different from each other, and every one of them opens with your one key.

• One wallet, countless addresses: a real Bitcoin wallet derives thousands of addresses from a single seed, all managed by your one master key. "One key opens many banks" is literally what it is.
• A fresh bank each time: precisely because you can build countless banks, you can use a new one every time you receive money, which is crucial for privacy (coming up next).

Step three: two ideas you absolutely must build

About "what someone can do if they find one of your banks," there are two different things, and telling them apart matters a lot:

So a Bitcoin address is used once and then swapped. It's not pointless fuss — even though the key is safe (①), if you always use the same bank to receive all your money, the whole world can see how much goes in and out of that bank (② is broken). Use a fresh bank each time and others can't figure out your stash.

A hook for later: banks naturally don't recognize each other, but if you pour the money from several banks into one new bank, that's like announcing to everyone "these are all mine" — which is exactly what privacy techniques like CoinJoin and change addresses are meant to deal with.

Step four: a bank's "opening conditions" can be designed — this is Script

The neatest thing about the piggy bank: "who, and under what conditions, can open it" can be designed. Behind a Bitcoin address there is really a piece of locking condition that specifies what must be true before it can be spent:

• an ordinary bank = "whoever has this key can open it" (single-sig)
• a safe that needs two keys turned together = multisig (say, 2-of-3)
• a timed bank that only opens on a certain day = timelock
• a bank that opens only for the right secret word = hashlock (the cornerstone of the Lightning Network)

So an address isn't one dead lock, but a "spending-condition contract." Starting from the piggy bank, later on Bitcoin Script is just a smooth extension all the way.

Step five: one thing the piggy bank can't explain — how a private key "gives birth to" a public key

A real bank and its key are made at the same time by the factory; there's no "which gives birth to which." But a real public/private key pair has a direction:

Private key → public key: easy (computed in one step) Public key → private key: almost impossible

And be careful about direction: your key can build countless banks (private key → address, easy going forward); but the other way, whoever finds one of your banks can't work out the key (address → private key, can't be done backward). This "easy to build forward, impossible to figure out backward" is something the piggy bank can't explain — we need a different picture: a special curve, hopping across points on it.

The "multiply / factor" here is about public/private keys — and let's tell it apart from hashing while we're at it

Public/private keys' "easy to build forward, impossible to figure out backward" and "multiplying two numbers is easy, splitting them apart is hard" are the same magic:

Bitcoin uses the "hopping version" (elliptic curves), but the "multiply version" is plenty for building intuition. Both are: lightning-fast forward, hopeless backward. The piggy bank handles the picture and the usage; the hopping handles the direction and the safety — put the two together and public/private keys are complete.

Step six: the same key pair works both ways

This key pair can do more than "lock a letter" — it can also "stamp a seal." The two uses point in exactly opposite directions:

Used forward it's "locking a letter" (encryption); used backward it's "stamping a seal" (signature). Key point: Bitcoin barely uses the "encryption" one — on-chain transactions are public; anyone can see how much moved and to whom; what it protects isn't "hiding the contents" but "only I can spend my money." So what Bitcoin uses every day is signatures, not encryption.

A small correction: strictly speaking, a signature isn't "encrypting with the private key" — it's a different, dedicated bit of math. But the picture of "lock a letter forward, stamp a seal backward" is enough to build the intuition.

★Bonus · Using a "Fingerprint" as a Keytoward the frontier

Someone might ask: isn't a hash also "easy forward, impossible backward"? So could we use it as a public and private key? What a great question — it will lead us all the way to the frontier of cryptography.

Step one: a hash really can be a one-time key

I pick a secret number x at random (private key), compute the fingerprint hash(x), and make it public (public key). Whoever sees the fingerprint can't work backward to x. When I need to prove "I'm the person behind this public key," I reveal x, everyone hashes it, and if it matches → it really is me. This is actually the commitment from Section 3, used as an "ID card."

Step two: we're stuck — and this is exactly the part to really feel

Here's the trouble: to prove it, you have to reveal the secret x; reveal it once and x is burned. Next time you use it, everyone already knows x, and anyone can impersonate you.

Notice the two layers clearly: at the public-key layer, both sides are public (the fingerprint is public / the elliptic-curve public key is also public) — that's not the difference. The whole difference is at the proving layer: hashing makes you reveal the secret along with it, while the private key only reveals a "result computed from the secret." This step is the watershed.

👉 This "prove it while keeping the secret hidden" magic is the next section: signatures.

★Bonus · Why a Quantum Computer Can Crack a Keyplanning ahead

What exactly is a quantum computer? First, clear up three misunderstandings

It's a real machine, not a program. Like the computer on your desk, it's hardware — just with different parts. The key-cracking program (called Shor's) is software running on this machine, and only a quantum machine can run it.

Its parts can be "both 0 and 1." An ordinary computer's smallest unit is a bit, which can only be 0 or 1, like a coin lying flat on the table (heads or tails, nothing in between). A quantum computer's qubit can be in a superposition of 0 and 1, like a coin still spinning, not yet settled — a bit of both. Many spinning coins let you compute many possibilities stacked together at once.

It's not "a faster computer." For gaming, watching videos, doing addition, it's not fast at all — actually slower and more fragile. It has magic only for a tiny handful of special problems.

How can it crack public/private keys? — it heard the lock's rhythm

Back to the clock track from Section 4: the private key is the number of steps, the public key is the endpoint. An ordinary computer (even ten thousand mining rigs) can only "try 1 step, 2 steps… one at a time," and facing 2 to the 256th power positions, it would be trying until the end of the universe.

But this track hides a secret an ordinary computer can't see: it has a rhythm, it repeats. What a quantum computer is best at is precisely spotting "the repeating rhythm" at a glance — it doesn't try one at a time; it lets all the step-counts run in parallel and interfere with each other, and it shakes out this hidden period directly. Once the rhythm is known, working backward to the private key goes from "trying until the end of time" to "a few steps of math."

So why isn't hashing afraid? — it's a rhythmless mess

Hashing has no "repeating rhythm" to hear; it's just a mess, with no period and no structure. Quantum's "find the rhythm" skill is useless here, and it's forced back to brute force — and at brute force it's only a little faster than an ordinary computer (a square-root speedup), which you make up for by doubling the fingerprint's length.

So the same property works both ways: precisely because a hash is "a mess," you can't go backward, and you can only verify after revealing (the weakness from the last section), and precisely because it's "a mess," quantum can't find a rhythm (the shield of this section).

In reality quantum computers are still tiny and fragile — that "spinning coin" collapses back into ordinary heads-or-tails the moment it's heated or shaken (called decoherence), and it only works when cooled to near absolute zero and shielded layer upon layer. It's still several orders of magnitude away from actually cracking Bitcoin. But the threat is real, which is why it's worth defending ahead of time with schemes like hash signatures.

5Digital Signature · Anyone Can Check the Seal, but the Ring Stays With You

First, get this straight: a handwritten signature actually has two holes

We sign our names on contracts every day, but a handwritten signature isn't actually that reliable — it has two big holes, and these are exactly what digital signatures fix:

• Hole one: it can be imitated. Someone can practice your handwriting and copy it pretty well, and the person checking might not tell real from fake.
• Hole two: it can be "peeled off and stuck elsewhere." The name you sign on a contract and the name you sign on an IOU look exactly the same — because the signature has nothing to do with the contents. So someone can peel off the page you signed and stick it onto a different document: "You clearly signed version A, so how did it end up approving version B?" And you can't explain your way out.

Remember these two holes — can be imitated, can be peeled and re-stuck. Below you'll see digital signatures plug each one: "the ring stays with you" plugs imitation, "the signature changes with the contents" plugs peel-and-stick.

The signature changes with the contents — this plugs hole two

Remember that "peel off the signature page" trick at the start? A handwritten signature can be peeled and re-stuck precisely because it has nothing to do with the contents — it's the same signed anywhere. A digital signature is the opposite: it's computed from your private key together with every single character of this document. Change one character, and the whole signature changes. So a digital signature is welded onto this one document, this one version — you can't peel version A's signature and stick it onto version B (stick it on and it's dead the moment it's checked). And that's how the peel-and-stick hole is plugged.

This is exactly how Bitcoin spends money

When you spend Bitcoin, you use your private key to stamp a seal (a signature) on that transfer: "I, the owner of this address, agree to send this money to so-and-so." The whole network checks the stamp with your public key. On-chain transactions are public, and everyone can see them — but:

• Nobody can forge your stamp (without your private key, you can't produce a stamp that passes) → unforgeable; others can't steal or impersonate.
• Change one character and the stamp is void (the signature changes with the contents) → nobody can move your "Send 0.5 to Alice" signature onto "Send 5 to Bob."
• You can't deny it afterward either (the stamp is ironclad proof) → non-repudiable; you can't say "I never signed."

★Bonus · Signing a Message vs Signing a TransactionCHECKSIG / CSFS

A signature was always "stamping a seal on a piece of text"

Signatures were never only for transfers. Their essence is: use a stamp (private key) to stamp a seal on some specified piece of text, and anyone can verify it with the seal-checking lamp (public key). Everyday life is full of it — a teacher stamps "✔read" on this essay, you make your mark on this contract, Apple signs this installer, I attach a signature to this email. The stamped text differs, but the action is the same: stamp with the stamp, check with the lamp, and one changed character kills the stamp.

Signing a transaction vs signing a message: only "who decides that text" differs

The action (stamp / check) is identical; the only difference is who decides the text being stamped. That one sentence is the whole difference between the two opcodes below.

CHECKSIG vs CSFS — two seal-checking lamps

In Bitcoin Script there are two opcodes that verify signatures, both "seal-checking lamps," differing in which sheet of paper the stamp was made for:

CHECKSIG: the lamp is welded to shine only on this transaction　｜　CSFS: whatever you put up, the lamp shines on

Why this is a big deal

CSFS frees signatures from "can only back this transaction" into "can back any statement," turning signatures into a general-purpose building block:

• Bring in external facts: an oracle stamps a seal on "BTC = $100k," and a script verifies it with CSFS → bringing an off-chain fact onto the chain.
• Signatures can be referenced/reused: because it signs a standalone piece of text, not a particular transaction, the same signature can be referenced elsewhere too.
• Assemble a covenant: have a script check "a certain promised text was correctly signed," without relying on the transaction itself — combined with opcodes that can assemble messages (like CAT), you can constrain "money can only be spent in a certain way."

6Zero-Knowledge Proof · Prove It's True Without Leaking Why It's Truethis is a machine, not a building block

The trick is to play a three-step game. Memorize these three steps first — this is the skeleton of every zero-knowledge proof:

That's the key point, and it's why you have to play over and over: play once, and a cheat has a fifty-fifty chance of getting lucky, so you can't believe him. But each extra round, the cheat has to get lucky again — two rounds 1/4, three rounds 1/8, ten rounds only about one in a thousand… Play twenty rounds and he still comes out each time from the direction you randomly specify, and his chance of bluffing is small enough to ignore, so you're almost certain he really knows the spell. And from start to finish you never heard a single word of the spell.

Why is the "commit" step essential? Because if Ali Baba could hear you finish shouting before deciding which side to go, he could go the right way every time even without knowing the spell — he has to lock in his choice before you shout (①) for your on-the-spot challenge (②) to mean anything. This is exactly the use of the commitment from Section 3: lock in first, no takebacks.

But it's different from the guessing-game commitment: that guessing-game commitment has to be opened publicly at the end; this commitment is never opened from start to finish — he locked in "go left or go right," but that choice is never made public; you only see him come out from the direction you specified.

7The Millionaires · Find Out Who Has More Without Saying the NumberYao 1982

Two millionaires want to know who's richer, but neither wants to say how much money they have. Can we compute just the conclusion "who's richer" without leaking each person's number? This is the Millionaires' Problem posed by Andrew Yao, which opened up a whole field called secure multi-party computation (MPC).

We need a new building block: encryption you can compute on

It and zero-knowledge are close siblings, but with different jobs

8Lay Them All Out on One Map

All of cryptography is layered. Grab these three layers and everything afterward has a place to hang:

Essence reconciliation table · three clean cuts through the three easiest to mix up

Put hashing, public/private-key encryption, and public/private-key signatures side by side, and slice them apart in one go with three questions:

Three essentials to remember:

① "Easy forward, hard backward" is the foundation hashing and public/private keys share — hashing is easy forward and hard backward; public/private keys' private key makes the public key easily while going backward is hard. Same magic.

② Hashing is not encryption. It has no key and no decrypt step; it only produces a "data fingerprint." To "open" it, the only way is to reveal the original yourself (reveal), not to decrypt with an algorithm.

③ Hashing's "must be revealed" trait is sometimes a weakness and sometimes a weapon: used as identity/signature → weakness (one-time, which is exactly why real signatures are needed); used as commitment → weapon (revealed only when it should be, otherwise locked down); against quantum → weapon (a rhythmless mess quantum can find no shortcut in). Same property, three scenarios, both sides of the coin.

There's another thread that strings encryption → commitment → zero-knowledge together — "how much you ultimately need to know" decreases all the way down:

The further you go, the less you need to know — that's the "zero" of "zero-knowledge": the knowledge you get is zero, and the certainty you get is full.

TRY IT · IDENTIFICATION QUIZ

You'll get a scenario; guess whether it uses hashing, encryption, or commitment. Answer, see if you're right, then click "next."