A Bitcoin wallet is a key-management and transaction tool, not a container holding digital coins. It derives receiving information, finds spendable outputs, constructs transactions, produces signatures, and helps the user back up the authority needed to recover funds. Its security model matters as much as its interface.
Address types are visible encodings of particular spending conditions and network information. They influence compatibility, transaction weight, error detection, and sometimes what features a wallet can use. Choosing an address is therefore not cosmetic, yet the prefix alone does not prove who controls it or whether a payment is safe.
What you will learn
- Explain what custodial, software, and hardware wallets actually control
- Recognize common mainnet address families and their practical tradeoffs
- Build a backup and test process that includes keys, scripts, and recovery context
Custody begins with who can produce signatures
In a self-custody wallet, the user controls keys that can satisfy the relevant spending conditions. In a custodial service, the provider generally controls on-chain keys and records the user's claim in its internal database. A balance shown in either interface can look similar while the failure and recovery models differ substantially.
Software wallets keep signing capability on a general-purpose device unless paired with an external signer. Hardware wallets aim to isolate private-key operations, but users still depend on correct device verification, authentic software, secure backups, and careful review of destination and amount. No device eliminates judgment or operational risk.
Addresses encode destinations, not accounts
Common Bitcoin mainnet forms include legacy addresses beginning with 1, script-hash addresses beginning with 3, native SegWit addresses beginning with bc1q, and Taproot addresses beginning with bc1p. These prefixes help wallets interpret the destination, but the underlying transaction creates an output with specific spending conditions.
Modern SegWit output types can reduce the weight of later spending transactions compared with older forms, which can lower fees at the same fee rate. Compatibility is not universal, especially with older services. The receiving wallet should generate a supported address, and the sender should verify that its software recognizes it for the intended network.
Change is easy to overlook
Because transactions spend whole outputs, paying less than an input's value usually requires a change output. The wallet creates that output to an address it controls. A block explorer may therefore show value going to two new addresses even though only one belongs to the intended recipient.
Poor backup design can lose change. An older nondeterministic wallet may require new backups as it generates keys, while modern deterministic wallets derive many keys from recovery material. Even then, recovery may require knowing the wallet's derivation method, script types, passphrase use, or multisignature configuration, not merely possessing a list of words.
Backups protect access, not device availability
A recovery seed or equivalent backup can recreate key material after device loss, but anyone who obtains it may also recreate spending authority. Backups should resist theft, fire, water, accidental disposal, and memory failure. A passphrase can add separation but creates another secret whose loss can make the backup useless.
A credible recovery plan is tested with an amount small enough to lose. The test should confirm that the restored wallet discovers expected addresses and can sign under the intended policy. For multisignature or descriptor-based arrangements, preserve the complete configuration and key origins needed to reconstruct the spending script.
Address hygiene supports privacy and accuracy
Reusing one address links incoming payments on the public ledger and can make later spending easier to cluster. Generating a fresh receive address does not provide perfect anonymity, but it avoids an unnecessary public link. Wallet coin selection and change handling can still combine outputs in revealing ways.
Users should verify the full destination on a trusted display, confirm the network, and avoid relying on the first and last few characters alone. Clipboard malware and substituted invoices can preserve a familiar-looking pattern. Address checksums catch many typing errors, but they cannot detect a valid address supplied by an attacker.
Common misconceptions
“The wallet device contains the bitcoins, so a broken device destroys them.”
The chain records outputs; the device manages keys. A correct, complete backup can restore spending authority on compatible software when the original device fails.
“All valid Bitcoin addresses work in every wallet and service.”
Older software may not support newer address forms or may apply withdrawal restrictions. Compatibility should be checked before sending, especially during migrations.
“A seed phrase alone always restores every advanced wallet setup.”
Passphrases, derivation paths, script descriptors, multisignature cosigner data, and key origins may be required to reconstruct the intended wallet and locate outputs.
Risks and limitations
- Exposed seed material, malicious wallet software, or signing a substituted destination can lead to irreversible theft without a central recovery process.
- Incomplete backups can omit passphrases, descriptors, cosigner information, or newly generated nondeterministic keys, making apparently preserved funds inaccessible.
- Unsupported address formats or wrong-network destinations can produce failed withdrawals, operational delays, or funds requiring specialized recovery assistance.
- Address reuse and careless coin selection can reveal payment relationships, balances, and counterparties even when no real-world name appears on-chain.
Key takeaways
- Wallets manage keys and transactions; the blockchain records spendable outputs.
- Custodial and self-custodial balances have fundamentally different control models.
- Address types affect compatibility, transaction weight, and available spending features.
- Change outputs return unused input value to a destination controlled by the sender.
- A backup is credible only when its full recovery context has been tested.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.