Keys & Addresses

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

Why this matters

Wrong address type, wrong network prefix, or a typo can permanently lose funds. Builders must validate addresses and understand what each format commits to.

Analogy

Your 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 printed so people can send mail without seeing the lock’s internals.

One-way derivation

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.

Address families you will see

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

Builder checklist

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

Encoding details builders hit

Base58Check (legacy) mixes numbers and letters, omits confusing characters, and appends a checksum. Bech32 uses a different alphabet and stronger error detection; Bech32m (BIP-350) tweaks the checksum constant for Taproot (bc1p).

If a library says "invalid checksum," do not "fix" the string by hand, regenerate from keys/descriptors.

Derivation vs address

HD wallets derive many keys from one seed. Addresses are presentations of locking conditions for specific keys/scripts. Back up:

1. The seed/mnemonic
2. The descriptor or derivation standard you used
3. Multisig cosigner records if applicable

Try it

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

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

Worked mental model

Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

Hands-on habit

Every protocol idea should be paired with one local experiment:

1. Reproduce the happy path on regtest (or Polar for Lightning)
2. Break it on purpose (wrong fee, expired invoice, offline peer)
3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)

That habit turns reading into builder instinct.

Glossary check

Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

Resource order

Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Next steps

See how confirmed UTXOs live inside blocks, then learn the full transaction structure.