Private key → compressed public key

What this page computes

You give it one 256-bit number — the private key k — and it computes the compressed public key. Inside the server this is one operation:

1. What a private key really is

A Bitcoin private key is not a file, a password or a random blob of bytes. It is a single integer — a scalar in the language of elliptic-curve cryptography — that satisfies:

Two boundary values are excluded, and this matters in practice:

• k = 0 would give 0 · G, the so-called point at infinity, which has no coordinates and cannot be serialized into a public key.
• k ≥ n wraps around, because the curve's point group is cyclic of order n: n · G = ∞, so (n+1) · G = G. A key of n+1 would be a legal-looking 32-byte number that silently behaves like 1.

The practical upper bound is therefore about 2²⁵⁶, but not exactly: the search space holds n − 1 ≈ 1.158 × 1077 usable keys, which is roughly the number of atoms in the observable universe divided by a billion. Guessing one by brute force at a trillion keys per second would still take around 10⁵⁸ years.

2. The curve: why a public key is a point

Bitcoin uses the curve secp256k1, defined over the prime field of integers modulo p:

Any pair (x, y) satisfying that equation is a point on the curve. Because the equation is taken modulo p, the "curve" is not a smooth arc but a scattered set of points in a 256-bit wide finite grid — yet it still forms a mathematical group, which is what makes cryptography possible on it.

Points can be added (geometrically: draw a line through two points, find the third intersection, reflect it across the x-axis) and therefore also multiplied by an integer by repeated addition. That group law is the entire engine of Bitcoin key derivation.

Note that p and n are different numbers and it is a common beginner bug to confuse them. p bounds the coordinates; n bounds the private key.

3. How P = k·G is actually computed

There is no closed-form shortcut. The standard method is double-and-add, which walks the 256 bits of k from most significant to least:

R = point at infinity
for bit in bits_of(k):        # 256 iterations
    R = double(R)             # R = R + R
    if bit == 1:
        R = add(R, G)         # R = R + G
return R

That is about 256 doublings and ~128 additions — a few hundred field operations, which is why a modern laptop can do tens of thousands of these per second and this PHP implementation with GMP does roughly 80 per second.

4. Serializing a point: 33 bytes or 65 bytes

A point is two 256-bit coordinates, so the obvious encoding is 64 bytes plus a tag. SEC1 defines two standard ways:

5. The parity trick: why 32 bytes are enough

Compression is not a lossy hack — it is exact, because Y is fully recoverable from X. For a given X, the curve equation gives

which has exactly two solutions, Y and p − Y. Those two roots always have opposite parity: one is even, the other is odd (this holds because p is odd, so p − Y ≡ −Y flips the lowest bit). So a single bit — "is Y even or odd?" — is enough to pick between them. That bit is exactly what the 02/03 prefix stores.

Decompression is therefore a real computation: add the constant 7 to the cube of X, take the modular square root (feasible in closed form because p ≡ 3 (mod 4), giving Y = (X³+7)(p+1)/4 mod p), then negate if the requested parity does not match.

6. Worked example

These are the real values this page produces for the sample key 0824c314…171ca:

Notice the last two rows: one private key, two completely different addresses. The page's own result panel recomputes all of these live, so you can verify the claim yourself.

7. Compressed vs uncompressed — why anyone cares

Both encodings describe the same point and both are valid signatures-wise, but they lead to different addresses, and that has real consequences.

8. Where the compressed public key goes next

• P2PKH (1…): Base58Check(0x00 ‖ hash160) — see private key → P2PKH address.
• P2WPKH (bc1q…): bech32("bc", 0, hash160) — the compressed key is mandatory here; witness programs are always 20 bytes.
• P2SH-P2WPKH (3…): Base58Check(0x05 ‖ hash160(0x0014 ‖ hash160)).
• P2TR (bc1p…): a different path entirely — the internal key is tweaked with TapTweak and only the x coordinate of the output key is used.

9. Security notes

• A public key is safe to publish. It reveals nothing usable about k, assuming the discrete log problem stays hard.
• A public key does leak some information: once a key has signed a transaction, the address is publicly tied to that public key, which slightly reduces the attacker's search space if ECDSA nonce reuse ever occurs. Taproot was partly motivated by hiding keys behind a single point.
• Always validate a received public key with the on-curve check (Y² ≡ X³ + 7). Accepting an off-curve point enables invalid curve attacks that can recover the private key. This page performs that check and refuses off-curve input.
• Quantum computers running Shor's algorithm could solve the discrete log directly. That affects public keys that are already exposed on-chain, not the hash-based addresses that have never spent.

10. Common mistakes

• Confusing the private key with the WIF. The WIF is a Base58Check encoding of the key plus a network byte and a compression flag. They are different strings for the same secret.
• Assuming one private key = one address. One key yields at least five distinct address types, plus testnet variants.
• Treating the public key as the address. The public key is not hashed into a Base58 form by itself; the address is the 20-byte hash of the (encoded) public key.
• Padding errors. A private key of 0x1f is 31 bytes of leading zeros followed by 1f — losing those zeros produces a completely different key.
• Mixing up p and n. X and Y are reduced modulo p; k is reduced modulo n.

11. Quick reference