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.
Complete Step 1 // Required reading in the study plan above (and the interactive hash lab when listed there). Optional tools sit under further reading beneath the article.
Step 2 — Core idea: hashes, keys, and verify
| Term | Meaning | Bitcoin use |
|---|---|---|
| Hash | Fingerprint of data; one-way | Txids, block ids, script commits |
| Private key | Secret that can sign | Spend authority |
| Public key | Derived from private; safe to share for verify | Addresses / outputs |
| ECDSA | Historical signature scheme | Pre-Taproot |
| Schnorr (BIP-340) | Taproot’s preferred signatures | Smaller, aggregation-friendly |
Analogy: A hash is a fingerprint; a signature is a wax seal — anyone can check it, only the private seal can create it.
// Conceptual — use audited libraries in production
type Hash256 = string;
function commitsTo(data: Uint8Array, digest: Hash256): boolean {
// true if sha256(data) === digest
return true;
}Loading diagram…
Remember: private keys are secrets; signatures authorize specific sighashes; treat SHA-256 digests as unique IDs in practice.
Done when: You can walk the Mermaid diagram out loud without notes.
Step 3 — Try it and capture lab evidence
- Re-open the required hash-functions lab if needed; optionally use the SHA-256 visualizer from further reading.
- Locally hash a known string; record input + digest.
- Derive a lab-only address or pubkey on regtest/testnet; discard that key material.
Common mistakes
- Confusing encryption with signatures
- Reusing ECDSA nonces
- Assuming “hashed” means “secret” for low-entropy inputs
Done when: Lab evidence is complete and you would refuse to reuse the lab key.
Next lesson
Learn Bitcoin Economics — supply, fees, and why miners secure the chain — then dive into UTXOs.