This chapter introduces elliptic curves defined over finite fields and explains why they form the mathematical backbone of Bitcoin’s cryptography. While elliptic curves over real numbers appear smooth and continuous, applying the same equations over a finite field creates a discrete, scattered set of points. Despite the visual difference, all point addition formulas, slopes, and algebraic rules behave exactly the same—only the arithmetic changes to modular arithmetic. Bitcoin uses the curve y² = x³ + 7 (secp256k1), which preserves symmetry and nonlinear behavior essential for cryptographic security.

A point lies on a finite-field elliptic curve if its coordinates satisfy the curve equation under modulo p. Verifying a point such as (73,128) on F₁₃₇ requires checking that y² mod p equals x³ + 7 mod p. Implementing this in code involves creating classes for finite field elements and curve points. Operator overloading ensures that all arithmetic—addition, multiplication, exponentiation, division—is automatically performed modulo p. Once these abstractions exist, more advanced cryptographic operations become straightforward to write and reason about.

Elliptic curve points form a mathematical group under addition. The group satisfies closure, associativity, identity (the point at infinity), and inverses (reflection across the x-axis). Geometric constructions confirm these properties, making scalar multiplication (P added to itself repeatedly) well defined. These group rules enable elliptic curve cryptography and ensure consistent, predictable behavior under repeated point operations.

Choosing a generator point G on a curve allows us to generate a cyclic group: G, 2G, 3G, …, nG = 0. The points appear nonlinear and unpredictable, even when generated sequentially. This unpredictability creates the foundation for the discrete logarithm problem: computing P = sG is easy, but determining s from P is computationally infeasible for large groups. This one‑way function is what makes public key cryptography secure. Scalars (private keys) are written in lowercase; points (public keys) in uppercase.

To compute sG efficiently, implementations use the double‑and‑add algorithm: scanning the scalar’s binary representation, doubling the point each step, and adding G only when the bit is 1. This reduces computation from O(n) additions to O(log n), enabling practical cryptographic operations even with 256‑bit scalars.

Bitcoin uses the curve secp256k1, defined by y² = x³ + 7 over a prime field where p = 2²⁵⁶ − 2³² − 977. The generator point G has fixed coordinates chosen using a deterministic NUMS (“nothing up my sleeve”) procedure. The group order n is a large prime close to 2²⁵⁶, ensuring that every nonzero point generates the same group. The size of 2²⁵⁶ (~10⁷⁷) is astronomically large, making brute‑forcing private keys physically impossible. Even a trillion supercomputers running for a trillion years would not meaningfully reduce the key space.

A private key is a random scalar s; the public key is P = sG. Because solving the discrete log problem is infeasible, P can be shared without revealing s. Public keys must be serialized for transmission using SEC format. Uncompressed SEC format uses 65 bytes: prefix 0x04 + x‑coordinate + y‑coordinate. The compressed format uses only 33 bytes: prefix 0x02 or 0x03 (depending on y’s parity) + x‑coordinate. Bitcoin originally used uncompressed keys but now prefers compressed ones for efficiency.

Bitcoin addresses are hashes of public keys, not the raw keys themselves. To generate an address, serialize the public key in SEC format, compute hash160 (SHA‑256 then RIPEMD‑160), prepend the network prefix (0x00 for mainnet, 0x6F for testnet), compute a checksum using double SHA‑256, append the first four checksum bytes, and encode the result using Base58. This encoding removes ambiguous characters and includes the checksum to prevent transcription errors. The multi‑step pipeline hides the public key until a spend occurs, adds network identification, and ensures human‑readable, error‑resistant addresses.