Cryptography & Bitcoin

Every Bitcoin transaction is secured by Elliptic Curve Cryptography (ECC). Your private key is a number. Your public key is a point on an elliptic curve, derived from your private key through a mathematical operation that's trivial in one direction and computationally infeasible in the other. This asymmetry — easy to compute, impossible to reverse — is what lets you prove you own bitcoin without revealing your private key.

The Elliptic Curve Bitcoin Uses: secp256k1

Bitcoin uses the secp256k1 curve, defined by the equation y² = x³ + 7 over a finite field of prime order. "secp" stands for Standards for Efficient Cryptography; "256" for 256-bit security; "k1" for Koblitz curve type 1. Satoshi chose this specific curve — notably not the more commonly used NIST curves — for efficiency and because it avoided curves potentially weakened by known-bad parameters. Private keys are 256-bit integers; public keys are points derived via one-way multiplication, secured by SHA-256 hashing in the broader protocol.

• Private key: a randomly chosen 256-bit number (1 to ~10⁷⁷)
• Public key: private key multiplied by the generator point G on secp256k1
• The multiplication is point addition on the curve — one-way by the ECDLP (Elliptic Curve Discrete Logarithm Problem)

Why ECC Over RSA?

RSA (the older standard) requires 2048+ bit keys for equivalent security. ECC achieves the same security with 256-bit keys — dramatically more efficient. Bitcoin processes millions of signature verifications; smaller keys mean faster validation, smaller transactions, and lower fees. ECC's efficiency was the right choice for a global payment protocol.

"The entire security of Bitcoin rests on one mathematical assumption: that computing the elliptic curve discrete logarithm is computationally infeasible with today's (and near-future) hardware." — Bitcoin cryptographic foundation

Want to go deeper?

• Bitcoin cryptography — lopp.net
• secp256k1 — Bitcoin wiki

SHA-256 (Secure Hash Algorithm, 256-bit) is the hash function at the heart of Bitcoin's proof-of-work and transaction identification. A hash function takes any input of any size and produces a fixed-length output that appears completely random — yet is deterministic (the same input always gives the same output) and practically impossible to reverse. SHA-256 is used twice (double-SHA-256) in Bitcoin's core operations.

SHA-256 Properties

Where Bitcoin Uses SHA-256

• Mining (Proof of Work): Miners hash block headers (double-SHA-256) to find a hash below the target
• Transaction IDs (TXIDs): Each transaction is identified by the double-SHA-256 of its serialised data
• Block IDs: Each block is identified by the double-SHA-256 of its header
• Merkle trees: SHA-256 builds the Merkle root that commits all transactions in a block
• Script opcode: OP_SHA256 and OP_HASH256 allow scripts to require specific hash pre-images

SHA-256 in Action

The same input always produces the same output, and a tiny change produces a completely different hash:

# SHA-256 of "hello"
Input:  "hello"
Output: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

# SHA-256 of "hello " (one extra space)
Input:  "hello "
Output: 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03

# Double-SHA-256 (as Bitcoin uses for TXIDs and block hashes)
SHA256(SHA256("hello")) =
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50

Simplified Signing Flow (Pseudocode)

# Key generation
private_key  = random 256-bit integer
public_key   = private_key × G   # G = secp256k1 generator point

# Signing a transaction
tx_hash      = SHA256(SHA256(serialized_transaction))
signature    = ECDSA_sign(tx_hash, private_key)
# Result: (r, s) pair — 64 bytes in Schnorr, ~71 bytes in ECDSA

# Verification (anyone can do this with only the public key)
valid = ECDSA_verify(tx_hash, signature, public_key)
# True = the signer knows private_key, without revealing it

"SHA-256 is the cryptographic bedrock of Bitcoin. Satoshi's choice of it was sound — it remains unbroken after 20+ years of intense scrutiny." — Bitcoin cryptography note

Want to go deeper?

• Bitcoin cryptography — lopp.net
• SHA-256 — Bitcoin wiki

Elliptic Curve Digital Signature Algorithm (ECDSA) is the signature scheme Bitcoin used from its launch in 2009 until the 2021 Taproot upgrade introduced Schnorr signatures. ECDSA is how you prove you own a private key without revealing it — and therefore how you authorise the spending of bitcoin. Understanding ECDSA means understanding the mathematical proof of ownership that underlies every Bitcoin transaction.

How ECDSA Signing Works (Simplified)

1. You have a private key k and want to sign message m (a transaction hash)
2. Choose a random nonce r (this is critical — reusing r can expose your private key)
3. Compute a point R = r × G on the curve; take R's x-coordinate as r_x
4. Compute s = (hash(m) + k × r_x) / r (mod curve order)
5. Signature = (r_x, s)

Verification uses your public key to confirm the signature is valid for that specific message (transaction) without revealing k.

The Nonce Reuse Vulnerability

ECDSA has a critical weakness: if the same nonce r is used to sign two different messages with the same private key, the private key can be mathematically extracted from the two signatures. This is not theoretical — it caused the PlayStation 3's ECDSA implementation to be broken in 2010 (Sony reused nonces), and has caused Bitcoin key compromises in the past. Good ECDSA implementations use deterministic nonce generation (RFC 6979) to prevent this.

"ECDSA is secure when implemented correctly. But it demands perfect randomness, and 'correctly' is harder than it sounds. This is why Schnorr signatures are an improvement." — Bitcoin cryptography

Want to go deeper?

• Bitcoin cryptography — lopp.net
• ECDSA — Bitcoin wiki

With the Taproot upgrade in November 2021, Bitcoin gained support for Schnorr signatures — a mathematically cleaner, more efficient, and more privacy-preserving signature scheme than ECDSA. Schnorr signatures were patented until 2008 (one reason Satoshi used ECDSA instead), but once patents expired and the cryptographic community had thoroughly reviewed them, the case for adding Schnorr to Bitcoin became compelling.

ECDSA vs Schnorr: Side-by-Side

Why Schnorr Is Better Than ECDSA

• Linearity: Schnorr signatures are linear — multiple signatures from multiple keys can be combined into a single signature (signature aggregation). ECDSA signatures cannot be combined.
• Provable security: Schnorr signatures have a tighter, cleaner security proof. ECDSA's security proof is less tight and depends on additional assumptions.
• No nonce reuse vulnerability: Schnorr's security model handles this more cleanly.
• Smaller multisig transactions: A 3-of-3 multisig with Schnorr looks identical to a single-key signature on-chain — better privacy and lower fees.

Key Aggregation and MuSig

Schnorr's linearity enables MuSig (Multi-Signature) protocols where multiple participants jointly create a single Schnorr signature. A 2-of-2 MuSig looks like a regular single-key signature on-chain — indistinguishable from a simple payment. This dramatically improves the privacy of multisig wallets and collaborative transactions.

"Schnorr signatures are to ECDSA what a clean architectural redesign is to legacy code. Same security assumption, better everything else." — Bitcoin cryptography researcher

Want to go deeper?

• Bitcoin cryptography — lopp.net
• BIP 340 — Schnorr Signatures for secp256k1

Every Bitcoin block contains potentially thousands of transactions. How does a single 32-byte hash in the block header "commit" to all of them? The answer is a Merkle tree — an elegant data structure named after Ralph Merkle that allows a compact proof of inclusion for any transaction in the block, without needing to download the entire block.

How a Merkle Tree Is Built

1. Hash each transaction: TXID = double-SHA256(serialised transaction)
2. Pair adjacent TXIDs and hash each pair: SHA256(SHA256(TXID_1 || TXID_2))
3. Repeat the pairing and hashing until one hash remains — the Merkle root
4. The Merkle root is stored in the block header

For an odd number of transactions, the last transaction is duplicated to make the tree balanced.

Merkle Proofs: Efficient Verification

The Merkle tree structure enables SPV (Simplified Payment Verification) proofs. To prove transaction T is in a block, you only need: T's hash, and the "Merkle path" — the sibling hashes along the path from T to the root. An SPV client can verify T is in the block with O(log n) hashes instead of downloading all n transactions.

"The Merkle tree allows Bitcoin's block header to be a commitment to thousands of transactions in just 32 bytes. It's one of Bitcoin's most elegant cryptographic building blocks." — Bitcoin technical analysis

Want to go deeper?

• Bitcoin cryptography — lopp.net
• Merkle trees — Bitcoin wiki

Bitcoin's entire security model is built on cryptographic proofs — mathematical demonstrations that can be verified by anyone without trusting anyone. From digital signatures to hash commitments to Merkle proofs, every claim in Bitcoin is verifiable from first principles. This is what "trustless" means in Bitcoin: you don't need to trust anyone's word, only their mathematics.

Types of Cryptographic Proofs in Bitcoin

• Digital signatures: Prove ownership of a private key without revealing it. Every Bitcoin input includes a signature that proves the spender controls the corresponding key.
• Proof of Work: Proves that computational work was expended to produce a block. Verifiable in a single hash computation.
• Merkle proofs: Prove a transaction is included in a block using only O(log n) hashes.
• Script satisfaction: Prove an unlocking script satisfies the locking conditions of an output.
• Chain of block hashes: Proves the ordering and history of blocks — each block commits to all previous blocks.

Zero-Knowledge Proofs: The Future Layer

Zero-knowledge proofs (ZKPs) allow proving a statement is true without revealing the underlying data — e.g., "I know the pre-image of this hash" without revealing the pre-image. ZKPs are being researched for potential Bitcoin applications: more private transactions, more efficient light clients, and new scripting possibilities. As of 2026, ZKPs remain an active research area for Bitcoin, though not yet part of the base protocol.

"Bitcoin's magic is that everything is proven, nothing is trusted. The entire financial history of Bitcoin can be verified from scratch by anyone with a computer." — Bitcoin cypherpunk philosophy

Want to go deeper?

• Bitcoin cryptography — lopp.net
• Bitcoin Whitepaper — cryptographic proofs throughout