Private key → P2PKH address (compressed)

What this page computes

One 256-bit private key goes in; one classic 1… address comes out. The address is not a second key and not a hash of the private key — it is a Base58Check encoding of a 20-byte commitment to the compressed public key:

Every intermediate value is shown in the result panel, because the point of this page is to make each step visible rather than to hide it behind a black box.

1. What "P2PKH" actually means

A Bitcoin output is not an account with a balance. It is an amount plus a small program called the locking script (scriptPubKey). To spend that output, the next transaction supplies an unlocking script / witness that makes the program finish with a single TRUE on the stack. P2PKH stands for pay to public key hash, and its locking script is:

OP_DUP  OP_HASH160  <20-byte pubkey hash>  OP_EQUALVERIFY  OP_CHECKSIG

The order matters: the script first re-derives the hash of the public key that the spender supplied, compares it to the committed hash, and only then verifies the signature. Hashing first is what lets the address stay short and keeps the public key off the chain until the coins move.

The Unix-style shorthand <pubkeyhash> OP_CHECKSIG describes the older P2PK ("pay to public key") form, whose locking script pushes the whole public key instead of a hash of it. That form is what Satoshi's first transactions used, and its outputs are bigger:

Executing the script, step by step

The spender's unlocking script is <sig> <pubkey>. Here is exactly what the interpreter does, with the demo key's real values:

So the hash is not a convenience: it is the identity check. If the spender hands over a public key that hashes to something else, OP_EQUALVERIFY fails and the spend is rejected before any signature math is done.

2. The construction, byte by byte

Base58Check is fed 25 bytes. Nothing else is in there — no chain code, no key index, no checksum of the private key:

25 bytes is 200 bits. Because Base58 carries log₂(58) ≈ 5.858 bits per character, the encoded string is 33 or 34 characters long (200 / 5.858 ≈ 34.1). The demo address is exactly 34 characters.

Why the address starts with "1"

Base58 is a big-integer base conversion, and a pure conversion would erase leading zero bytes. So the encoding has an extra rule: every leading 0x00 byte in the input becomes a literal 1 character at the front of the output. The version byte of a mainnet P2PKH address is 0x00, so the first character is always 1. Change the version byte and the leading character changes with it — that single byte is the whole reason 1…, 3… and m… look the way they do.

3. Why hash160 = RIPEMD160(SHA256(x))

Two different hash functions are applied in sequence, and the reason is defence in depth. A collision in SHA-256 alone is useless to an attacker, because the 32-byte digest is then fed to a second, structurally different function: to produce two public keys with the same hash160 you need a collision in the composition, which means breaking both designs. Hashing twice also shortens the result to 20 bytes, which makes every address, script and output smaller.

The relevant threat for a specific address is a second preimage, not a free collision: the attacker must find a public key hashing to your 160-bit value, which costs about 2¹⁶⁰ work. An 80-bit collision bound only matters for generating two colliding keys of the attacker's own choosing, so 20 bytes was judged an acceptable trade for smaller scripts — and it is still unbroken today.

4. What the 4-byte checksum protects against

The checksum is SHA256(SHA256(payload))[0..3] — 32 bits appended to the payload before Base58 encoding. Its whole job is to catch accidental transcription errors: a mistyped character changes the decoded integer, and the probability that a random corruption still matches those 32 bits is 1 in 2³² ≈ 1 in 4.29 billion. That is why stealing a single character from an address makes almost every wallet reject it loudly.

5. Mainnet vs testnet: one byte changes everything

The version byte is the only difference between a mainnet and a testnet P2PKH address for the same hash160. Same 20 bytes, different first byte, completely different strings:

* The test networks share the Base58 version bytes shown here; only the bech32 human-readable part differs (bcrt1 on regtest). For the demo key's hash160 the mainnet address is 146ZNjH7XTXnMd1ofe3z7CL2i8WM7N2UqT and the testnet one is micWfnN6LUy38jVRPD2Mw7YMa873zjixGw — the same 20-byte commitment, pointing at different chains.

6. Worked example with the demo key

These are the exact values this page computes for 0824c314…171ca, and the result panel recomputes them live:

Reading the scriptPubKey: 76 = OP_DUP, a9 = OP_HASH160, 14 = "push the next 20 bytes", then the hash, 88 = OP_EQUALVERIFY, ac = OP_CHECKSIG. Five opcodes and one constant — 25 bytes that define who may spend.

7. Why an address is not a public key

• It is a one-way commitment. The public key is not stored in the address; only its 160-bit hash is. Recovering the key from the address means inverting SHA-256 and RIPEMD-160, for which no method better than brute force is known.
• You cannot verify a signature from an address alone. ECDSA verification needs the public key, which is why the spender must reveal it inside the unlocking script.
• The address does not say how the key was serialized. Compressed and uncompressed keys both produce a perfectly ordinary-looking 1… address; the version byte and length are identical. You cannot tell from an address whether the coins are at the compressed or the uncompressed variant of that key.
• It is not a private key either. Publishing an address reveals nothing that allows spending, which is exactly why it is safe to hand out.

8. Address reuse is a privacy bug, not a consensus bug

The blockchain is a public, permanent ledger, so an address is not an account you can hide behind — it is a permanent label. Every payment to the same address is linked together for anyone to see, together with the amounts and the timing. Two consequences deserve emphasis:

• Clustering. Reusing one address for salary, exchange withdrawals and donations lets an observer build a map of your income, your counterparties and your spending without ever breaking any cryptography.
• Key exposure. The first time an address spends, its public key becomes public for that output, permanently. Fresh addresses keep the preimage layer intact for all funds that have not moved.

The standard remedy is a hierarchical deterministic wallet (BIP32/BIP44): it derives a fresh address for every payment from the same seed, and sends change to a new address too. Reusing an address costs nothing in fees and is still perfectly valid on-chain — which is precisely why so much software does it anyway.

9. Where this fits in the derivation chain

• Before this page: private key → compressed public key produces the 33 bytes that get hashed here.
• Sibling: the same address built from the uncompressed 65-byte key — a different address for the same secret.
• Sibling: the nested SegWit 3… address and the native SegWit bc1q… address, which reuse the identical hash160.
• Reverse direction: a public key → hash160 → addresses needs no private key at all.

10. Security notes

• An address reveals nothing about the key, so it is safe to share; the key and the WIF are not.
• Verify addresses character by character on the signing device. The 4-byte checksum catches typos, not deliberate substitution.
• Send a small test amount first when a new address is involved, and wait for confirmations before the rest.

11. Common mistakes

• Hashing the uncompressed key by accident. Importing a K…/L… WIF into a wallet that hashes the 65-byte form (or the reverse) shows a zero balance for coins that are perfectly safe at the other address.
• Believing the address can be reversed. No amount of computing power turns 146ZNjH7… back into a public key or a private key; only a full search of the hash's preimage would, and that is infeasible.
• Treating a prefix as validation. 1 at the start does not prove the address is correct, on the right network, or even P2PKH — decode it.
• Hand-editing a rejected address. If a wallet says "invalid checksum", the address is wrong; guessing the correction is how coins are destroyed.
• Confusing mainnet with testnet. Both look plausible; the version byte decides which chain the coins land on.

12. Quick reference