A beginner-friendly guide to how one wallet creates many receiving and change addresses, and what you need to restore them.
Introduction
Open a Bitcoin wallet twice and you may see two different receiving addresses. Both can belong to the same wallet. The wallet does not need a new seed phrase for each address; it follows a repeatable method for deriving related keys and addresses.
That method is called hierarchical deterministic, or HD, wallet derivation. It helps a wallet organize many addresses under one root, use fresh receiving addresses, recognize its own change, and recover its history from a suitable backup.
The details matter when you change devices. Two wallet apps can start from the same recovery words yet display different addresses if they use different passphrases, derivation paths, accounts, or address policies. This guide explains the process without asking you to perform cryptography by hand.
The Short Answer
An HD Bitcoin wallet starts with a seed, derives a tree of related private and public keys, selects a derivation path for a particular account and address index, then applies an output or script policy to produce a Bitcoin address. The same inputs produce the same address again, which is why a compatible wallet can rediscover it during recovery.
For a common native SegWit account, an example receiving-key path is m/84’/0’/0’/0/5. The final number is the address index. The corresponding change branch would use 1 in place of the preceding 0. A path identifies a key’s position; the wallet also needs to know how that key is turned into an output script and address.
What Is an HD Wallet?
An HD wallet is a wallet that can derive a tree of keys from one root. BIP 32 describes the key-derivation method. Instead of storing a completely unrelated backup for every new address, the wallet can regenerate related keys from the same root data.
Think of the tree as an organized filing system. An account can have one branch for receiving payments and another for change. Each branch can have address indexes 0, 1, 2, and so on. The wallet records which indexes it has shown or used so that it can continue without repeating addresses unnecessarily.
Many wallets display recovery words generated under BIP 39. BIP 39 turns a mnemonic and an optional passphrase into a binary seed that can feed a BIP 32 wallet. BIP 39 and BIP 32 are related standards, but they are not the same thing, and not every HD wallet uses BIP 39 words.
How a Wallet Gets From a Seed to an Address
The user interface hides several steps. The sequence below describes a common single-signature HD wallet, not every wallet design.
Step 1 The Wallet Obtains Seed Material
A wallet begins with secret seed material generated by a secure random process. A BIP 39 wallet may display a mnemonic phrase for backup. If the user adds a BIP 39 passphrase, that passphrase changes the resulting seed. Entering a different passphrase can therefore open a different, valid-looking wallet with different addresses.
The mnemonic and passphrase are spending secrets. Neither should be pasted into a website, a support chat, or an online address calculator. The article’s path examples contain no real secrets.
Step 2 BIP 32 Creates a Master Key
BIP 32 turns a binary seed into a master extended private key and a chain code. The chain code is extra data used during child-key derivation. The master extended private key can derive further private and public keys. A corresponding extended public key can derive certain public descendants without revealing the private keys.
This is why a wallet can separate address monitoring from transaction signing. A device can display or watch addresses derived from public information while a hardware wallet keeps the private material needed to spend.
Step 3 The Wallet Chooses a Path
A path tells the wallet which child key to derive. Common path layouts separate the address type, coin, account, receiving or change branch, and address index. Wallet software may hide the path from everyday users, but it becomes important during migration and recovery.
Step 4 The Wallet Derives a Public Key
For a receiving address, the wallet follows the selected path to derive the corresponding child public key. A watch-only wallet can do this from a suitable account-level extended public key for non-hardened child paths. It cannot create a valid spending signature from that public information alone.
Step 5 The Wallet Applies Its Output Policy
A public key does not by itself specify every possible Bitcoin address. The wallet chooses an output construction, such as legacy pay-to-public-key-hash, native SegWit, or single-key Taproot. That choice determines the script or witness program a payment will lock to and the address encoding shown to the sender.
For example, BIP 84 defines a common path scheme for native SegWit P2WPKH accounts. BIP 86 defines a scheme for single-key Taproot P2TR outputs. The same underlying seed can be used with both schemes, but the paths and resulting addresses differ.
Step 6 The Wallet Records and Watches the Address
The wallet shows the address to the user and watches the blockchain for payments to the matching output script. Bitcoin itself does not store a label saying an address belongs to your wallet. Your wallet recognizes the output because it can recreate the relevant key and script under its policy.
How to Read a Bitcoin Derivation Path
Many wallets use a five-level pattern from BIP 44 and related standards:
m / purpose’ / coin_type’ / account’ / change / address_index
Consider the illustrative path m/84’/0’/0’/0/5:
· m identifies the master root of the key tree.
· 84′ indicates the BIP 84 purpose for a native SegWit P2WPKH account.
· 0′ is the registered Bitcoin mainnet coin type in this convention.
· 0′ selects account zero, the first account.
· 0 selects the external or receiving branch.
· 5 selects the sixth child index, because counting starts at zero.
The apostrophe marks a hardened derivation step. Wallet interfaces sometimes write the same idea with h, such as 84h. The path m/84’/0’/0’/1/5 follows the same account but uses the internal or change branch.
These are conventions, not a guarantee that every wallet uses exactly the same layout. Record the actual path or wallet descriptor supplied by the software that created your wallet.
Why There Are Receiving and Change Addresses
The common BIP 44 style reserves branch 0 for external receiving addresses and branch 1 for internal change addresses. A receiving address is one you can give to someone who will pay you. A change address receives the unspent remainder when your wallet builds a transaction from one or more UTXOs.
Suppose a wallet controls a 0.10 BTC UTXO and sends 0.03 BTC. After the fee, the remaining value normally returns to a new output controlled by the same wallet. That output may use an address from the change branch. The numbers are only an illustration; actual fees and coin selection vary.
Change is easy to miss during recovery. A wallet that scans only the receiving branch may show an incomplete balance even though the change outputs are still controlled by the same keys. A complete restore should know both branches and the relevant script policy.
Why Wallets Show Fresh Receiving Addresses
An HD wallet can generate another receiving address by advancing the index. Using a fresh address for each payment can reduce the amount of activity visibly tied to one reused address. It also helps a merchant match payments to invoices.
An older address does not stop working merely because the wallet displayed a newer one. The wallet should continue watching earlier addresses it generated. Reusing an address is usually a privacy choice rather than a requirement for receiving funds; check your wallet’s own behavior if you rely on an address for recurring payments.
Fresh addresses do not make every payment anonymous. Blockchain analysis can still connect activity in other ways, especially when outputs are later spent together. Address rotation is one privacy measure, not a promise of anonymity.
What Are xpubs and xprvs?
An extended private key, often written as an xprv, includes a private key and chain code at a chosen point in the tree. It can derive private descendants beneath that point and can ultimately authorize spending. Treat it as highly sensitive.
An extended public key, often written as an xpub, contains the corresponding public key and chain code. It can derive non-hardened public descendants. A compatible watch-only wallet can use an account xpub to generate and monitor receiving and change addresses without holding spending keys.
An xpub is not a private key, but it is not harmless public data. Sharing an account xpub can expose many present and future addresses in that account, along with their transaction history. It does not necessarily tell another wallet which script type, path origin, or policy to apply; a descriptor can supply that missing context.
Some wallet standards serialize extended public keys with prefixes such as ypub or zpub to signal a particular convention. Do not infer a complete wallet policy from a prefix alone. When moving between apps, export the exact information the original wallet recommends.
Hardened and Non-Hardened Derivation
BIP 32 supports two kinds of child-key derivation. A non-hardened child public key can be derived from a suitable parent extended public key. That is useful for watch-only wallets and devices that create receiving addresses without access to private keys.
A hardened child cannot be derived from a parent xpub alone. The parent extended private key is required at that step. In the common BIP 44 pattern, the purpose, coin type, and account levels are hardened; the receiving/change branch and address index are not.
This division lets an account-level xpub derive addresses within that account without exposing the master secret or other hardened accounts. It also affects security: BIP 32 warns that combining a parent xpub with a leaked non-hardened descendant private key can compromise that branch. Protect both private child keys and the extended public keys associated with them.
Common Bitcoin Address Paths
Several standards use similar path shapes but different purpose numbers and output types:
· BIP 44, m/44’/0’/0’/0/i: a common legacy P2PKH account pattern. Legacy mainnet addresses commonly begin with 1.
· BIP 49, m/49’/0’/0’/0/i: a common P2SH-wrapped SegWit P2WPKH pattern. Its mainnet addresses commonly begin with 3, although that prefix is not unique to this type.
· BIP 84, m/84’/0’/0’/0/i: native SegWit P2WPKH. Mainnet addresses commonly begin with bc1q.
· BIP 86, m/86’/0’/0’/0/i: single-key Taproot P2TR. Mainnet addresses commonly begin with bc1p.
Here i stands for a changing address index. These examples describe single-key account conventions. Multisig, custom scripts, and some wallet products use other paths and additional policy data. Never force a familiar path onto a wallet that documents a different one.
Why the Same Seed Can Show Different Addresses
A common recovery problem is opening a wallet, typing the correct words, and seeing no familiar addresses. That screen alone does not prove the bitcoin has moved. The new software may be looking in the wrong place.
Check these factors against the original wallet’s records:
· Mnemonic and passphrase: one wrong word or a different BIP 39 passphrase produces different keys.
· Network: Bitcoin mainnet and test networks use different settings and address encodings.
· Purpose and script type: legacy, nested SegWit, native SegWit, and Taproot accounts use different policies.
· Account number and path: account zero and account one are different branches.
· Receiving and change branches: funds may sit on either branch.
· Discovery range: a wallet may stop before it reaches addresses used far beyond a run of unused indexes.
· Multisig policy: other cosigners’ public keys, threshold, ordering, and script details must also match.
Do not test random online recovery tools with a real seed phrase. Use the original wallet’s documentation and a trusted offline or hardware-wallet procedure when diagnosing a restore.
What Is the Address Gap Limit?
A recovering wallet cannot scan an infinite number of unused addresses. BIP 44 describes a discovery rule that stops after 20 consecutive unused external addresses. That number belongs to that specification’s algorithm; individual wallets may scan differently or allow users to adjust the range.
If a user generated many addresses without using them and later paid to an address far beyond the scanned range, a standard restore might initially miss it. Funds are not destroyed by the scan limit. The wallet needs to search the correct branch and a sufficiently wide range, using trusted software and accurate recovery information.
How Descriptors and PSBTs Fit In
An output descriptor combines key information with the script and path rules needed to recognize a family of Bitcoin outputs. It can be more useful for recovery than an xpub alone because the wallet learns both which keys to derive and what scripts to watch.
A PSBT carries information for a transaction in progress, including key-origin paths and other metadata that can help a hardware wallet or multisig signer identify the keys it controls. The descriptor helps describe the wallet; the PSBT helps coordinate a particular spend. Both depend on using the correct derivation details.
For a multisig wallet, keep the full policy and all cosigner information in the recovery plan. One participant’s seed phrase is not enough to reconstruct every address or satisfy the spending threshold.
A Practical Backup and Recovery Checklist
· Keep the recovery words and any BIP 39 passphrase in separate, secure locations that fit your threat model.
· Record the wallet software or hardware model, the network, and the account or derivation path it uses.
· Preserve the wallet’s descriptor or multisig policy export when the product offers one.
· Record whether the wallet uses legacy, nested SegWit, native SegWit, Taproot, or another output type.
· Include both receiving and change information; do not save only the latest displayed address.
· Test a restore or watch-only reconstruction with a small controlled amount before relying on a new setup.
· When moving wallets, verify a fresh receiving address on the trusted signing device before sending significant funds.
The exact backup format differs by wallet. Follow the product’s official recovery instructions, especially for multisig and hardware-wallet setups.
Common Misconceptions
One Seed Phrase Means One Bitcoin Address
An HD seed can derive many keys and addresses. An address is one destination within a wallet’s larger key tree and output policy. Backing up only an address does not back up the ability to spend.
An xpub Can Spend Bitcoin
An xpub supports public derivation and monitoring. Signing requires the relevant private keys. An xpub still deserves privacy protection because it can reveal an account’s address history.
A New Wallet Showing Zero Balance Means the Funds Are Lost
A zero balance can result from the wrong passphrase, path, account, script type, policy, or scan range. Check those details before drawing a conclusion. Do not share the seed with anyone offering to diagnose it for you.
A Fresh Address Makes a Payment Anonymous
New addresses reduce address reuse, but they do not erase the public transaction graph. Wallet behavior and later spending patterns also affect privacy.
XTS Perspective
At XTS Insights, we see address derivation as a practical part of Bitcoin literacy. It explains why a wallet can show a new address for every payment and why restoring a wallet requires more than recognizing a string of recovery words.
The useful habit is to preserve the wallet’s secret backup and its public configuration. The first protects the ability to sign; the second helps compatible software find the right addresses and spending rules. Readers who understand both can evaluate wallet migrations, watch-only setups, hardware-wallet use, and multisig recovery with fewer surprises.
Frequently Asked Questions
Can one Bitcoin wallet have many addresses?
Yes. An HD wallet can derive many receiving and change addresses from related key branches. It tracks the addresses that belong to its configured accounts and scripts.
Is a derivation path the same as an address?
No. A path identifies a key’s position in an HD tree. The wallet derives a public key and applies a script policy before showing an address.
Does every Bitcoin wallet use BIP 39 recovery words?
No. BIP 39 is a widely used mnemonic-to-seed method, while BIP 32 defines HD key derivation. Wallets can use different backup or key-generation methods.
What does the apostrophe in a path mean?
It marks a hardened child derivation step. A parent xpub alone cannot derive that child. Some interfaces use an h instead of an apostrophe.
Can I restore a wallet with only its xpub?
An xpub may allow a compatible app to watch non-hardened descendants, but it does not provide spending keys. The app may also need the correct script policy, origin path, and range.
Why does my wallet use a different address each time?
It can advance the receiving-address index and derive a fresh key and address. This can limit address reuse and help the wallet organize incoming payments.
Why does a restored wallet show zero balance?
The restore may be using a different passphrase, network, derivation path, account, address type, multisig policy, or scan range. Verify the original wallet’s settings before assuming the funds are gone.
Is a Bitcoin change address controlled by me?
In a correctly constructed wallet transaction, change is sent to an output controlled by the same wallet. The wallet usually derives that output from an internal branch and should track it during recovery.
Conclusion
Bitcoin wallets can show many addresses because HD derivation generates related keys from one root. A derivation path chooses a key, while the output policy determines what address the wallet displays. Receiving and change branches organize those addresses for ordinary payments.
For day-to-day use, wallet software manages the details. For migration or recovery, the details become essential: keep the correct mnemonic and passphrase, path, account, script policy, and, when applicable, the descriptor and multisig information. A careful test restore is the best way to know that a backup describes the wallet you actually use.
Key Takeaways
· BIP 32 defines an HD key tree; BIP 39 is one common way to create its seed from recovery words.
· A path such as m/84’/0’/0’/0/5 identifies one key position in a common native SegWit account.
· Under the common BIP 44 layout, branch 0 is for receiving and branch 1 is for change.
· An xpub can derive and monitor public descendants, but it cannot sign transactions and can expose financial history.
· An address also depends on a script policy; the same seed can appear different in another wallet when paths or policies change.
· A reliable recovery plan records both spending secrets and the wallet configuration needed to rediscover its outputs.
Leave a Reply