MASTERING-BITCOIN · Unit 4 · Video 3

Why Bitcoin Addresses Start With 1 — Interactive Practice

IKey Reference

Concept Value / Formula Notes
Base58 alphabet size 58=64−658 = 64 - 6 Excludes 0, O, l, I, +, /
Base58Check structure [version (1B)] [payload (20B)] [checksum (4B)] 25 bytes before encoding
Checksum first 4 bytes of SHA256(SHA256(version∥payload))\text{first 4 bytes of } \text{SHA256}(\text{SHA256}(\text{version} \| \text{payload})) Typo detection
Elliptic curve (secp256k1) y2=x3+7y^2 = x^3 + 7 Symmetric about x-axis
Uncompressed pubkey 04 ‖ x (32B) ‖ y (32B) = 65 bytes Full point
Compressed pubkey 02 or 03 ‖ x (32B) = 33 bytes 02 if y even, 03 if y odd

Version byte → leading character:

Version Purpose Leading character
0x00 P2PKH mainnet 1
0x05 P2SH mainnet 3
0x80 WIF private key 5, K, or L
0x6F P2PKH testnet m or n
0xC4 P2SH testnet 2

IIVisualization 1: The Base Encoding Ladder

Any integer can be written in different number bases. Higher bases pack the same value into fewer characters. Slide the value below and watch how the string length shrinks as the base grows. This is why Bitcoin uses base58 — it is compact and readable.

⚙ interactive visualization — coming to this page format soon

IIIVisualization 2: Version Byte → Leading Character

The first byte before base58 encoding is called the version byte. Because base58 encoding preserves the leading bits of the payload, the value of the version byte deterministically controls the leading character of the final address. Pick a version byte and see what prefix it produces.

⚙ interactive visualization — coming to this page format soon

IVVisualization 3: Compressed Public Keys and Curve Symmetry

Bitcoin's public keys live on the elliptic curve y2=x3+7y^2 = x^3 + 7. For any valid xx, there are exactly two values of yy — one "even" (upper), one "odd" (lower). Since knowing xx plus one bit of parity uniquely determines the point, we can shrink a 65-byte public key down to 33 bytes. Slide xx below and see the two candidate yy values.

⚙ interactive visualization — coming to this page format soon

Notice: The curve is perfectly symmetric across the x-axis. A compressed public key stores only xx plus a single parity bit (expressed as a 0x02 or 0x03 prefix byte). The underlying point on the curve is identical to the uncompressed form — just half the storage.

Caveat: Compressed and uncompressed encodings are different byte strings, so hashing them produces different addresses. One private key, two valid addresses. This is why WIF private keys carry a compression flag.

VQuiz Questions

Test your understanding with the questions below.

Question 1

A Bitcoin address is encoded with version byte 0x00. What character does the address begin with?

✅ Correct! Version byte 0x00 always produces a leading 1.

❌ Not quite. 0x00 is a leading zero byte, and base58 maps leading zero bytes to leading '1' characters.

Show solution

Solution:

Base58 encoding preserves leading zero bytes as leading '1' characters in the output. Since version byte 0x00 is a leading zero byte, every P2PKH mainnet address begins with 1.

Version Leading character
0x00 1 (P2PKH mainnet)
0x05 3 (P2SH)
0x80 5, K, or L (WIF)
0x6F m or n (testnet)

The answer is 1.

Question 2

True or False: The same private key will always generate the same Bitcoin address, regardless of whether the public key is encoded in compressed or uncompressed form.

✅ Correct! Hashing the bytes of the public key — not the abstract point — means different encodings give different addresses.

❌ Not quite. Think about what the address hash is computed from — it's the byte string of the public key, not the mathematical point itself.

Show solution

Solution:

The Bitcoin address is the HASH160 of the public key bytes, not the abstract curve point. Compressed and uncompressed encodings are different byte strings:

  • Uncompressed: 04 ‖ x (32B) ‖ y (32B) → 65 bytes
  • Compressed: 02 or 03 ‖ x (32B) → 33 bytes

Different input bytes give different hashes, hence different addresses. One private key therefore has two valid addresses, and funds sent to one cannot be spent from the other without knowing the correct encoding.

The answer is False.

Question 3

In Base58Check encoding for a P2PKH Bitcoin address, how many raw bytes are assembled before the final base58 conversion (version + payload + checksum)?

✅ Correct! 1 (version) + 20 (HASH160 payload) + 4 (checksum) = 25 bytes.

❌ Not quite. Add up all three pieces: the version byte, the 20-byte HASH160 payload, and the 4-byte checksum.

Show solution

Solution:

The Base58Check structure for a P2PKH address has three pieces:

Piece Size
Version byte 1 byte
Payload (HASH160 of pubkey) 20 bytes
Checksum (first 4 bytes of double-SHA256) 4 bytes
Total 25 bytes

1+20+4=25 bytes1 + 20 + 4 = 25 \text{ bytes}

Those 25 bytes are then base58-encoded into the ~34-character human-readable address you see.

The answer is 25 bytes.

Question 4

A compressed public key you received begins with the prefix byte 0x03. What does this tell you about the point on the elliptic curve?

✅ Correct! Prefix 0x03 signals odd y; 0x02 signals even y.

❌ Not quite. The prefix byte encodes the parity of y, since the curve's symmetry means x alone is ambiguous between two candidates.

Show solution

Solution:

Because the curve y2=x3+7y^2 = x^3 + 7 is symmetric about the x-axis, each valid xx has two possible yy-values. In secp256k1's finite field, one is even and the other is odd. A single parity bit suffices to distinguish them, and it is encoded in the prefix byte:

  • 0x02 → yy is even
  • 0x03 → yy is odd

Both store only the 32-byte x-coordinate afterward, totaling 33 bytes instead of 65. A receiver recomputes yy by solving the curve equation and picks the root matching the parity flag.

The answer is the y-coordinate is odd.

Solved: 0 / 4