The cryptography of Bitcoin

Bitcoin stands on three pillars: a peer-to-peer network, a consensus mechanism, and a cryptographic foundation. This article takes that foundation apart. Not to teach you how to implement SHA-256 — to make sure you know what’s inside, why these algorithms and not others, and what would collapse if any of them broke.

We’ll cover five building blocks: the hash function SHA-256, the elliptic curve secp256k1, the signature scheme ECDSA, its modern replacement Schnorr (BIP340, activated in 2021), and the chain that turns a public key into a Bitcoin address. By the end, you’ll have a complete view of what Bitcoin does every time a transaction is signed.

SHA-256: the cement that binds everything

SHA-256 (Secure Hash Algorithm, 256 bits) is everywhere in Bitcoin: it hashes blocks for mining, identifies transactions, helps derive addresses, signs messages. Remove SHA-256 from Bitcoin and nothing is left.

It’s a function that takes any binary input and always outputs 256 bits. For the general properties (determinism, avalanche effect, irreversibility), I refer you to the side-quest. Here we formalize the three cryptographic properties that Bitcoin demands of it, in their precise statement:

1. Preimage resistance (one-way) — given a hash h, it’s infeasible to find a message m such that SHA256(m) = h. Expected cost: ≈ 2²⁵⁶ attempts. This is what prevents going back from an address to the public key, as long as you haven’t spent.
2. Second-preimage resistance — given a message m₁, it’s infeasible to find another message m₂ ≠ m₁ such that SHA256(m₂) = SHA256(m₁). Expected cost: ≈ 2²⁵⁶. This is what prevents an attacker from substituting one transaction with another that would yield the same ID.
3. Collision resistance — it’s infeasible to find any two messages m₁ ≠ m₂ such that SHA256(m₁) = SHA256(m₂). Careful — here the expected cost is only ≈ 2¹²⁸ (birthday paradox), not 2²⁵⁶. That’s still wildly out of reach — but it’s why we talk about a 256-bit hash function while aiming at a 128-bit security level.

As long as nobody breaks SHA-256, Bitcoin holds. If someone tomorrow found an exploitable collision, they could forge two blocks with the same ID, or two interchangeable transactions, and the chain would tear apart. More than 30 years after SHA-1 was first published (1995), and after two decades of intense analysis of SHA-256, no practical flaw has been published. The function is considered solid until the arrival of quantum computers running Grover’s algorithm (which would bring security from 256 down to 128 bits — still out of reach, but we’ll come back to that in BTC-A-10 ).

secp256k1: the curve that signs everything

Bitcoin needs digital signatures: prove you’re the owner of the funds you spend, without revealing the key that proves it. For that, we use public-key cryptography over elliptic curves — ECC for short. Satoshi chose a specific curve: secp256k1, with equation y² = x³ + 7 in a finite field modulo a 256-bit prime p.

The choice deserves a pause. When Bitcoin was born (2008), the American cryptographic standard for elliptic-curve signatures was secp256r1 (also called P-256 or prime256v1), a NIST curve. Satoshi deliberately chose secp256k1, a less popular Koblitz curve at the time, recommended by the same SECG but with a different structure.

Scalar multiplication: the one-way lock

On the secp256k1 curve, we define a generator point G (public coordinates, fixed by the standard, identical for everyone). Starting from G, the key operation is scalar multiplication: for an integer k, compute P = k · G — that is, add G to itself k times (with algorithmic shortcuts when k is large, but that’s the idea).

In the direction k → P, it’s easy. With a 256-bit k, this takes a few microseconds on a phone — about 256 doublings and as many additions, ≈ 500 curve operations.

In the reverse direction, it’s infeasible. Given G (public, fixed by the standard) and P (the public key observed on the blockchain), recovering the k that satisfies P = k · G is what’s called the elliptic-curve discrete logarithm problem (ECDLP). No known algorithm does better than ≈ 2¹²⁸ operations on secp256k1 — roughly the number of operations an attacker controlling all the computers on the planet could perform over several lifetimes of the universe.

It’s this easy/impossible asymmetry that underwrites all of Bitcoin’s cryptography:

• Your private key k: a randomly drawn 256-bit integer.
• Your public key P = k · G: the resulting point on the curve.

You share P with the whole world. Nobody can recover k. And you can prove you know k without revealing it — which is the subject of the next chapter.

ECDSA: the original signature

ECDSA (Elliptic Curve Digital Signature Algorithm) is the signature scheme Bitcoin has used since 2009. It takes your private key k, a message m (in practice: the hash of a transaction), and produces a signature (r, s) — two 256-bit integers — that anyone can verify with your public key P.

The algorithm fits in 4 steps. Without the modular-arithmetic details, here’s the logic:

1. Pick a random nonce n between 1 and the group order.
2. Compute the point R = n · G on the curve. Extract R’s x-coordinate, modulo the group order, that gives r.
3. Compute s = n⁻¹ · (hash(m) + r · k) mod q where q is the group order and k your private key.
4. Publish (r, s) with the transaction.

Verification: with P = k · G (your public key) and the message m, anyone can recompute R from (r, s) and P, and check that the x-coordinate matches r. You prove you know k without ever sending it.

The Achilles heel: the nonce

The whole ECDSA edifice rests on one catastrophic condition: the nonce n must be random, unique per signature, and secret. If you use the same n twice to sign two different messages with the same key k, anyone can recover k from the two signatures. It’s elementary algebra: two equations, two unknowns (n and k).

This is not theoretical. In 2010, Sony used a constant nonce (the same value every signature) when signing the PlayStation 3 firmware. Within weeks, the group fail0verflow extracted Sony’s master private key from two firmware signatures and published the result at the 27C3 conference. No more signed updates, no more DRM. A single-parameter implementation mistake, and the entire PS3 chain of trust collapses.

Schnorr / BIP340: the modern signature (since 2021)

ECDSA does the job, but it was chosen in 2008 by elimination: the Schnorr scheme, simpler and more powerful, was under patent until 2008 and saw late adoption. In November 2021, the activation of the Soft-fork Taproot (block 709,632) introduced Schnorr into Bitcoin via BIP340, alongside ECDSA which keeps working.

Three concrete advantages of Schnorr over ECDSA:

1. Provable — Schnorr’s security is formally derived from ECDLP and the random oracle model. ECDSA’s relies on additional, more fragile, assumptions.
2. Linear — the Schnorr signature is linear in the private key, which makes it possible to aggregate multiple signatures into one. This is the basis of MuSig2 (BIP327, assigned in March 2022): N signers can produce a joint signature indistinguishable from a single one. Saves space on the blockchain, and privacy: it no longer shows up as multi-sig.
3. Deterministic by construction — BIP340 specifies a deterministic mode (nonce derived from the message and the key), eliminating the PS3 class of errors by design.

All Taproot transactions (addresses starting with bc1p) use Schnorr. ECDSA remains on the older addresses (1..., 3..., bc1q...) — Bitcoin preserves backward compatibility.

From public key to address

You have a public key P = k · G — a point on secp256k1, two 256-bit numbers, ≈ 130 hex characters. Too long, and reveals the public key directly. Bitcoin hashes the public key into a shorter address, which serves as the destination identifier.

Here’s the chain for a modern SegWit address (P2WPKH, those starting with bc1q…):

1. P (public key, 33 compressed bytes)
2. → SHA-256(P) = 32 bytes
3. → RIPEMD-160(SHA-256(P)) = 20 bytes. This double-application has a name: HASH160. RIPEMD-160 outputs 160 bits, which is plenty for collision resistance while keeping addresses short.
4. → bech32 encoding (BIP173 ) with the bc1q prefix and a 6-character self-correcting checksum. If you make a typo, the wallet catches it before sending.

The final address looks like bc1q9hk...m4xj (42 characters). What you share is that hash — not the public key. The public key itself only becomes visible on the blockchain at the moment you spend from that address. That’s an extra layer of protection: as long as the address hasn’t spent, even a quantum computer breaking ECDLP couldn’t recover the private key — it doesn’t have access to P, only to HASH160(P).

Taproot addresses (bc1p…) use a slightly different encoding, bech32m (BIP350 ), to fix a subtle checksum bug in bech32. Same spirit, different checksum constant.

Recap

When you sign a Bitcoin transaction, here’s what happens under the hood:

1. The wallet serializes the transaction and computes its hash m (double SHA-256).
2. With your private key k, it generates an ECDSA or Schnorr signature of m — proof you authorize the spend.
3. The signature is appended to the transaction and broadcast to the network.
4. Every node verifies the signature using your public key P (derived from the source address via the script of the spent output). If OK, the transaction is valid and can be included in a block.

All in a few milliseconds, and without a single secret leaving your machine.

What’s next

Now that we have the cryptography, we can look at the object it applies to: the Bitcoin transaction, in binary, byte by byte. Inputs, outputs, scripts, nLockTime, weight in vBytes. That’s the subject of BTC-A-02 — Anatomy of a Bitcoin transaction (coming).

This article is not investment advice.