Bitcoin Backup Incomplete
Seed Phrases, Passphrases, and Derivation Paths
This memo is published by CustodyStress, an independent Bitcoin custody stress test that produces reference documents for individuals, families, and professionals.
The Seed Phrase Is Not Enough
Having a backup differs from having a complete backup. Holders who created backups may wonder whether those backups contain everything needed for successful recovery. A bitcoin backup can be incomplete in ways that are not obvious—missing elements that only become apparent when recovery is attempted. The backup exists; sufficiency does not.
Completeness depends on what recovery requires. A backup that works for one recovery scenario may fail for another. Different circumstances demand different information. What counts as complete varies with situation, and situations cannot always be predicted in advance.
The Seed Phrase Is Not Enough
Seed phrases are often treated as complete backups. Store the twelve or twenty-four words, and recovery is handled. This simplification misleads. Seed phrases alone may not be sufficient to recover funds, depending on how the wallet was configured.
Passphrases add a critical component that seed phrases do not capture. A wallet using a passphrase (sometimes called the "25th word") generates different addresses than the same seed phrase without the passphrase. Backing up only the seed phrase without the passphrase leaves the passphrase-protected funds inaccessible.
Derivation paths determine which addresses the seed phrase produces. Different wallet software may use different derivation paths by default. Recovering with the seed phrase in different software may show different addresses—and potentially zero balance if the wrong path is used. The seed phrase works; the addresses do not match.
Script types affect what recovery produces. Legacy addresses, SegWit addresses, and native SegWit addresses all can derive from the same seed phrase using different parameters. Without knowing which script type was used, recovery may find some funds but miss others stored at addresses the recovery process does not check.
Missing Metadata
Backups often lack metadata that matters for recovery. The raw cryptographic material exists, but information about how to use it does not. This metadata gap creates barriers that having the seed phrase alone does not overcome.
Wallet identification tells recovery what software to use. Which wallet application was this seed phrase created for? Different wallets have different defaults, different features, and different quirks. Without knowing the original wallet, recovery becomes trial and error.
Configuration information captures choices made during setup. Did the holder enable certain features? Change default settings? Use specific options? These choices may affect recovery and are not encoded in the seed phrase itself.
Transaction history provides context that raw keys lack. What addresses have been used? What amounts were involved? This information helps verify that recovery is correct and complete. Without history, the holder may not know whether recovery found everything.
Multisig Complexity
Multisig backups face unique completeness challenges. Multiple keys must be recoverable, and the configuration that ties them together must also be preserved. Backing up individual keys without configuration information produces pieces that cannot be reassembled.
Wallet descriptors or equivalent configuration data specify how keys combine. This information tells recovery software which addresses belong to the multisig wallet and how to construct valid transactions. Without it, having all the seed phrases may not be enough to spend the funds.
Key identification matters when multiple seeds exist. Which seed phrase corresponds to which key in the multisig? If labels were not preserved, recovery may require testing combinations. Three keys with unclear identities create ambiguity that clear labeling would prevent.
Threshold information specifies how many signatures are needed. A 2-of-3 multisig behaves differently than a 3-of-3 multisig. If the backup does not record the threshold, recovery attempts may use wrong parameters and fail despite having correct keys.
Access Information Gaps
Backups exist somewhere. That somewhere requires access. Information about how to reach the backup may be missing even when the backup itself is properly stored.
Location documentation tells where to look. A backup in a safe deposit box needs bank name, box number, and access credentials. A backup with a family member needs current contact information. Location without accessibility information provides incomplete coverage.
Authentication requirements include PINs, passwords, or credentials. A hardware wallet backup includes the seed phrase but may not include the device PIN. An encrypted digital backup includes the file but may not include the encryption password. Layers of protection add layers of required information.
Legal or formal requirements affect access. Safe deposit box access requires specific documentation. Trust-held backups require trustee cooperation. These formal requirements may not be obvious to whoever attempts recovery, especially if that person is an heir unfamiliar with the arrangements.
Procedural Knowledge Gaps
Even complete technical backups may lack procedural information. Having all the components differs from knowing how to use them. The gap between components and knowledge can render complete backups practically incomplete.
Recovery procedures vary by wallet and configuration. The steps to recover a specific setup depend on what that setup involves. Generic instructions may not apply to specific configurations. Someone following wrong procedures may fail despite having correct materials.
Software requirements may not be documented. What software is needed? Where to download it? How to verify authenticity? Recovery may require tools the backup does not mention and the recovering party does not know to obtain.
Sequence matters for some recovery procedures. Steps done in wrong order can produce errors or security exposures. A backup that lists components without specifying sequence leaves the recovering party to guess at order, risking mistakes.
Verification Gaps
A backup may be incomplete in ways that only verification reveals. Transcription errors, corruption, and encoding problems all create backups that appear complete but fail when used. Unverified completeness is assumed completeness—which may not match reality.
Character-level accuracy matters for seed phrases. A single wrong letter invalidates the phrase. Handwritten backups are particularly prone to ambiguity—is that letter a "q" or a "g"? Did the holder write the complete word or an abbreviation? Small errors produce total failure.
Data integrity degrades over time. What was accurate when created may become corrupted through storage. Paper fades. Digital files corrupt. Metal engravings may be readable today and illegible in twenty years. Backup completeness at creation does not guarantee completeness later.
Checksum validation catches some errors but not all. A seed phrase that passes checksum validation is internally consistent but may still be wrong for this wallet. Checksums verify format, not correspondence to the intended wallet. Passing checksum provides false confidence when other errors exist.
Heir-Specific Incompleteness
What suffices for the holder may not suffice for heirs. The holder can fill gaps from memory and improvise solutions. Heirs cannot. A backup that works for the holder may be incomplete for inheritance purposes.
Context that lives in the holder's mind does not transfer. Why certain choices were made, what to do if something unexpected happens, how to troubleshoot problems—this context helps the holder succeed but is absent for heirs relying only on documented backup.
Skill assumptions embedded in backup design may exceed heir capabilities. The holder created a backup assuming a certain level of technical competence. If heirs lack that competence, the backup is effectively incomplete for their purposes even if technically complete.
Questions cannot be answered after the holder is gone. When the heir encounters confusion, they cannot ask the holder what was meant. Every ambiguity in the backup becomes a potential stopping point. What the holder would have clarified in person remains unclear in their absence.
Testing Reveals Incompleteness
The definitive test of backup completeness is attempted recovery. Using only the backup—without access to the original wallet, without the holder's memory, without additional information—either succeeds or reveals what is missing.
Simulated recovery by someone other than the holder tests more thoroughly. The holder may unconsciously supplement the backup with remembered information. A different person cannot do this and will encounter gaps the holder would have bridged.
Recovery under realistic conditions tests further still. Comfortable conditions with unlimited time differ from stressful conditions with pressure. A backup that works slowly and carefully may fail when grief, urgency, or confusion are present.
Periodic re-testing catches drift. A backup complete when tested may become incomplete as circumstances change. Regular testing—not just initial testing—confirms ongoing completeness against evolving requirements.
Summary
A bitcoin backup can be incomplete even when a seed phrase exists. Missing passphrases, unknown derivation paths, absent metadata, multisig configuration gaps, inaccessible storage, missing procedural knowledge, verification failures, and heir-specific deficiencies all create incompleteness that the presence of a seed phrase does not address.
What counts as complete depends on what recovery requires, and different scenarios require different elements. A backup complete for one situation may be incomplete for another. Universal completeness would require anticipating all possible recovery scenarios.
Testing reveals incompleteness that assumption misses. Actual recovery attempts using only backup materials—ideally by someone other than the holder—expose gaps that theoretical assessment cannot find. The holder who wonders whether their backup is complete can answer definitively only through testing.
System Context
Non-Spend Backup Verification as a Proof Gap
For anyone who holds Bitcoin — on an exchange, in a wallet, through a service, or in self-custody — and wants to know what happens to it if something happens to them.
Start Bitcoin Custody Stress Test$179 · 12-month access · Unlimited assessments
A structured, scenario-based diagnostic that produces reference documents for your spouse, executor, or attorney — no accounts connected, no keys shared.
Sample what the assessment produces