Enter the same recovery phrase into two wallets and you may see two different sets of addresses. That is usually not a bug and not a sign that the backup is corrupt. A seed determines the private keys an account can derive; it does not, by itself, record which derivation path the wallet should follow or which script should receive each payment. When those two details are missing or mismatched, the same seed quietly opens a different account.
Three questions have to be kept apart: which child key is derived, how an extended key is serialized for export, and what the blockchain output actually commits to. Conflating them is what turns a recoverable mismatch into a mistaken migration.
Bitcoin’s most common single-signature accounts are defined by three improvement proposals. BIP49 is pay-to-witness-public-key-hash wrapped inside pay-to-script-hash, the nested-SegWit account, derived at the purpose path 49′ and exported with the ypub prefix on mainnet. BIP84 is native pay-to-witness-public-key-hash at 84′, exported as zpub. BIP86 is single-key Taproot at 86′; it reuses the xpub serialization because no dedicated Taproot prefix was defined. The number after m, the purpose, is what separates these accounts, not a cosmetic label.
The output each account builds is different too. BIP49 commits to a 20-byte script hash wrapped in a HASH160 EQUAL pattern, so spending it reveals the inner witness program in the scriptSig and places the signature and public key in the witness. BIP84 drops the wrapper and pays directly to a version-0 key-hash program. BIP86 pays to a 32-byte Taproot output key produced by applying the TapTweak to the internal key, which is not the same as dropping the derived public key into the output unchanged.
The prefix mistake follows from treating serialization as derivation. Re-encoding an extended public key exported from the 49′ account with zpub version bytes changes how the key is displayed, not which account it belongs to. The re-labelled key still describes the same child at the same path; an application that accepts it has not proven it reconstructed the 84′ account. And no amount of re-labelling moves money already received. Moving a balance from a nested-SegWit output to a Taproot output is an on-chain spending transaction, not an export-format repair.
This is why BIP86 calls out a common recovery failure directly: many backups simply do not record the derivation path and script type. An empty wallet after a restore does not prove the backup controls nothing; it may only mean the wallet is looking at the wrong purpose path and finding no history there. BIP49 and BIP84 warn the same way, because an incompatible wallet may simply not discover the account at all.
A useful diagnostic order is to compare the complete path first, then the script, then the export. Record the network, the account standard, the full derivation path, the receiving or change branch, and an explicit address index. Check the candidate wallet’s documentation for support of that exact account and script construction; accepting the recovery words is not the same as supporting the account. Compare a previously recorded receiving address at the same branch and index, and repeat at further indices where records exist. Only then is a prefix converter relevant, and even then only to answer an export-compatibility question.
Keep secret material out of the loop: recovery words, private keys and extended private keys belong inside the trusted signer’s documented recovery process, never in a converter. And treat address agreement as a narrow result; it proves the same account can be reproduced, not that a payment instruction is authenticated or that the signer can complete a spend. Those remain separate checks.
Source: BTCUSA.