Private key → P2PKH address (uncompressed)
The other 1… address for the same private key: this one hashes the full 65-byte public key 04‖X‖Y. It is the format every wallet used before 2012, it is still valid and spendable today, and it is the address where a lot of old coins actually sit.
Enter a value above and press Convert. Not sure what to type? Press “Use example” to load the sample from the placeholder.
What this page computes
The same private key as the compressed page, but hashed through the
65-byte uncompressed public key 04 ‖ X ‖ Y. The address formula is identical —
only the bytes that go into the hash change:
The two addresses have the same shape, the same length and the same version byte, and they are not interchangeable. Coins live at one specific address, and only the hash of the exact byte string that was used at receive time will recognise them.
1. The uncompressed public key: 04 ‖ X ‖ Y
SEC1 defines several serializations of an elliptic-curve point. The original one spells everything out: a
04 tag, then the 32-byte X coordinate, then the 32-byte Y coordinate. Nothing is compressed, nothing
has to be recomputed — the verifier reads both coordinates straight off the wire.
| Form | Tag | Content | Length | Used by |
|---|---|---|---|---|
| Uncompressed | 04 | X (32 B) ‖ Y (32 B) | 65 bytes / 130 hex | Satoshi-era clients, this page |
| Compressed, even Y | 02 | X (32 B) | 33 bytes / 66 hex | everything since 2012 |
| Compressed, odd Y | 03 | X (32 B) | 33 bytes / 66 hex | everything since 2012 |
| x-only (BIP340) | — | X (32 B) | 32 bytes / 64 hex | Taproot output keys |
Both forms describe the same point on the same curve. Compression is not a different key, not a different derivation path, and not a "legacy mode" of the maths — it is only a shorter spelling, made possible by the fact that Y is fully recoverable from X and one parity bit (see the compressed page for that trick).
The 32-byte scalar is just a number. "Compressed" is a property of how a wallet serializes the public
key, and it is recorded nowhere except in the WIF string (5… = uncompressed,
K…/L… = compressed) and in the wallet's own metadata. This single fact is the root
cause of every "my coins disappeared" story described below.
2. Why the hash — and therefore the address — differs
hash160 is a function of the exact byte string you feed it, not of the point it represents. A 65-byte input and a 33-byte input have different lengths, different first bytes, and a completely different digest. There is no relationship between the two results: they are two independent 160-bit values.
| Step | Compressed (C) | Uncompressed (U) |
|---|---|---|
| Public key | 02ff812e…8c67ee80 (33 B) | 04ff812e…32b424ae (65 B) |
| SHA-256 of it | 067eb00a0b9864633b020eef374476142daba913c5481ad6a4741cc8ab702617 | 30c812bb6ef97f95538e2423f944d056d0cefc28021113de143e56d2c9d11900 |
| hash160 (20 B) | 21f57b6debcfc5b67182dfb4af1641f0a8189012 | 3f0e966dc089c611a9c1d03bd4f69ea53b0223f9 |
| Payload with version byte | 0021f57b…12 | 003f0e96…f9 |
| Checksum (4 B) | cbd7667e | 3b0b7cbd |
| P2PKH address | 146ZNjH7XTXnMd1ofe3z7CL2i8WM7N2UqT | 16kR3eiswUY6tmGnxZhwQmW6LAvTLGWG2G |
| WIF that implies it | KwVYL77Lcs1ckM39NvGjrtfKhU4KKdR2iB9Wq2FSMN6rbGK5tVqG (K…) | 5HssbguBnjbaUVZCsH9YuzUG7T4vYQf51iiodi4izdVy6aVNekU (5…) |
Both rows are correct, both are spendable, and both belong to the same 256-bit secret. Nothing on-chain indicates that they are related — that is exactly what makes this an interoperability trap rather than a curiosity.
3. The historical timeline
Uncompressed is not a broken legacy format; it is the original one.
| Period | What happened |
|---|---|
| January 2009 | Bitcoin v0.1 ships. Keys are serialized uncompressed; the earliest coins are mostly P2PK outputs that contain the full 65-byte key. |
| 2009 – 2011 | Every wallet — including the reference client — hashes the 65-byte form. Essentially every address from this era is an uncompressed P2PKH address. |
| March 2012 | The reference client's 0.6 series adds compressed public keys; newly generated keys use 02/03 and WIFs gain the K…/L… prefix. BIP16 (P2SH) activates on 1 April 2012 in the same era. |
| 2013 – 2014 | HD wallets (BIP32 / BIP44) become standard and assume compressed keys for every derived address. Uncompressed becomes an export-only format. |
| 24 August 2017 | SegWit activates. Compressed keys become mandatory for witness address types, making the split permanent. |
| Today | Uncompressed P2PKH is still valid, still relayed, and still holds real coins — mostly untouched since 2009–2011. |
4. Wallet recovery: why an old address shows coins the new wallet cannot see
This is the situation the page exists for. You restore a seed, or import a key, and the wallet shows a zero
balance — while a block explorer shows coins sitting quietly at a 1… address that you are sure
belongs to you. Three things have gone wrong at once:
- The wallet only computes one serialization. A modern wallet following BIP44 / BIP49 /
BIP84 / BIP86 derives compressed public keys by convention. It hashes the 33-byte form, gets the
compressed
hash160, and looks up146ZNjH7…. The coins are at16kR3eis…— a value the wallet never computes, so it never asks the network about it. - A restored seed is not a restored wallet. The seed deterministically produces the private key, but the address convention is client software, not mathematics. The same seed with a 2009 client and with a 2024 client yields two disjoint sets of addresses.
- The WIF flag, not the key, decides. When the key was exported as
5HssbguBnjbaUVZCsH9YuzUG7T4vYQf51iiodi4izdVy6aVNekU(prefix5), the wallet should treat it as uncompressed. Import it asK…/L…, or paste the raw hex into a wallet that assumes compressed, and the coins vanish from view without moving an inch.
Derive both addresses for every key you own and look up the uncompressed one specifically. Tools
that do this: an offline wallet with an "uncompressed / legacy" import option, a key-sweeping utility that
scans both hash160 forms, or a page like this one paired with an offline explorer. Do not "fix" it
by sending coins from the old address to the new one until you can sign with the old key — you still need the
key that controls the source address, and it is the same key, so signing is fine; the danger is
concluding the money is gone and doing something drastic.
5. Is the uncompressed form still valid on-chain?
Yes. Nothing in the consensus rules forbids it, and a P2PKH output created from an uncompressed key remains spendable today:
- The locking script only commits to a 20-byte hash. The interpreter does not care whether the public key
revealed in the unlocking script was 33 or 65 bytes —
OP_HASH160simply hashes whatever bytes it is given andOP_EQUALVERIFYcompares the result. - Uncompressed P2PKH spends are still standard by relay policy, so they propagate and get mined like any other transaction.
- The only structural limit is inside witness programs: a v0 witness spend that presents an
uncompressed key violates the standardness flag
SCRIPT_VERIFY_WITNESS_PUBKEYTYPE. Such an output can still be built (the encoder will happily give you abc1q…or3…string), but the spend cannot propagate through normal relay — witness address types are compressed-only by policy.
An uncompressed P2PKH address is not deprecated and not broken: it is an ordinary, fully spendable output. Making such outputs unspendable would require a soft fork that no one has proposed, so the coins will still be there whenever you get around to them. The only real deadline is the practical one — the longer a key sits exposed to weak-randomness and phishing risk, the more chances an attacker gets.
Feeding hash160(uncompressed pubkey) into a P2WPKH or P2SH-P2WPKH encoder produces a
syntactically perfect address that you may be unable to spend through normal relay, because the witness would
have to carry the 65-byte key. If a tool offers to "upgrade" an old key to SegWit, it must start from the
compressed public key derived from the same scalar — the uncompressed hash is simply the wrong 20
bytes for every witness address type.
6. The economics: bigger script, higher fees
Spending an uncompressed P2PKH output costs more because the unlocking script must carry 32 extra bytes: the full Y coordinate. Both addresses look identical on the receiving side; the difference shows up only when the coins move.
| Item | Compressed | Uncompressed |
|---|---|---|
| Public key in the scriptSig | 33 B + 1 push byte = 34 B | 65 B + 1 push byte = 66 B |
| Signature push (typical) | 1 + 70…72 B + 1 sighash byte ≈ 73 B | same ≈ 73 B |
| scriptSig total | ≈ 107 bytes | ≈ 139 bytes |
| Whole input (txid + vout + script + sequence) | 32 + 4 + 1 + 107 + 4 = 148 bytes | 32 + 4 + 1 + 139 + 4 = 180 bytes |
| Extra weight per input | — | +32 bytes = +32 vB |
| Extra fee at 10 sat/vB | — | +320 sat per input |
At 10 sat/vB the surcharge is about 320 satoshis per input; on a sweep of 50 old inputs that is roughly 16 000 satoshis of pure overhead, and the gap widens whenever fees spike. It is a real cost, but it is also the only way to move those coins: the fee is not optional and not avoidable, because the extra bytes are what make the hash match.
7. Mainnet vs testnet version bytes
| Network | P2PKH version | P2PKH prefix | P2SH version | WIF version | Bech32 hrp |
|---|---|---|---|---|---|
| Mainnet | 0x00 | 1… | 0x05 | 0x80 | bc |
| Testnet | 0x6F | m… / n… | 0xC4 | 0xEF | tb |
The version byte is the only thing that differs between the two chains for a given hash160: the uncompressed
hash160 above yields 16kR3eiswUY6tmGnxZhwQmW6LAvTLGWG2G on mainnet and
mmGNLhorkVyMfskQg8gKEgiRCAXAGnxeBv on testnet. The version byte is also the only reason the
mainnet address starts with 1 — Base58 writes each leading 0x00 as a literal
1.
8. Worked example with the demo key
| Step | Value |
|---|---|
| Private key k | 0824c314772b2c2859c889471390a36bf66e53a1ca1642f96f0f2c9307a171ca |
| Uncompressed public key (65 B) | 04ff812e26116a9aa140abe629e7f8a38401653caf925119def59ed3758c67ee808f49cde13c7ffd64f1d730bf87a743a578eda4971ddac4a08118160732b424ae |
| SHA-256 of that (32 B) | 30c812bb6ef97f95538e2423f944d056d0cefc28021113de143e56d2c9d11900 |
| hash160 (20 B) | 3f0e966dc089c611a9c1d03bd4f69ea53b0223f9 |
Payload = 00 ‖ hash160 (21 B) | 003f0e966dc089c611a9c1d03bd4f69ea53b0223f9 |
| Checksum (4 B) | 3b0b7cbd |
| P2PKH address (uncompressed) | 16kR3eiswUY6tmGnxZhwQmW6LAvTLGWG2G |
| Same key, compressed address | 146ZNjH7XTXnMd1ofe3z7CL2i8WM7N2UqT |
| Matching scriptPubKey (25 B) | 76a9143f0e966dc089c611a9c1d03bd4f69ea53b0223f988ac |
Everything in that table is recomputed live by the result panel, so you can confirm that the two
hash160 values, and therefore the two addresses, have nothing in common.
9. Where this fits in the chain
- Companion page: the compressed P2PKH address — the same pipeline with 33 bytes instead of 65, and the address modern wallets show.
- Upstream: private key → uncompressed public key shows how the 65 bytes are built from the point.
- Export format: the uncompressed WIF (
5…) is what a wallet needs in order to look at this address rather than the compressed one. - Only this page's address is relevant to old funds: nested SegWit and native SegWit are compressed-only and will never match an old key's uncompressed hash.
10. Security notes
Uncompressed addresses are heavily associated with early, high-value coins, and some early keys were
generated with weak randomness (a predictable RNG seeded from the clock, or invented by hand). An uncompressed
address sitting at the top of a "rich list" attracts brute-force attention. If you control such coins, move them
— but move them correctly: first sweep the uncompressed address with the 5… WIF, then
consolidate to a fresh, modern address derived from a properly random seed.
- Both addresses are public information; only the private key and the WIFs are secret.
- Verify which address actually holds the coins before signing anything. Send a small test output first if you are unsure.
- Never paste an old private key into a website that also offers to "check your balance" — that is the classic phishing pattern, and an old key is a tempting prize.
11. Common mistakes
- Assuming one key means one address. One scalar gives at least five useful addresses
(
1…compressed,1…uncompressed,3…,bc1q…,bc1p…) plus their testnet variants. - Importing the wrong WIF form.
5…andK…/L…are the same secret pointing at different addresses; mixing them up produces an empty wallet view. - Trusting a wallet's "auto-detect". Some clients scan both forms, some scan only one, and some silently show zero. Verify against a block explorer with the derived address, not the balance.
- Thinking compressed is "newer maths". It is the same curve and the same point; only the serialization changed.
- Sweeping to a SegWit address from an uncompressed key's hash. Build the destination from a fresh compressed key instead; see the danger note above.
12. Quick reference
| Item | Value |
|---|---|
| Formula | Base58Check(0x00 ‖ hash160(uncompressed pubkey)) |
| Hash input | 65-byte key 04 ‖ X ‖ Y (130 hex digits) |
| Hash function | hash160 = RIPEMD160(SHA256(x)), 20 bytes |
| Version byte | 0x00 mainnet, 0x6F testnet |
| Encoded payload | 25 bytes = 1 + 20 + 4 |
| scriptSig when spending | ≈ 139 bytes (vs ≈ 107 compressed) |
| WIF that implies it | 5… (uncompressed) |
| SegWit compatible? | No — witness programs are compressed-only by policy |
| Demo address | 16kR3eiswUY6tmGnxZhwQmW6LAvTLGWG2G |
| Still spendable? | Yes — consensus and relay policy both accept it |