Cryptography Primer

Bitcoin does not “store passwords on the blockchain.” Ownership is proven with cryptography: one-way hashes and signatures that anyone can verify, but only the key holder can create.

Why this matters

Every wallet bug that loses funds usually traces back to misunderstanding keys, hashes, or signatures. You do not need a PhD, you need clear mental models.

Analogy

A hash is like a fingerprint of data: same input → same fingerprint; tiny change → totally different fingerprint; fingerprint does not reveal the original.

A digital signature is like a wax seal: anyone can check the seal matches the letter and the author’s public stamp, but only the author has the private seal.

Hashes in Bitcoin

Bitcoin leans on SHA-256 and RIPEMD-160 (often as HASH160 = RIPEMD160(SHA256(x))). Hashes identify transactions, blocks, and scripts. They also commit to data without revealing it early (for example, Lightning payment hashes).

// Conceptual, use audited libraries in production
type Hash256 = string; // 32-byte digest hex
 
function commitsTo(data: Uint8Array, digest: Hash256): boolean {
  // true if sha256(data) === digest
  return true;
}

Keys and signatures

Bitcoin historically used ECDSA on the secp256k1 curve. Taproot prefers Schnorr signatures (BIP-340): smaller, linear (friendly to aggregation), and cleaner security proofs.

What builders must remember

1. Private keys are secrets, treat them like cash and passwords combined.
2. Public keys and addresses are safe to share for receiving.
3. Signatures authorize specific messages (transaction sighashes), not blank checks.
4. Hash collisions are astronomically unlikely for SHA-256 in practice; treat digests as unique IDs.

Common mistakes

• Confusing encryption (hiding data) with signatures (proving authorship)
• Reusing nonces in ECDSA (catastrophic key leaks historically)
• Assuming “hashed” means “secret”, hashes of low-entropy secrets can be guessed

Worked mental model

Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

Hands-on habit

Every protocol idea should be paired with one local experiment:

1. Reproduce the happy path on regtest (or Polar for Lightning)
2. Break it on purpose (wrong fee, expired invoice, offline peer)
3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)

That habit turns reading into builder instinct.

Glossary check

Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

Resource order

Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Next steps

With crypto intuition in place, learn Bitcoin’s economic incentives, supply, fees, and why miners secure the chain, then dive into UTXOs.