ECDSA in Plain English: How secp256k1 Turns a Secret Number Into a Public Key

Every time a wallet signs a transaction, one core system is doing the heavy lifting: ECDSA.

If the name sounds scary, this post is for you.

We will avoid dense math language and focus on intuition:

• what the private key really is
• how a public key is derived from it
• what "elliptic curve multiplication" means in practice
• why everyone can verify your signature, but nobody can fake it

The core idea in one sentence#

Your private key is just a secret number.

Your public key is produced by taking that secret number and applying a special repeatable curve operation many times.

That operation is built so that:

• forward direction is easy (private key -> public key)
• reverse direction is extremely hard (public key -> private key)

What secp256k1 is (without pain)#

secp256k1 is the exact curve setup used by Bitcoin and Ethereum ECDSA.

At a high level, it gives us:

• a huge coordinate space
• one fixed starting point called G (generator point)
• strict rules for how points can be combined

The curve equation is:

y^2 = x^3 + 7 (computed in a huge finite field)

You do not need to do this math by hand. Libraries do it. What matters is understanding the behavior.

What point addition looks like on X-Y coordinates#

Before multiplication, we need one building block: point addition.

Given two points on the curve (P and Q), the geometric rule is:

1. draw a straight line through P and Q
2. that line hits the curve at a third point (-R)
3. mirror that third point across the X-axis
4. mirrored point is R = P + Q

This is a real secp256k1-based view:

• left panel: actual equation shape over real numbers (y^2 = x^3 + 7) with geometric addition intuition
• right panel: actual secp256k1 finite-field points sampled from real multiples of G

So curve "addition" is not normal coordinate addition. It is a special curve rule.

How multiplication is just repeated addition#

When we say:

publicKey = privateKey × G

this does not mean normal multiplication like 7 * 9.

It means repeated point addition on the curve.

If the private key were 13, conceptually it is like:

13 × G = G + G + G + ... (13 times)

So multiplication is just "add the same point many times".

In real implementations, it is done much faster with a method called double-and-add.

How to read this animation:

1. the cyan accumulator dot is the current sum
2. orange motion traces the secant/tangent traversal
3. yellow motion shows the reflection to the next sum point
4. accumulator then moves to that new point (G -> 2G -> 3G -> ...)

A second visual: point doubling and point addition#

This next animation shows the same curve and the faster route:

• double G to get 2G
• double 2G to get 4G
• add G once more to get 5G

Important: this is still geometric intuition over the same equation. Actual secp256k1 signatures run these operations in a finite field modulo a very large prime.

Why this is one-way#

You can always compute forward:

• start from G
• apply the rules
• get publicKey

But reversing it means solving the elliptic curve discrete logarithm problem, which is computationally infeasible at secp256k1 size.

That is the security wall.

How ECDSA signing works in simple steps#

When you sign a message hash z, your wallet does this (simplified):

Input: private key d, message hash z
1) pick one-time nonce k
2) compute point R = k * G
3) take r = x-coordinate(R) mod n
4) compute s from (z, r, d, k)
Output signature: (r, s) plus recovery id v

You can think of k as an ephemeral secret used once for that one signature.

If k is reused, private key leakage becomes possible. This is a known catastrophic failure mode.

How verification works (without the private key)#

Verifier input:

• message hash z
• signature (r, s)
• signer public key

The verifier checks whether (r, s) is mathematically consistent with that public key and message hash.

No private key is needed for verification.

That is exactly what blockchains rely on.

Why nonce k is so critical#

Many real-world failures came from nonce mistakes, not from the core algorithm itself.

Bad examples:

• reusing the same k for two different signatures
• weak randomness in k
• leaking partial nonce bits repeatedly

Safer practice in modern tooling:

• deterministic nonce generation (RFC 6979 style)
• constant-time crypto libraries
• strict signature validation (including low-s rules where applicable)

What Ethereum keeps and what users see#

In Ethereum UX, users mostly see an address, not a raw public key.

Relationship (simplified):

1. private key -> public key (k × G)
2. hash public key
3. take last 20 bytes -> address

That means the address is derived from the public key, and the public key is derived from the private key.

Common misunderstandings (quick fixes)#

"Public key is just a random number"#

Not random. It is deterministically derived from the private key.

"Elliptic multiplication is regular multiplication"#

No. It is repeated curve point operations.

"Signature proves who I am"#

It proves control over a private key for that specific message. Identity is a separate layer.

"If I share my public key, I am unsafe"#

Public key is meant to be public. Security comes from keeping the private key secret and using safe signing flows.

Practical wallet safety rules#

Even if you never write crypto code, these rules matter:

• never export your private key into random tools
• use a hardware wallet for meaningful funds
• verify what you sign, not just where you click
• avoid blind-signing opaque payloads
• keep wallet software up to date

TL;DR#

ECDSA on secp256k1 is simpler than it looks once you strip the jargon:

• private key = secret number
• public key = secret number applied to generator point with curve operations
• signature = proof you know the secret without revealing it
• verification = public math anyone can run

The most important mental model is this:

the system is secure because forward computation is easy, reverse recovery is infeasible, and nonce handling is strict.

Further reading#

• secp256k1 overview
• RFC 6979 deterministic nonce generation
• How signatures are used in Safe transaction flows
• Ethereum accounts and keys