Study Notes: Chapter 3 – Addresses

1. Why Replace Names With Addresses?

Q1: Why can using names in our ledger (or spreadsheet) be a privacy problem?

Because outsiders (like an insurance company) could identify who is sending and receiving. They could see how many cookies (or how many bitcoins) someone is spending. It compromises personal and financial privacy.

Figure 2. Acme Insurances looks at cookie-eating habits to adjust premiums.

Q2: How does replacing names help?

Instead of names, the spreadsheet will list only public key information. That way, transactions appear like “PublicKey_A to PublicKey_B,” making it harder to see who is who.

2. Public Keys, Public Key Hashes, and Addresses

Q3: After dropping personal names, what do we store in the spreadsheet instead?

We store public key hashes (PKHs). Each public key is first hashed with SHA256, then hashed again with RIPEMD160, resulting in a 20-byte PKH.

Figure 6. The public key is hashed first with SHA256, then RIPEMD160, to produce a PKH.

Q4: Why shorten public keys to 20-byte PKHs?

• Smaller size: A 160-bit PKH is smaller than a 33-byte public key, saving storage space in the ledger.
• Extra security: If there’s ever a vulnerability in the public key derivation, hashing adds another protective layer.

Q5: Does replacing names with PKHs solve all privacy concerns?

Not entirely. PKHs are pseudonyms, but any link between a PKH and its real owner can still reveal someone's entire transaction history. So it's better, for privacy, to use multiple PKHs (or addresses).

3. Avoiding Costly Typing Errors With Addresses

Typing a 20-byte PKH by hand can be error-prone. A single character mistake can send funds into the void. Enter Bitcoin addresses (or cookie token addresses), which include a checksum.

Q6: What is a Bitcoin (cookie token) address in this analogy?

It’s the PKH plus:

• A version byte (often 0x00) at the start.
• A 4-byte checksum at the end to detect typos.
• Encoded in base58check to avoid confusing characters and to make addresses more user-friendly.

Figure 10. Base58check encoding transforms a PKH into a user-friendly address.

Q7: How does base58check encoding help reduce errors?

• Checksum: A 4-byte checksum (from double-SHA256) detects most typos. If the address is misspelled, the checksum won’t match.
• Short alphabet: It excludes look-alike characters like 0 (zero) vs. O (capital O), reducing confusion.

Figure 15. Decoding an address checks the checksum, preventing funds from going to a non-existent address.

4. Boosting Privacy by Using Multiple Addresses

Q8: Can Acme Insurances still track your cookie-eating if they identify your PKH or address just once?

Potentially yes. Once they match your PKH to you, they see all your spreadsheet activity tied to that PKH. But if you frequently use new PKHs or addresses, it’s harder to link them all to you.

Figure 1. Addresses (PKHs) help with privacy, but using new addresses per payment is even more private.

Q9: Is there any drawback to using many addresses?

It can be a bit more complex to manage, but modern wallet software automates generating new addresses and keeping track of them, improving privacy and security.

5. Key Takeaways / Summary

• Replacing names: The spreadsheet or ledger now uses public key hashes instead of personal names.
• PKH creation: Public key → SHA256 → RIPEMD160 → 20-byte PKH reduces size and adds a layer of security.
• Addresses (Base58check): User-friendly format with a version byte and a 4-byte checksum to prevent loss of funds through typos.
• Network vs. Users: Lisa (or the Bitcoin network) sees only PKHs. Humans use addresses for safety and ease.
• Privacy remains partial: PKHs are pseudonymous. Reusing addresses can still link them to one identity, so best practice is new address per transaction.

End of Study Notes for Chapter 3. You now understand how Bitcoin addresses (PKH + base58check) reduce errors and improve privacy over using names or raw public keys!