Private key → uncompressed public key

What this page computes

You give it a 256-bit private key k and it produces the uncompressed public key: the elliptic-curve point P = k·G written out in full, both coordinates, tagged with a single 04 byte. That is 65 bytes — the format Satoshi's original client used for every key it ever made.

Nothing here is a new kind of cryptography. The curve arithmetic is identical to the compressed-key page; only the serialization of the resulting point differs — and that difference is what gives one private key two unrelated addresses.

1. Why the uncompressed form is exactly 65 bytes

A public key is a point on secp256k1: two numbers X and Y in the range [0, p−1] satisfying Y² ≡ X³ + 7 (mod p), with p = 0xFFFFFFFF…FFFFFC2F (256 bits). Since each coordinate is smaller than p, each one fits into 32 bytes. The encoding is the obvious one — a one-byte tag saying "here comes a point in uncompressed form", then the two coordinates:

Three details are easy to get wrong:

• The coordinates are fixed-width. Unlike DER-encoded integers (which drop leading zero bytes), a SEC1 coordinate is always 32 bytes. If X happened to be 0x00a1…, that leading 00 byte stays. Removing it would shift every following byte and produce a key of a different length — which is exactly what some broken parsers used to do.
• Big-endian. The first byte after the tag is the most significant byte of X. Key serialization is never little-endian, unlike some other Bitcoin structures.
• The 04 byte is not part of the number. It is a tag, exactly like the 02/03 tag of the compressed form. Hash the 65 bytes as a unit; the tag participates in the hash.

2. The prefix byte: 04, and the abandoned 06/07

The first byte comes from SEC1, the standard that defines how elliptic-curve points are written as octet strings. SEC1 gives each point encoding a one-byte identifier, and Bitcoin inherited all of them:

The hybrid forms 06 and 07 carried the parity of Y in the low bit of the tag (06 = even, 07 = odd) and also wrote out Y in full. The parity bit therefore said nothing the Y bytes did not already say, while handing an attacker a second, redundant field to tamper with: flip the tag and the key becomes internally inconsistent. Later revisions of SEC1 dropped the hybrid encodings for exactly that reason, no wallet ever emitted them, and they carry no meaningful transaction volume. This page's shared parser still accepts a 06/07 key so you can inspect one — never generate or store one.

3. Where this format came from — and why it changed in 2012

The original Bitcoin client (2009) generated keys through OpenSSL. OpenSSL's default octet-string encoding for an EC point is the uncompressed one, so every key created by the first three years of Bitcoin software was a 65-byte 04‖X‖Y key, and every address in the early blockchain was hash160 of that 65-byte string. That is the historical default, not a special "legacy mode" someone switched on.

Compression was proposed later as a space optimization. A point's Y coordinate is fully determined by X plus one bit (its parity), so 32 of the 65 bytes are redundant. A BIP-style proposal worked through the change, and Bitcoin 0.6.0, released in March 2012, shipped support for compressed public keys and made them the default for newly generated keys. The motivations were purely economic and practical:

• Every spend from a P2PKH output embeds the public key in the scriptSig. A 33-byte key instead of 65 saves 32 bytes per input — a ~23 % smaller scriptSig, and real money at scale.
• Smaller inputs mean a smaller UTXO set and a smaller blockchain — a live concern even in 2012.
• Security is identical: both encodings describe the same point, and ECDSA does not care how the point was written down.

Because the change altered the bytes that get hashed, wallets had to tell their users which form a key was in — a raw private key carries no such information. That is the entire reason the WIF format grew a 0x01 compression flag in the same release (see private key → compressed WIF). Crucially, the change added a format; it did not invalidate the old one. Coins sitting at uncompressed addresses in 2012 are still spendable today, by the same consensus rules.

4. Why the uncompressed form still matters

• Old funds. Any key or address generated before mid-2012, and any created afterwards by software that never adopted compression, holds its coins at hash160(04‖X‖Y). Recovering such coins requires reproducing exactly that 65-byte string.
• Paper wallets. Printed wallets from the 2011–2013 era, and many physical-bitcoin collectibles of the same period, were built with uncompressed keys. Their private key is printed as a 5… WIF precisely because the pairing is uncompressed key + uncompressed address.
• Sweeping. To spend from such an address, the scriptSig must push the public key whose hash160 matches the one committed in the address. Push the compressed key instead and the P2PKH check fails — the transaction is rejected, not silently redirected.
• Forensics and recovery. Given an address and a candidate key, you need both serializations to decide which one the address belongs to — literally what this page computes.

5. Worked example with the real demo values

Everything in this table is what this page computes for the sample key shown in the input box. You can reproduce it by pressing "Use example":

The last three rows are the whole point of this page. The same 256-bit number k is responsible for both 16kR3eis…GWG2G and 146ZNjH7…2UqT. They are not aliases: they are two distinct 20-byte commitments, two distinct addresses, and a wallet normally watches only one of them.

The address itself is a Base58Check structure built from the hash160 above:

6. Compressed vs uncompressed, side by side

The scriptSig arithmetic is worth spelling out: a P2PKH spend pushes one DER signature plus its 1-byte sighash type (about 72 bytes) and one public key, each preceded by a length byte. At a fee rate expressed in satoshis per virtual byte, that 32-byte difference is paid on every input, forever.

7. One key, two addresses — the most common "I lost my coins" story

Three consequences worth remembering:

1. Both addresses are spendable by you. The same private key controls the compressed and the uncompressed address. If someone ever paid you at an old address, you can still move those coins.
2. They cannot be merged. You cannot "convert" an uncompressed address into a compressed one; you can only send the coins from the former to the latter in an ordinary transaction, paying a fee.
3. Check both before concluding anything. When a restored wallet shows zero, compute both forms (this page and its compressed twin do exactly that) and search the blockchain for both addresses.

8. What happens after this step

• Private key → P2PKH uncompressed address — the full address construction, version byte and checksum included.
• Private key → uncompressed WIF — the matching 5… backup string, which is what you would actually import into a wallet.
• Private key → compressed public key — the 33-byte sibling and its own addresses.
• Uncompressed public key → hash160 → addresses — the same computation starting from a key you already have, with an on-curve check.

9. Security notes

• Security is not reduced by using 65 bytes. Compressed and uncompressed keys are the same curve point; the discrete-log problem, the signature scheme and the effective key strength are identical. "Uncompressed" means "longer", not "weaker".
• It costs more to spend. A larger scriptSig means a larger transaction and a higher fee for the same economic value transferred. That is the only practical penalty, and it is why no modern wallet hands out uncompressed addresses.
• Validate points you receive. An off-curve (X, Y) pair can be used for invalid-curve attacks against careless implementations. This site verifies Y² ≡ X³ + 7 before using a point.
• A private key in a web form is a private key on the wire. This page submits over the request line, and anything that reaches a server may be captured in a log or proxy. Treat this tool as a teaching aid: experiment with throwaway keys, and move real funds only inside software you control.
• Quantum exposure is unchanged. A published public key — compressed or not — is what Shor's algorithm attacks; 32 extra bytes buy no quantum resistance.

10. Common mistakes

• Dropping the 04. The tag is part of the hash160 input. A 64-byte "X‖Y" string hashes to something completely different and is not a valid public key.
• Trimming leading zero bytes from a coordinate. Fixed width is mandatory: 32 bytes for each coordinate, always.
• Believing compressed and uncompressed are two different keys. They are two serializations of one point, controlled by one private key.
• Expecting an uncompressed key to work in SegWit. Witness v0 requires compression; an uncompressed key simply cannot be used there.
• Assuming the 04 tag encodes parity. It does not. Only the hybrid 06/07 tags and the compressed 02/03 tags carry parity.
• Spending an uncompressed-address UTXO with a compressed key. The script fails; the wallet must present the exact public key that hashes to the address.

11. Quick reference