Bitcoin Setup Sanity Check

Post-Setup Sanity Check for Basic Functionality

This memo is published by CustodyStress, an independent Bitcoin custody stress test that produces reference documents for individuals, families, and professionals.

What Simple Verification Reveals

A bitcoin setup sanity check occurs when holders complete initial custody configuration and want to verify basic functionality before relying on the arrangement. The holder has written down seed phrases, configured hardware wallets, or created backup documentation. They want confirmation the setup will work when needed without conducting full stress testing that introduces security risks.

Sanity checking aims to catch obvious mistakes like wrong word sequences, illegible handwriting, or incorrect backup locations. These checks operate within the holder's current knowledge and available time. They reveal surface-level errors but miss deeper configuration problems that only manifest under conditions the holder cannot easily simulate.

---

What Simple Verification Reveals

Holders can verify they possess something by looking at it. The seed phrase backup sits in the safe. The hardware wallet is in the drawer. These physical confirmations show the items exist where expected. They do not confirm the items contain correct information or function as intended.

Reading seed phrases back confirms they are legible. The holder wrote down twelve words during wallet setup. Checking later confirms those words are readable. This catches illegible handwriting before it causes recovery failure. It does not catch the wrong words being written down or words being in the wrong order.

Blockchain balance checks confirm funds arrived. The holder sent bitcoin to an address. Checking the blockchain shows the transaction confirmed and the address contains the expected amount. This verifies the transfer completed. It does not verify the holder can spend from that address when needed.

Simple bitcoin setup sanity checks can count backup copies. The plan called for three seed phrase copies in different locations. The holder visits each location and confirms copies exist. This reveals missing backups. It does not reveal whether all copies contain identical information or whether any copy is actually usable for recovery.

---

The Recovery Test Dilemma

Testing recovery procedures requires exposing seed phrases to the recovery process. The holder uses their backup to restore a wallet and verify it generates the correct addresses. This test proves the backup contains valid information and the restoration process works.

Each recovery test increases exposure. The seed phrase is handled, entered into devices, and potentially observed by anyone nearby. Repeated testing for bitcoin setup sanity check purposes creates multiple exposure opportunities. The testing itself introduces risk the test is meant to reduce.

Test environments may differ from real recovery conditions. The holder tests recovery in a quiet room with time to carefully enter words. Actual recovery might occur during an emergency while stressed and rushed. The test environment success does not guarantee success under real conditions where cognitive load, time pressure, or technical difficulties create failure modes the test did not include.

Destructive testing requires abandoning the original setup. The holder tests recovery by wiping their hardware wallet and restoring from backup. If the restore fails, the original setup is gone. Testing proves nothing while destroying the only working configuration. Non-destructive testing using separate devices provides less certainty because differences between test and production environments may hide incompatibilities.

---

Passphrase Verification Gaps

Passphrases add a secret word to seed phrases. The combination of seed phrase plus passphrase generates wallet addresses. The passphrase must be remembered or documented separately. Sanity checking this setup involves specific challenges.

Entering the passphrase into a wallet generates addresses. The holder verifies these match expected addresses, confirming the passphrase is correct. This test works when performed immediately after setup. Memory degradation over months or years means a passphrase verified today may be forgotten later. The sanity check captured point-in-time accuracy but not long-term memorability.

Documented passphrases need to be findable and interpretable. The holder writes the passphrase in a notebook. Sanity checking confirms the notebook exists and is readable. It does not test whether future users understand which written phrase is the passphrase versus other notes in the notebook. Context that is obvious today becomes ambiguous years later.

Multiple passphrases can coexist with the same seed phrase, each generating different wallets. The holder intended to use passphrase A but documented passphrase B. A bitcoin setup sanity check testing passphrase B succeeds, generating addresses. These are not the addresses holding the bitcoin. The test passed but verified the wrong thing. The real passphrase remains untested.

---

Documentation Interpretation Testing

Custody documentation describes procedures for inheritors or future holders. Sanity checking documentation involves attempting to follow the instructions. The holder reads their own documentation and executes the described steps. Successful execution confirms the instructions are followable by someone familiar with the setup.

Self-testing documentation creates false confidence. The author knows what they meant and mentally fills gaps in written instructions. An inheritor reading the same documentation lacks this context and may interpret ambiguous phrases differently. The documentation that seemed clear to its author becomes confusing when read by others.

Technical terminology makes sense to holders at the time of writing. Months or years later, the same holder may no longer remember what specific terms meant. A note says "use the blue device" when two hardware wallets existed - one blue, one black. The blue device has since been replaced. The documentation now contains an ambiguous reference that made sense when written but no longer maps to current reality.

Sequential procedures are particularly vulnerable to interpretation gaps. Step three says "after verifying the balance" but step two did not explicitly mention balance verification. The gap was obvious to the author because they knew balance verification was implicit. The reader does not know whether they missed an instruction or whether balance verification happens elsewhere. The bitcoin setup sanity check of documentation finds clear errors but misses these implicit dependencies.

---

Multi-Device Consistency

Some custody setups involve multiple devices that must remain synchronized. A holder uses both a hardware wallet and a mobile wallet derived from the same seed. Sanity checking requires verifying both devices generate matching addresses and can sign transactions for the same bitcoin.

Matching addresses on different devices suggests consistent setup. Both devices derive the same addresses from the seed phrase. This confirms basic derivation path consistency. It does not confirm both devices will remain synchronized as firmware updates, app updates, and standards evolution occur over years.

Version skew creates gradual divergence. The hardware wallet firmware stays at version 1.5 because updates stopped when the manufacturer discontinued the model. The mobile app updates to version 3.0. New addresses generated after the divergence differ between devices. The bitcoin setup sanity check performed at setup time showed consistency. Years later, the devices have drifted incompatibly.

Backup completeness across devices is difficult to verify. The holder backs up the seed phrase thinking this protects all devices. One device used a custom derivation path not reproducible from the seed alone. The backup captures the primary device but not the variant configuration. Testing the backup on the primary device succeeds. Recovery from backup for the variant device fails because the special configuration was not documented.

---

The Exchange Account Assumption

Exchange accounts feel simpler than self-custody. The holder creates an account, enables two-factor authentication, and considers the setup complete. Sanity checking involves logging out and back in to verify password and 2FA work. This test confirms current access.

Long-term exchange access depends on factors beyond login credentials. Email addresses must remain active. Phone numbers must remain controlled. Identity documents must stay valid. The bitcoin setup sanity check verifies login works today. It does not test whether the email account will be accessible in five years or whether the phone number will still receive SMS codes after the holder changes carriers.

Exchange KYC updates create periodic access barriers. The exchange requires updated identity verification. The holder's documents have expired or changed addresses. Account access freezes pending new verification. The original sanity check showed login worked. The latent requirement for maintaining KYC compliance was not tested because it had not yet triggered.

Account recovery procedures often require information the holder does not actively track. The exchange asks security questions set years ago. The holder does not remember the answers. The exchange requires proof of original funding source. The bank account used has since closed. The sanity check tested normal login, not recovery from forgotten credentials or changed life circumstances.

---

Inheritance Handoff Simulation

Some holders simulate inheritance handoff during a bitcoin setup sanity check. They give recovery documentation to a spouse or child and ask them to attempt recovery using only the provided information. This reveals whether the documentation is actually usable by inheritors.

Simulation occurs with the original holder present and available. The inheritor gets stuck and asks questions. The holder provides clarification. The simulation succeeds with this assistance. Real inheritance occurs when the holder is not available to clarify. The simulation tested assisted recovery, not unassisted recovery that will actually occur.

Cognitive state during simulation differs from actual stress. The simulated inheritor knows this is a test with no real consequences. They approach it calmly and methodically. Actual inheritance occurs while grieving, possibly under financial pressure, and without the safety net of knowing the real owner can fix problems. The simulation tested technical steps, not execution under stress.

Temporal distance creates environmental changes the simulation cannot capture. The simulation uses current devices and current software. Years later, devices have been replaced, software has updated, and service providers may have changed interfaces or gone out of business. The simulated sanity check confirmed setup worked in current conditions. It did not test survivability across the environmental changes that will occur before actual recovery.

---

Metadata Preservation Testing

Bitcoin wallets may have metadata like labels for addresses or notes about transactions. This metadata exists only in wallet software, not on the blockchain. Sanity checking metadata preservation requires verifying backups include this information.

Seed phrase backups restore addresses and balances. They do not restore metadata unless specifically backed up separately. The holder assumes their seed phrase backup is complete. Testing restoration shows addresses and balances appear correctly. Labels and notes are missing. The backup is technically complete for fund access but practically incomplete for understanding the wallet's transaction history.

Encrypted wallet backups include metadata but require correct decryption. The holder backs up an encrypted wallet file. The bitcoin setup sanity check involves decrypting the backup and verifying its contents. This works when the decryption password is fresh in memory. Years later, password uncertainty makes multiple attempts necessary, possibly exhausting allowed attempts and permanently locking the backup.

Cloud sync services automatically back up wallet data including metadata. The sanity check confirms sync is working by adding a label and seeing it appear on other devices. This tests current sync functionality. It does not test whether the cloud service will maintain the data for years, whether the account will remain accessible, or whether file format changes will make old backups unreadable.

---

Address Reuse Detection Limits

Privacy and security both benefit from avoiding address reuse. Holders who understand this principle may attempt to verify their wallet does not reuse addresses. The sanity check involves examining the address list and transaction history looking for repeated addresses.

Visual inspection of addresses fails to detect subtle reuse. Addresses are long hexadecimal strings that look similar. The holder scans a list and sees different characters, concluding addresses are unique. Two addresses differ by a single character that the holder missed. The addresses appear unique in the bitcoin setup sanity check but are actually being reused due to software bugs or misconfiguration.

Some reuse is intentional for change addresses. The wallet automatically generates change addresses and may reuse them according to its algorithm. The holder checking for reuse cannot easily distinguish intentional change address reuse from problematic receiving address reuse without deep understanding of how their specific wallet handles change.

Future reuse cannot be detected at setup time. The wallet will reuse addresses months later due to software bugs that only trigger under specific conditions. The initial sanity check showed unique address generation. The reuse occurs later due to state the wallet entered after the check was performed. Point-in-time verification misses time-dependent failure modes.

---

The Checklist Illusion

Checklists provide structure for bitcoin setup sanity checks. The holder follows items: seed phrase written, backup stored, password set, test transaction sent. Each item is checked off. The completed checklist creates confidence that the setup is complete and correct.

Checklist items describe actions, not outcomes. "Backup stored" means the holder put something in storage. It does not confirm the stored item is complete, correct, or retrievable. The checklist tracks task completion, not task effectiveness. All items can be checked while the backup actually being stored is incomplete or incorrect.

Checklists cannot cover all possible error modes. They capture known failure patterns the checklist author anticipated. New failure modes, especially those emerging from software updates or environmental changes, are not on the list. The holder completes every item and believes the setup is sound. Unchecked failure modes remain untested.

Following checklists discourages independent thinking. The holder focuses on completing listed items rather than considering whether the list is comprehensive or whether their specific situation needs additional checks. The checklist becomes a ceiling on thoroughness rather than a floor. The bitcoin setup sanity check ends when the list is complete, even if obvious gaps exist beyond the list's scope.

---

Professional Review Boundaries

Some holders hire professionals to review their setup. The professional examines the custody arrangement and confirms it meets basic criteria. This review provides external validation beyond self-assessment.

Professional review occurs at a point in time using information the holder chooses to share. The professional sees the setup as it exists during the review. Changes after the review are not captured. Information the holder forgot to mention or considered irrelevant creates gaps in what the professional assessed versus what actually exists.

Review scope is limited by time and cost. A comprehensive security audit examines every aspect of the custody arrangement. This level of review is expensive and time-consuming. Most holders request basic sanity checking that catches obvious errors within limited review hours. Subtle configuration problems requiring deep analysis may exceed the review scope the holder purchased.

Professional opinions reflect the reviewer's assumptions about future conditions. The reviewer confirms the setup works under current technology and service provider landscapes. Their opinion is valid given those assumptions. Market changes, technology evolution, or service provider failures can invalidate assumptions the professional reasonably held at review time. The bitcoin setup sanity check gave point-in-time assurance within the professional's stated assumptions, not guarantees of future functionality across all possible environmental changes.

---

Outcome

Bitcoin setup sanity checks detect obvious configuration errors like missing backups, illegible documentation, or basic login failures. They confirm physical components exist and simple procedures work under current conditions. These checks provide value by catching surface-level mistakes before reliance begins.

Deeper configuration problems resist detection through sanity checking. Recovery testing introduces exposure. Passphrase verification captures point-in-time accuracy, not long-term memorability. Documentation self-testing creates false confidence because authors mentally fill their own gaps. Multi-device consistency checks miss version skew that develops over time. Exchange access verification tests current login, not long-term dependency maintenance.

Inheritance simulations differ from actual stress conditions. Metadata preservation failures appear after recovery succeeds for funds. Address reuse detection misses subtle duplication or future bugs. Checklists create confidence through task completion without verifying task effectiveness. Professional reviews provide point-in-time external validation within bounded scope and stated assumptions. The bitcoin setup sanity check reveals what it is designed to reveal while leaving latent failure modes untested until stress events make them visible.

---

System Context

Bitcoin Custody Failure Modes

Bitcoin Backup Path Testing

Bitcoin Backup Incomplete

← Return to CustodyStress