One of the most repeated messages in support forums always starts the same way: I imported my key into a new wallet and the balance came up zero. Almost nothing is ever lost. What changed was the packaging of the same number, and the wallet looked at the wrong door.
The private key, as you already know, is a 256-bit number. The rawest way to write it is in hexadecimal: sixty-four characters, from 0 to 9 and from a to f, with each pair of characters representing a byte. It's just the number and nothing else — no version, no checksum, no error warning if you swap a character.
That's why the WIF, or Wallet Import Format, exists. It's the same recipe as the address, applied to the private key: a version byte is added at the front, a four-byte checksum is calculated using SHA-256 twice, and everything is converted to base 58. The result is a string that starts with the digit 5 and has fifty-one characters, or starts with K or L and has fifty-two. The difference between these two cases is the subject of the rest of the lesson.
Return to the curve for a moment. The public key is a point, and a point has two coordinates, x and y. Writing both in full gives sixty-five bytes: one marking byte and thirty-two for each coordinate. This is the uncompressed form, the only one that existed when Bitcoin was born.
However, the curve equation allows you to save half of that. Given x, the equation y² = x³ + 7 returns y squared, and knowing the square gives the value except for one detail: there are two roots, one even and one odd. So, you just need to store the entire x and a single bit indicating which one is correct. The compressed public key is thirty-three bytes and starts with 02 or 03 — exactly that bit. The uncompressed one starts with 04.
Here's the entire trap. Both forms describe the same point, but they are different byte sequences — and the address, as Lesson 3 showed, is the hash of the byte sequence. Different hashes, different addresses. The same private key, therefore, controls two addresses that look nothing alike, and the money in one doesn't appear in the other.
The WIF indicates which of the two the wallet should assemble. When the private key is to be used in compressed form, a byte 01 is added at the end before calculating the checksum, and it's this extra byte that pushes the result from fifty-one to fifty-two characters and changes the initial 5 to K or L. The first character of a WIF is not decoration: it's the instruction on how to read the rest.
The switch happened in 2012 when Bitcoin Core began generating compressed keys by default. The savings are real: thirty-two bytes less in each transaction input, repeated over billions of transactions. The keys from before remain valid, and that's why serious wallets, when importing, scan both paths instead of choosing one.
There are still two packages that appear occasionally. The key encrypted by the BIP-38 standard starts with 6P and only becomes a real key after a password — this is what Mike Caldwell's physical coins, the Casascius, printed under a hologram between 2011 and 2013. And the mini format, thirty characters starting with S, fit in the tight space of these same coins.
None of this changes the key. Hexadecimal, WIF, compressed, encrypted: these are ways to write, store, and transport the same number, with more or less protection against typing errors. Confusing the packaging with the content is what makes a balance seem lost — and checking the first character usually resolves the scare in ten seconds.
A real wallet, however, doesn't store a key. It stores a seed, from which thousands of keys are generated in sequence, all recoverable from twelve words. How this trick works, and why it changed the way backups are done, is the subject of the next module.