MASTERING-BITCOIN · Interactive Practice | Unit 4 · Video 6

From '5' to 'K': Bitcoin Key Formats, Vanity Addresses, and Paper Wallets

IKey Formulas & Facts

Concept	Formula / Rule	Description
Vanity search space	$N = 58^{n}$	$n$ = number of required characters from the base58 alphabet
Expected time to find	$t = \dfrac{58^{n}}{r}$	$r$ = generation rate in keys/second
WIF prefix	Starts with `5`	Raw key + version byte `0x80` + checksum → base58check
WIF-compressed prefix	Starts with `K` or `L`	Same as WIF, plus one extra `0x01` flag byte before the checksum

Remember: "Compressed" refers to the public key — the private key in WIF-compressed format is actually one byte longer, not shorter.

IIVisualization 1: The Cost of Vanity

Every extra character you demand in a vanity address multiplies the search space by 58 — the size of the base58 alphabet. Use the sliders to explore how quickly this blows up.

Try this: start with a 2-character prefix (milliseconds), then slide up to 11 characters. Watch the time axis go from seconds to millions of years.

⚙ interactive visualization — coming to this page format soon

Notice: Each time you add one character, the bar grows by a factor of 58. That's why even a billion-keys-per-second GPU farm can't produce an 11-character vanity prefix within a human lifetime. The cryptography isn't stronger — it's just a filter, and the filter gets exponentially pickier.

IIIVisualization 2: The Byte That Flips the Prefix

WIF and WIF-compressed are built from the same 256-bit private key. The only difference is a single extra byte — 0x01 — inserted before the checksum. That one byte changes the leading character from 5 to K or L after base58check encoding.

Use the toggle to add or remove the compression flag and watch the byte-strip (and the prefix) change.

⚙ interactive visualization — coming to this page format soon

Reflect: The compressed version is one byte longer (37 bytes vs 36 before encoding). Yet it's called "compressed" — because the flag tells the importing wallet to derive compressed public keys from this private key. The compression happens on the public-key side, never on the private-key side.

IVQuiz Questions

Question 1

You export a private key from your wallet and notice the string begins with the character 5. What format is this key in?

✅ Correct! A leading 5 is the signature of uncompressed WIF encoding.

❌ Not quite. Raw hex and binary are not base58 strings — they don't have a 'leading character' in the base58 sense. WIF-compressed starts with K or L, not 5.

Show solution

Solution:

A WIF private key is built as:

$\underbrace{\texttt{0x80}}_{\text{version}} \;\|\; \underbrace{\text{256-bit key}}_{\text{32 bytes}} \;\|\; \underbrace{\text{checksum}}_{\text{4 bytes}}$

When the resulting 36-byte payload is base58check-encoded, the leading character is always 5. This marks the key as intended for uncompressed public keys.

If a single 0x01 flag byte were inserted before the checksum, the 37-byte payload would instead encode to a string starting with K or L — that's the WIF-compressed variant.

Question 2

True or False: A WIF-compressed private key is shorter than an uncompressed WIF private key because the "compression" removes redundant bytes from the private key itself.

✅ Correct! The compressed format is actually one byte longer, and the flag affects only how public keys are derived.

❌ Not quite. The name is deceptive — the private key bytes are identical. The compressed WIF is one byte longer due to the 0x01 flag.

Show solution

Solution:

The statement is false on both counts:

A WIF-compressed private key payload is 37 bytes (before base58check encoding), whereas the uncompressed WIF payload is 36 bytes. The compressed version is one byte longer, not shorter.
The extra byte is 0x01, a flag that tells an importing wallet to derive compressed public keys from this private key. The private key itself is unchanged — it's still the same 256-bit number.

The name is misleading: "compression" refers to the public-key output, never the private-key input.

Question 3

Eugenia's computer finds a vanity address with a 4-character prefix in about 1 minute. Approximately how long will it take the same computer to find a vanity address with a 6-character prefix?

✅ Correct! Each extra character multiplies by 58, so two extra characters multiply by 58² = 3,364.

❌ Not quite. The growth is exponential in the base58 alphabet, not additive or linear. Two extra characters → factor of 58² = 3,364.

Show solution

Solution:

Every extra character multiplies the search space by 58 (the base58 alphabet size).

$t_{6} = t_{4} \times 58^{(6-4)} = 1 \text{ min} \times 58^{2} = 1 \text{ min} \times 3{,}364 \approx 3{,}364 \text{ minutes}$

$3{,}364 \text{ minutes} \approx 56 \text{ hours} \approx 2.3 \text{ days}$

The exponential blow-up is the whole reason vanity addresses hit a wall so quickly. At 9 characters you're at ~800 years; at 11 characters, millions of years.

Question 4

Which of the following is the best reason that vanity addresses and paper wallets have fallen out of favor in modern Bitcoin practice?

✅ Correct! The cryptography is fine — what's broken is the workflow: no HD tree, and address reuse links payments on a public ledger.

❌ Not quite. The cryptographic primitives (secp256k1, SHA-256, base58check) are unchanged and still work. The issue is systemic: a one-off key can't live in an HD wallet tree, and reusing a memorable address leaks privacy.

Show solution

Solution:

The cryptography is identical — same elliptic curve, same SHA-256, same base58check. What changed is the surrounding model:

Deterministic (HD) wallets. A single recovery phrase (12–24 words) generates a tree of thousands of addresses. A vanity key or paper-wallet key is a one-off that doesn't fit this tree — it needs its own separate backup, breaking the "one seed to rule them all" model.
Privacy via fresh addresses. Modern wallets issue a new address for every payment. A memorable vanity address (or a paper-wallet address you hand out repeatedly) links all payments together on-chain and exposes your balance to anyone watching.
Paper-wallet specific: online generators have been backdoored for years, and importing the key to spend typically exposes it to malware.

The fix is a recovery phrase plus a hardware signing device — keys stay offline, the HD tree handles many addresses, and privacy is preserved by default.

Solved: 0 / 4