A Bitcoin seed phrase promises something specific: from those words, compatible software can rebuild the same private keys and addresses that your old wallet used. What the seed does not rebuild is the layer you added on top of those keys — the labels, payment notes, and account names that turned a list of opaque addresses into something you could actually understand. Recovery is easy to get wrong precisely because these two things are usually bundled together, and they do not survive the same procedure.
Keys, scripts, and annotations are three different jobs
The hierarchical deterministic wallet specification (BIP32) works in two parts. It first shows how a tree of keypairs is derived from a single seed, then describes how to build a wallet structure on that tree. That structure is advisory, and it is explicit about one limit: an account name has to be entered by hand and cannot be synchronized through the blockchain. Rebuilding the keys is one task; remembering what they were for is another.
A second task is reconstructing the scripts the wallet was watching. Output script descriptors (BIP380) give a language for describing collections of output scripts, including their derivation paths, so a backup can identify which scripts and keys to produce. That gets you the right addresses. It still does not tell you why a particular payment was made.
The third task — preserving the annotations themselves — is what most people forget. The Wallet Labels Export Format (BIP329) exists to make this portable. It defines a UTF-8 JSON Lines file: one JSON object per line, each carrying a type and a reference that ties a label to a specific transaction, address, input, output, public key, or extended public key. The format is marked Draft and Informational, and it defines no private-key record types, so a label export on its own can never restore spending authority.
Verify by reference, not by wording
The useful test after migrating wallets is whether each note reattached to the object it describes. BIP329 lets an importing wallet ignore record types it does not store and truncate labels that are too long, so a shared file format is not proof that every annotation survived. Compare important records by reference — the transaction ID and output index — rather than by matching text, because a transaction-level note and an output-level note can carry identical words yet refer to different objects.
The prudent order is to export a protected copy before retiring the old wallet, import through the receiving wallet’s documented process, then check long notes for truncation and hunt down unmatched references. Keep the original until unsupported record types and missing annotations have been reviewed.
An export without keys is still sensitive
It is tempting to treat a label file as harmless because it cannot authorize a spend. That is wrong. BIP329 calls the data privacy-sensitive and recommends encryption in transit and at rest, because the file can contain addresses, transaction references, extended public keys, and descriptions that connect payments to people and purposes. Delete unencrypted copies once the protected one is verified.
None of this changes the core rule: a seed restores keys, descriptors help rebuild scripts, and only a deliberately separate metadata backup restores the context you spent time writing. Confirming one of these does not confirm the others.
Source: BTCUSA.