Keys & Addresses

An address is not a bank account number in a central database. It is a compact encoding of a locking condition — usually “prove you control this public key.”

Complete Step 1 // Required reading in the study plan above, then continue here.

Step 2 — Core idea: private → public → address

Wrong address type, wrong network prefix, or a typo can permanently lose funds. Validate addresses and know what each format commits to.

Analogy: The private key is the only key to a mailbox. The public key is a lock design others can verify. The address is the mailbox label so people can send mail without seeing the lock’s internals.

private key  →  public key  →  hashing / tweaking  →  address string

Never type private keys into random websites. In apps, keep keys in secure modules or hardware wallets.

Testnet/regtest use different HRPs (tb1, bcrt1, etc.). Always check the network.

Base58Check (legacy) mixes numbers and letters and appends a checksum. Bech32 has stronger error detection; Bech32m (BIP-350) tweaks the checksum for Taproot (bc1p). If a library says “invalid checksum,” regenerate — do not hand-edit the string.

HD wallets derive many keys from one seed. Back up the seed/mnemonic, the descriptor or derivation standard, and multisig cosigner records if applicable.

Done when: You can map each address family in the table to an encoding and network HRP.

Step 3 — Try it on regtest (lab)

bitcoin-cli -regtest getnewaddress "" "bech32"
bitcoin-cli -regtest getnewaddress "" "bech32m"
bitcoin-cli -regtest getaddressinfo <addr>

Read scriptPubKey and desc — they connect the address string to the underlying lock.

Builder habits

• Validate with a library, not regex alone
• Refuse sends to the wrong chain
• Prefer Bech32/Bech32m for new wallets (fees + error detection)

Done when: Lab evidence (two address types + getaddressinfo + one linking sentence) is complete.

Next lesson

Blocks & Chain — where confirmed UTXOs live and how reorgs affect finality.