Holes in My Bitcoin Security

Identifying Security Gaps in Existing Custody

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

Types of Security Holes

The question arises with uncomfortable frequency: what are the holes in my bitcoin security? The concern that drives this question is not paranoia but realism—every custody system has vulnerabilities, and the holder's inability to see them does not mean they do not exist. Holes in bitcoin security represent the weak points that an attacker could exploit, that a disaster could trigger, or that time and circumstance could widen into failures. Some holes are known and accepted as acceptable risks; others are unknown because the holder's threat model did not encompass them or because they emerged through changes that occurred without the holder's awareness. Identifying holes before they cause loss requires looking for weaknesses rather than confirming strengths—an uncomfortable but necessary orientation.

This document addresses the types of holes that commonly exist in bitcoin custody systems, how they develop, and why they persist undetected. The existence of holes does not indicate negligence or incompetence; even carefully designed systems have vulnerabilities. What matters is whether the holder has identified the significant holes and made conscious decisions about them, or whether unknown holes wait to reveal themselves through failure. Understanding common hole patterns enables more systematic search than hoping to notice problems spontaneously.

---

Types of Security Holes

Technical holes involve weaknesses in how the custody system is constructed and operated at the technical level. These might include outdated firmware on hardware wallets that contains known vulnerabilities, seed phrases stored in formats or locations that could be compromised, passphrases that are weaker than they feel (using meaningful dates or names that an attacker could guess), or software that has not been updated and may contain exploits. Technical holes also include configuration mistakes—derivation paths set incorrectly, multisig quorums not configured as intended, or backup formats that will not work with current software. The holder may believe the technical implementation is correct while errors lurk in the details.

Operational holes involve weaknesses in how the system is used and maintained over time. Even a technically sound system can be compromised through operational failures: discussing holdings in contexts where the wrong people might hear, clicking links that lead to phishing attempts, entering sensitive information on devices that may be compromised, or letting maintenance tasks slip until backups become unreliable and procedures become hazy. Operational holes are particularly insidious because they do not appear during system design—they emerge through the accumulated behavior of using the system day after day, year after year. A single careless moment can create an opening that careful design cannot prevent.

Environmental holes involve weaknesses in the physical and social context surrounding the custody system. The home where backup materials are stored may be vulnerable to fire, flood, or theft. The relationships with people who know about or participate in custody may change—trusted friends become estranged, family members develop financial problems that create temptation, professional helpers change jobs or retire. The legal and regulatory environment may shift in ways that create new vulnerabilities. Environmental holes exist outside the custody system itself but affect whether the system succeeds or fails. They change over time even when the custody configuration remains constant.

---

How Holes Develop

Initial design limitations create holes from the beginning. No holder can anticipate every threat, and every design process operates within the bounds of the holder's knowledge and imagination at the time of design. Threats the holder did not know about or did not consider produce corresponding holes in the system. These design-time holes persist until the holder's understanding expands to include them, which may happen through education, through observing others' failures, or through experiencing failure personally. The holder who designed the system several years ago may have known less than the holder of today, but the system still reflects that earlier, more limited understanding.

Drift creates holes over time as the system and its context change without coordinated updates. Backup locations change but documentation does not. Software updates alter how wallets work but procedures are not revised. Cosigners move, age, or become less reliable while the system continues to depend on them. The phone number for the lawyer who knows about the bitcoin setup changes when the lawyer switches firms. None of these changes trigger an alarm or require immediate attention, so they accumulate silently until the gap between the documented system and the actual system has grown wide enough to cause failure. Drift is particularly dangerous because it is gradual and does not announce itself; the holder may believe they have the same system they always had when in fact they have a degraded version.

Neglect creates holes when maintenance is deferred or forgotten. Backups should be verified periodically but often are not. Documentation should be updated when things change but often is not. Relationships with keyholders should be maintained but often are not. Each deferred maintenance task represents a potential hole that might not exist if the maintenance had been performed. The holder may intend to get to these tasks eventually, but eventually never arrives, and the holes grow larger while the holder's attention is directed elsewhere. Systems that require maintenance degrade when maintenance is neglected; this is true of custody systems as much as physical infrastructure.

---

Why Holes Persist Undetected

Holes persist because normal operation does not test for them. Checking a balance does not test whether the backup works. Making a transaction does not test whether heirs could recover access. Maintaining routine operations does not test what happens when routines are disrupted. The system can function perfectly for years while holes wait, invisible, for the specific circumstances that will activate them. This creates a false confidence: the system has always worked, so it will continue to work. But the scenarios that expose holes—device failure, holder death, theft attempt, legal action—have not occurred. The absence of failure is not evidence of hole-free design; it is evidence only that hole-activating circumstances have not yet appeared.

Holes also persist because finding them requires active searching rather than passive observation. The holder must deliberately look for weaknesses, imagine scenarios where the system fails, and question assumptions that feel solid. This searching is psychologically uncomfortable—it means contemplating bad outcomes, acknowledging limitations, and potentially discovering that careful work contains flaws. The natural preference is for confirming that everything is fine rather than searching for problems. Holders who do not overcome this preference may avoid examining their systems critically, preferring the comfort of assumed security to the discomfort of discovered vulnerability.

Additionally, holes persist because they often exist in the relationships between components rather than in the components themselves. Each component may be secure individually while the connections between them contain weaknesses. The handoff from backup to recovery device, the coordination between cosigners, the transition from living holder to inheriting heir—these seams between components receive less attention than the components themselves. The holder thinks about whether the hardware wallet is secure, whether the backup is protected, whether the documentation is complete. Less attention goes to whether the recovery process from backup using documentation actually works, because that process exists as a sequence across components rather than as a thing that can be examined in isolation.

---

Common Hole Patterns

The single point of failure pattern creates holes where one compromised or lost component defeats the entire system. Despite the holder's intention to build redundancy, careful examination may reveal dependencies that concentrate risk: all backups in locations vulnerable to the same regional disaster, all passphrases memorized by the same person who could forget them or become incapacitated, all documentation in a single location that could be destroyed. The pattern is common because full redundancy requires effort, and partial redundancy feels adequate until the partially-protected component fails.

The untested assumption pattern creates holes where the holder believes something is true but has not verified it. The assumption that the backup is still readable, that the passphrase is correctly remembered, that the documentation is still accurate, that the cosigner is still willing and able to participate—each assumption may be correct, but unverified assumptions are holes until tested. The pattern is common because testing takes effort and may feel unnecessary when the assumption seems obviously true. But assumptions have a way of being false precisely when they matter most.

The outdated information pattern creates holes where the holder's understanding no longer matches reality. Changes have occurred—software updates, relationship changes, location changes, legal changes—that the holder either did not notice or noticed but did not propagate through documentation and procedures. The holder operates based on a mental model that was accurate at some past point but has drifted from current reality. The pattern is common because tracking all relevant changes requires ongoing attention that competes with other demands on the holder's time and attention.

The capability assumption pattern creates holes where the system requires capabilities that will not be present when needed. Recovery requires technical skills that heirs do not have. Emergency access requires travel that an elderly holder cannot undertake. Coordination requires relationships that have deteriorated. The system design assumed capabilities that the people who must use it do not possess. The pattern is common because holders design systems based on their own capabilities rather than the capabilities of others who may need to operate the system under different conditions.

---

Scenarios Revealing Holes

Years of confident operation preceded the hardware wallet failure. The backup existed, properly stored, and the holder knew exactly where to find it. What the holder did not know was that the wallet software used at the time of backup had a different derivation path default than current versions. Restoring from backup produced an empty wallet—the same seed phrase, but different addresses. Hours of research eventually explained the problem and provided a solution, but the hours were stressful and the solution was not obvious. The hole was technical, buried in implementation details that the holder had never examined closely because the system had always just worked.

The fire destroyed the home office where custody materials were concentrated. The safe deposit box at the bank held backup materials, as intended. But the safe deposit box key was in the home office, destroyed in the fire along with everything else. Accessing the safe deposit box required legal proceedings to prove identity and claim the contents—proceedings that took weeks while estate administration needed to proceed. The hole was not in the backup itself but in the access path to the backup: a key that was protected against safe deposit box fire was not protected against home fire, and the dependence between them created a gap.

Communication with the overseas cosigner had been reliable for years through a messaging app they both used. When recovery became necessary, the cosigner's account on that app had been suspended due to a dispute with the platform over account verification. Attempts to reach them through email bounced; they had changed providers without notifying anyone. Social media searches eventually located them, but weeks passed in the search. The hole was relational—the communication channel that worked routinely was more fragile than it appeared, and no backup communication method had been established.

---

The Ongoing Nature of Hole Detection

Finding holes is not a one-time activity but an ongoing process that must keep pace with changes in the custody system and its environment. A system that was hole-free at initial design develops holes as circumstances change. A hole that was found and addressed may reappear in a different form. New threats emerge that create new holes in previously secure configurations. The search for holes never concludes because the factors that create holes continue to operate. Holders who believe they have identified all the holes and can now relax have simply stopped searching while holes continue to accumulate.

Periodic systematic review helps maintain awareness of holes. Reviewing the system every year or every few years with deliberate attention to what might have changed, what assumptions should be re-tested, and what new threats have emerged surfaces holes that gradual drift would otherwise conceal. This review benefits from external perspective—another person examining the system may see holes the holder has become blind to through familiarity. The discomfort of finding holes is worthwhile because finding them before failure enables response, while finding them through failure is far more costly.

---

Assessment

Holes in bitcoin security exist as vulnerabilities in custody systems that persist undetected until specific circumstances reveal them. These holes take multiple forms—technical weaknesses in system construction, operational weaknesses in system use, and environmental weaknesses in surrounding context. Holes develop through initial design limitations, drift over time, and neglected maintenance. They persist because normal operation does not test for them, because finding them requires uncomfortable active searching, and because they often exist in the relationships between components rather than in components themselves.

Common hole patterns include single points of failure, untested assumptions, outdated information, and capability assumptions that do not match who will actually need to use the system. Holes may exist undetected for years until the right circumstances expose them. Finding holes is an ongoing process rather than a one-time activity, requiring periodic systematic review that keeps pace with changes in the system and its environment. The existence of holes is not a failure of diligence but a feature of complex systems; what matters is conscious identification and decision-making rather than unaware exposure.

---

System Context

Bitcoin Custody Failure Modes

Bitcoin Custody Behavior Without Technical Knowledge

Bitcoin Dashboard Implies Safety but Isnt Reflecting Reality

← Return to CustodyStress