Private keys and elliptic curves: a deep-dive for people who don't like math

If you ever wondered how elliptic curves and private keys actually work, and you never liked math like me - let's try to get the idea without too much of it.

First: why does any of this exist?

Blockchain needs to solve one problem: how do you prove you own something without telling anyone your secret?

Your private key is the secret. Your public key (and address) is what you share with the world. The cryptography underneath ensures that knowing your public key reveals absolutely nothing about your private key - even though one is mathematically derived from the other.

The math that makes this possible relies on specific properties of algebraic structures that are easy to compute in one direction but practically impossible to reverse.

1. What even is a private key?

A private key is just a number. An absurdly large number - on Bitcoin's curve, it's a random integer between 1 and roughly:

115792089237316195423570985008687907852837564279074904382605163141518161494337

You can think of it as a 256-bit random number. If you somehow guessed everyone's private key by brute force, you'd need to try more combinations than there are atoms in the observable universe. So that's fine. Very secure. Moving on.

The public key is derived from the private key - we'll come back to exactly how at the end of the article. For now, let's focus on the private key itself and how it's possible that everyone gets a unique one.

2. Elliptic curves: a special kind of function

Elliptic curves are the foundation of all this. Think of them as a twisted version of the linear function you know from primary school.

You know linear functions. y = ax + b. Grows in a straight line. Boring but useful.

You probably also know quadratics - parabolas and such. Those grow faster, curve around, have some nice properties.

Elliptic curves are a different beast entirely. The general form used in cryptography is called the Weierstrass form:

y² = x³ + ax + b

For Bitcoin specifically (the secp256k1 curve), a = 0 and b = 7, giving you:

y² = x³ + 7

secp256k1 is just a specific name for this particular curve with this particular formula. The math behind elliptic curve cryptography was once purely theoretical academic stuff - until someone applied it in web3 to build magic internet money.

Plot that over real numbers and you get something that looks like a smooth, continuous snake curving through the plane - symmetric about the x-axis, because squaring y means both +y and -y are solutions.

Elliptic curves are also used in tons of places outside blockchain - TLS, SSH, Signal encryption - but in this post we only care about one thing they can do: a weird kind of arithmetic that's hard to reverse.

Correctness note: The curve equation you often see written as y² = ax³ + 7 is slightly off. The a coefficient belongs to the x term, not the x³ term. The actual secp256k1 curve is y² = x³ + 7. Small difference, matters if you implement it.

3. Point addition: geometry as arithmetic

Here's where elliptic curves get interesting.

You can "add" two points on an elliptic curve together. This sounds made up, but it has a precise geometric definition:

To add point P and point Q:

1. Draw a straight line through P and Q
2. That line intersects the curve at exactly one more point
3. Reflect that intersection point across the x-axis
4. That reflected point is P + Q

This is not addition in any normal sense. No numbers are being summed. You're doing geometry, and calling it addition - but it behaves like addition (associative, commutative, has an identity element), so mathematicians are happy to call it that.

The interactive below shows this:

λ = (y₂ - y₁) / (x₂ - x₁)

x₃ = λ² - x₁ - x₂
y₃ = λ(x₁ - x₃) - y₁

4. Scalar multiplication: the secret weapon

Now that we can add two points, we can do scalar multiplication: multiplying a point by a number k means adding it to itself k times.

k × P = P + P + P + ... (k times)

This is the core operation in elliptic curve cryptography. If G is a fixed starting point on the curve (called the generator point - the same for everyone using secp256k1), and k is your private key, then:

Public Key = k × G

That's it. Your public key is the result of scalar-multiplying the generator point by your private key.

Now here's the key question your brain is probably asking: "If I know G and I know the public key, can't I just figure out k by reversing the multiplication?"

And here's where it gets delicious.

In principle, yes. If you had infinite time and infinite compute, you could just try every value of k from 1 upward until you found one that produced your public key. This is called the Discrete Logarithm Problem.

In practice, no - because of finite fields. Which brings us to the twist.

5. Finite fields: the real story

Now here's the moment of truth. The elliptic curve you've probably seen thousands of times - that smooth snake shape - is not real. There is no real snake-shaped elliptic curve in blockchain. That's why what follows matters.

Here's the truth: The elliptic curve operations in Bitcoin and Ethereum don't happen over real numbers. They happen over a finite field - also called a Galois field or prime field, written as GF(p) or 𝔽ₚ.

What's a finite field?

A finite field is a "closed universe" of numbers with specific rules:

• It contains exactly p elements (where p is a prime number)
• All arithmetic is done modulo p - meaning results "wrap around" when they exceed p
• Every element has a multiplicative inverse (division always works)
• The set is closed: you can never escape it through arithmetic

Think of modular arithmetic like a clock - or like an unsigned integer that overflows. If your variable holds values 0 through 7, then:

4 + 4 = 8 → wraps to 0
4 + 6 = 10 → wraps to 2
7 + 7 = 14 → wraps to 6

This is arithmetic modulo 8 - every result is taken mod 8.

Why this matters for cryptography

Here's the clever bit. Say someone knows you did some additions modulo 8, and the result is 4. They can't tell whether you computed:

• 1 + 3
• 4 + 0
• 2 + 2
• 4 + 8 (one full wrap)
• 4 + 16 (two wraps)
• 4 + 10000000 (a lot of wraps)

You cannot recover the inputs from the output. The modular wrapping destroys that information. This is one of the ways to construct trapdoor (one-way) functions in cryptography.

Bitcoin's prime p is:

p = 2²⁵⁶ - 2³² - 977

That's not 8 possible values. That's a number with 77 decimal digits. The wrapping is... extensive.

6. Elliptic curves over finite fields: the spilled rice

Here's what happens when you take the elliptic curve equation and restrict it to a finite field:

Instead of computing y² = x³ + 7 over all real numbers (giving you a smooth curve), you compute it over integers mod p - meaning x and y can only be integers from 0 to p-1, and the = sign means "equals modulo p."

The result looks nothing like a snake. It looks like rice that someone spilled on a floor - a scatter of disconnected points with no obvious pattern. There's no adjacency, no gradient, no smooth path you could walk along. Each point lands somewhere based on the modular arithmetic, which causes values to wrap around unpredictably.

This is still technically an "elliptic curve" - the same algebraic structure applies, point addition still works, the formula still holds - but geometrically, it's unrecognizable.

Why does the spilled rice matter?

On a smooth curve, you might imagine "walking backwards" from the public key to the private key - following the curve, tracing the path of scalar multiplications. There's a visual intuition for reversal.

On the spilled rice? There's no path. There's no adjacency. You can't walk anywhere. You can only try individual points at random and check if they match.

With p having 77 decimal digits, there are roughly p/2 valid curve points. The number of multiplications you'd need to try to brute-force a 256-bit private key is astronomically large. This is the Elliptic Curve Discrete Logarithm Problem (ECDLP), and no efficient algorithm is known to solve it.

7. The full picture: private key → public key → address

Let's tie it all together.

The generator point G is a specific point on the secp256k1 curve, hardcoded into the protocol. Everyone using Bitcoin uses the exact same G. It's not secret - it's published in the spec.

Your private key k is a random 256-bit integer you (or your wallet) generates. It's the secret. Guard it with your life and then also your death.

Your public key is computed as:

Public Key = k × G

Where × is scalar multiplication over the elliptic curve, operating in the finite field GF(p).

Knowing G and the public key, recovering k requires solving ECDLP - which is computationally infeasible with current (and foreseeable) technology.

Your address is derived from the public key through hashing (SHA-256 then RIPEMD-160 on Bitcoin, Keccak-256 on Ethereum), plus some encoding. Hashing is a separate one-way function layered on top - addresses are shorter than public keys, and even if some theoretical attack broke ECDLP (the Elliptic Curve Discrete Logarithm Problem described above), the hash layer provides an extra barrier.

The full chain:

Random number k (secret)
      ↓  scalar multiplication (one-way)
Public Key (shareable)
      ↓  hashing (one-way)
Address (shareable)

Each arrow is a one-way function. None can be reversed. That's the whole system.

What's next: digital signatures

Everything above is the foundation for understanding digital signatures - a critical part of how blockchains actually work. Every transaction you send is signed with your private key, and anyone can verify that signature using your public key without ever learning the key itself.

The next post will explain how that signing process works on top of the elliptic curve math we covered here.