Timechain Wiki

Operational security practices

18 min read

Operational security is the behavioural layer of self-custody — the practices that operate independently of which hardware wallet, multisig configuration, or backup scheme is in use. Technical security is a ceiling, not a foundation: a maximally-secure setup operated by an undisciplined holder is meaningfully less safe than a simpler setup operated with strong discipline. The most-emphasised opsec rule, from Lopp: "Don't talk about Bitcoin, at least not while using your real name or face." Victims of physical attacks are rarely random — they are identified through social media, public appearances, leaked KYC data, or socially-close-party disclosure. Other load-bearing practices: assume data breaches will happen and compartmentalize identity from holdings; never enter seed phrases into any software interface; verify transaction destinations on the hardware wallet's screen; operate the wallet only in peak cognitive condition; design the setup so coercion cannot produce unilateral movement of the coins.

Why this note matters

Operational security is the discipline that catches the failure modes the technical setup cannot prevent. Phishing succeeds because of cognitive error; physical attacks succeed because the target was identifiable; novel-scheme losses succeed because the holder didn’t follow the discipline. The note matters because:

  • It establishes the behavioural layer as load-bearing. The synthesis is direct: technical security is a ceiling, not a foundation. The actual defences are procedural.
  • It surfaces Lopp’s single-most-emphasised rule (don’t talk about Bitcoin) and the structural reason it works.
  • It engages the cognitive-state rule as the discipline that defends against self-inflicted loss during stress.
  • It corrects the “more cryptography is more security” intuition that drives many holders to over-engineer technical setups while underweighting behavioural discipline.

The defensible position: a setup with strong technical configuration but weak operational discipline is structurally fragile. A setup with simpler technical configuration and strong operational discipline is often safer. The right answer is both — matched in their levels of rigor.

The threat landscape this addresses

The behavioural layer defends against:

  • Phishing and social engineering — the dominant attack vector (>80% of crypto-theft incidents)
  • The KYC-data-to-physical-attack pipeline — leaked exchange data feeds into burglary and wrench-attack targeting
  • Self-inflicted operational loss — the largest category for long-term holders (forgotten passphrases, novel schemes)
  • Cognitive-state failures — mistakes made under stress, time pressure, or impaired states
  • Inheritance failure — the holder’s eventual unavailability

These are not threats the cryptography addresses. They are threats the holder’s practice addresses, or doesn’t.

Don’t talk about Bitcoin

The single most-emphasised opsec practice across every practitioner the synthesis reviews. Lopp’s framing:

The most effective thing that a Bitcoiner can do to reduce their wrench-attack risk is very difficult: Don’t talk about Bitcoin, at least not while using your real name or face.

The structural argument

Victims of physical attacks are rarely random. The attacker base has limited bandwidth — they cannot mug everyone. They target identified holders. The targeting pipeline:

  • Social-media posts using real name + Bitcoin content
  • Public appearances at Bitcoin events with name and face
  • Leaked KYC data (Ledger 2020, Coinbase 2024, others)
  • Socially-close-party disclosure (“my friend has a lot of Bitcoin”)
  • Behavioural tells in physical settings (Bitcoin-branded apparel, conspicuous spending)

Removing yourself from the pipeline removes you from the realistic target set. Lopp’s Physical Bitcoin Attack database — showing a 169% year-over-year jump in 2025 — shows that attacks cluster around identifiable holders, not random victims.

Practical implications

  • No Bitcoin-branded apparel in public, no Bitcoin-related visible gear (hardware-wallet keychains, Bitcoin tattoos, Bitcoin laptop stickers)
  • No public Twitter/X threads with real name tying you to holdings
  • No screenshots of balances anywhere public, ever
  • No “just bought X BTC” posts — the cumulative pattern reveals holdings even if individual posts don’t
  • If you have significant holdings, keep your public and personal online identities separate — pseudonymous accounts for Bitcoin content, real-name accounts for everything else, never cross
  • Don’t tell friends and family about specific holding amounts; vague references are safer than precise ones
  • At Bitcoin conferences and meetups, consider whether your face being visible there matters for your threat model
  • Avoid being interviewed or quoted by name in Bitcoin-related contexts at the level of public-figure visibility

What this doesn’t mean

The rule is about identification, not about silence. The synthesis’s position:

  • It is appropriate to discuss Bitcoin philosophy, technology, and economics publicly — these contribute to the broader culture
  • It is appropriate to teach others, contribute to the community, and engage substantively
  • The constraint is: don’t connect your real-name identity to your specific holdings

Some practitioners (Lopp himself, Jameson is publicly identified) accept the higher attack risk in exchange for the public role. Most holders should not.

Assume data breaches will happen

The structural argument: holder-data leaks are not a possibility; they are a certainty over a 10-20 year holding horizon. KYC data from exchanges, hardware-wallet order histories, mailing lists, conference registrations — all have leaked or will leak. See KYC leakage for the full treatment of the activation mechanisms (court orders, breaches, regulatory data-sharing, dark-market sales) and the compartmentalised-KYC-identity discipline that limits how much of the holder’s stack any one leak resolves.

What has leaked (representative as of 2026)

  • Ledger 2020 — 270,000+ customers’ names, addresses, phone numbers
  • Coinbase 2024 — substantial breach affecting US customer base
  • Various exchange and service breaches — periodic, documented in incident reports
  • Conference attendee lists — Bitcoin conferences sometimes leak via accidental disclosure or insider compromise

The defensive posture

  • Use separate email addresses for crypto-related services. A Bitcoin-exchange registration with an email that contains your name is structurally weaker than one with a pseudonymous email.
  • Avoid tying your home address to hardware-wallet purchases where possible. Some holders ship to PO boxes, business addresses, or family members in different cities.
  • Avoid sharing your home address with any service that doesn’t legitimately need it. KYC requirements often demand it; non-KYC services do not.
  • Be aware that criminals use these databases to identify targets. The Ledger 2020 leak is actively used in the targeting pipeline per Lopp’s database.

When breach data affects you

If your data appears in a leak:

  • Treat the leaked information as permanently compromised — the data cannot be retracted
  • Update your threat model — the local-physical-attacker category becomes more salient
  • Consider whether the leaked address still corresponds to your current residence (moving doesn’t help retroactively but it bounds future risk)
  • For known-high-value leaks, consider additional security improvements (home security, vacation planning, public-profile reduction)

Phishing defences

Phishing is the highest-incidence attack vector. The procedural defences:

Never enter the seed phrase into any software interface

For any reason. Ever. The only legitimate places a seed phrase belongs:

  1. A hardware wallet during initial setup
  2. A hardware wallet during recovery
  3. On the durable backup media at setup time (paper, metal)

Every other context — a wallet app asking you to “import,” a website asking you to “verify,” a “support” representative asking you to “type it in” — is an attack. The pattern is universal.

Phishing emails contain links. The links go to spoofed sites. Bypassing the link by typing the URL directly catches the spoof.

For services you use regularly, bookmark the legitimate URL and use the bookmark.

Verify any unusual request through a separate channel

If your exchange “emails you” about urgent action, do not click the email. Open a fresh browser, navigate to the exchange directly, and check the account. If your hardware wallet vendor “calls you,” hang up and call back via the number on their official site.

The separate-channel verification breaks the attacker’s control of the communication.

Use a password manager that refuses to autofill on spoofed domains

This is a procedural defence that doesn’t depend on the holder’s vigilance. A password manager (1Password, Bitwarden, KeePassXC) will not autofill credentials if the domain doesn’t match the saved entry. A phishing site at “ledqer.com” looks like “ledger.com” to a tired human; the password manager refuses to autofill, and the holder gets a signal that something is wrong.

The defence works only if the holder relies on autofill rather than typing credentials manually. Discipline: when autofill doesn’t work, that is a signal, not a problem.

Verify on the hardware wallet’s screen

For every transaction, verify the destination address on the hardware wallet’s screen (not just in the coordinator software). The hardware wallet displays what is actually being signed; the coordinator could be displaying something else if the host computer is compromised.

This is the load-bearing defence against host-computer compromise and clipboard malware. Don’t skip it for convenience.

The cognitive-state rule

Operating a crypto wallet requires peak cognitive condition to avoid costly mistakes. Transactions involving on-chain assets should never be rushed, especially under emotional stress.

This is Lopp’s framing. The structural argument:

  • Wallet operations are irreversible
  • Mistakes (wrong address, wrong amount, wrong signing context) cannot be undone
  • Stress, fatigue, anger, fear, and urgency all degrade decision quality
  • The worst self-inflicted losses happen during cognitive impairment

Practical implications

  • Don’t sign transactions when tired, stressed, or upset — defer until you’re in a clear state
  • Don’t sign transactions when you’re being rushed — by anyone, for any reason; legitimate counterparties accept delay
  • Build delay into your setup deliberately — multisig setups, time-locked transactions, multi-party confirmation patterns force a pause
  • For substantial transactions, use a 24-hour cooling-off period — review the details after a sleep before broadcasting
  • Don’t operate the wallet under coercion — the cognitive state under threat is impaired by definition; designs that prevent unilateral action under duress are structurally stronger than designs that rely on the holder’s judgment under stress

Time-locked transactions and remote confirmers

Some configurations provide structural defences against the cognitive-state failure mode:

  • Time-locked transactions — a transaction that cannot be broadcast until a specified time. Useful for “I think I want to do this; I’ll know in 48 hours.”
  • Remote confirmer multisig — one of the multisig keys is held by a remote party (a partner, an attorney, a trusted family member) whose approval is required. Slow but resilient.
  • Multi-party signing requirements — two or more parties must explicitly agree before a transaction signs. Useful for joint accounts or family-multisig configurations.

These configurations trade convenience for cognitive-state defence. Appropriate for substantial holdings; over-engineered for routine spending.

Geographic distribution and the “two-item” rule

The synthesis-validated principle for any multisig or split-backup setup:

No single location contains enough material to spend your funds.

If two of three keys live in your home, an attacker (or a fire) at your home has everything. The math is structural: you need at least enough distinct locations that the threshold cannot be met from any single one.

Common distributions (see also Multisig setups)

  • 2-of-3 multisig: home safe + bank safe deposit box + trusted family member in a different city
  • 3-of-5 multisig: extend to additional locations (attorney’s office, second property, additional jurisdiction)
  • Single-sig + passphrase: seed at one location; passphrase backup at another
  • SLIP-39 split: each share at a distinct location

What “geographic” means

Distinct locations should be distinct in the sense that:

  • A fire at one location doesn’t affect another
  • A burglary at one location doesn’t reveal another
  • Access to one doesn’t reveal access to another

A home safe and a fire-resistant safe in the same home is one location. A bank box at one branch and a bank box at another branch of the same bank are arguably one institution but two physical locations — typically acceptable. A safe in a primary residence and a safe in a second property are two locations.

For Tier 3 holdings, jurisdictional distribution adds another dimension — having keys in different countries means a single jurisdiction’s regulatory action doesn’t compromise the entire setup.

Decoys and duress responses are speculative

The decoy-wallet pattern (a passphrase-protected hidden wallet, with the unpassphrased seed as a decoy) and duress-response patterns (special PINs that trigger a wipe; special phrases that signal duress to a partner) are widely discussed.

The synthesis’s read: their effectiveness depends on the attacker’s beliefs and psychology — which are unpredictable. Lopp cites cases where decoys failed to convince attackers and victims who complied immediately were tortured for hours on the assumption of hidden reserves.

When decoys are useful

  • As one layer among several — a decoy plus geographic distribution plus inability-to-move-unilaterally is structurally stronger than any one alone
  • For non-coercive discovery scenarios — a burglar who finds the seed alone in a search of the home is more likely to be convinced by a decoy than an attacker present and watching
  • For plausible deniability over time — the seed in the home safe, if discovered later, doesn’t reveal the full holdings

When decoys are not the primary defence

  • Against direct coercion — the attacker may not believe the decoy is everything, and sustained pressure can extract additional cooperation
  • Against sophisticated attackers — who know the decoy pattern and assume hidden wallets
  • For inheritance scenarios — the decoy adds complexity that heirs may misinterpret

The synthesis’s position: decoys are a partial measure; the structural defences (don’t be identifiable; can’t move unilaterally) are stronger.

The biggest threat is still yourself

Every source ranks user error as the most common cause of lost Bitcoin. Practical defences:

Write everything down, in physical form

In language a non-technical person (your future self after a decade, or your heir) can understand. Memorization is not documentation. The documentation should survive your eventual unavailability.

Test your recovery at least once before you need it

See Recovery rehearsal practice. The wipe-and-restore discipline at setup catches the broken backups before they matter.

Do not improvise security

Custody decisions made under stress, time pressure, or emotional duress are often wrong. Plan the setup deliberately; document it; rehearse it; only then trust it.

Do not invent novel schemes whose failure modes you have not analysed

“I write every fourth word backward and XOR with my birthday” is creative; it is also the largest self-inflicted-loss category in the synthesis. Use standards others have reviewed.

Do not operate your wallet under emotional duress or time pressure

The cognitive-state rule applied to routine operations. The cost of waiting is small; the cost of irreversible mistake is total.

Tradeoffs and considerations

Discipline scales with stake

The operational-security practices have a cost — in time, in social adjustment, in convenience. The cost is justified at scale; for Tier 0 it is mostly over-investment.

  • Tier 0: phishing awareness; not-photographing seeds. The rest is over-investment.
  • Tier 1: the above plus hardware-wallet discipline; basic compartmentalization of identity.
  • Tier 2: full opsec discipline; geographic distribution; don’t-talk-about-Bitcoin practice; cognitive-state awareness.
  • Tier 3: continuous operational practice; possibly professional security consultation; personal-security planning.

The discipline level should match the stake. Over-applying Tier 3 discipline at Tier 1 wastes effort; under-applying at Tier 3 is reckless.

The social-cost of “don’t talk about Bitcoin”

The discipline conflicts with the cultural orientation of much of the Bitcoin community, which has organized around public advocacy, evangelism, and “orange-pilling.” The synthesis acknowledges the tension:

  • Some practitioners (Lopp, Casa team, many Bitcoin educators) have public profiles by choice and accept the elevated attack risk
  • Most holders should not adopt that posture
  • The collective Bitcoin ecosystem needs public advocates; individual holders can support the cause without personally being identified at the public-figure level

The pragmatic position: contribute to the cause pseudonymously where possible; reserve personal-identification for contexts where it materially helps and where you’ve accepted the threat-model implications.

The “I have nothing to hide” fallacy

A common objection: “Why should I hide my Bitcoin holdings? I’m not doing anything wrong.”

The structural answer: hiding holdings is not about wrongdoing; it is about the targeting pipeline. Tax authorities, regulators, and legitimate institutions get appropriate disclosure through KYC. Criminals do not. The asymmetry is the point.

Procedural defences vs vigilance-based defences

The synthesis prefers procedural defences over vigilance-based ones where possible:

  • A password manager that refuses to autofill on spoofed domains beats “I’ll be careful”
  • A hardware wallet’s screen verification beats “I’ll check the address”
  • A multisig with remote confirmer beats “I won’t sign under duress”
  • A time-locked transaction beats “I’ll wait 24 hours”

The pattern: vigilance is unreliable over time and under stress; procedures are reliable. Design defences that don’t depend on the holder being sharp at the moment of attack.

Tiered application

Tier 0: Phishing awareness; never-photograph-seeds; hardware-wallet screen verification. The behavioural baseline.

Tier 1: Tier 0 plus separate email for Bitcoin services; not-Bitcoin-branded public profile; basic identity compartmentalization.

Tier 2: Tier 1 plus geographic distribution; don’t-talk-about-Bitcoin discipline; cognitive-state awareness; explicit threat-model review.

Tier 3: Tier 2 plus professional security consultation; possibly time-locked configurations; family-member-protection planning; jurisdictional considerations.

Common pitfalls

Treating cryptography as the defence. The cryptography is robust. The defences against actual incidents are behavioural.

The “I’d never fall for that” pattern. Phishing is sophisticated; humans are not as vigilant as they think. Procedural defences (password managers, hardware-wallet verification) are required.

Talking about Bitcoin under real name on social media. The dominant identification pathway for physical-attack targeting. Even casual disclosure compounds over time.

Underestimating data-leak persistence. The Ledger 2020 leak still drives targeting in 2026. Data does not retract; the consequences persist.

Operating the wallet under stress. “I’ll just send this quickly” is when irreversible mistakes happen. Wait until you’re clear-headed.

Treating decoys as the primary coercion defence. Decoys are partial. The structural defences (don’t be identifiable; can’t move unilaterally) are stronger.

Underweighting the inheritance dimension. Most operational security focuses on the holder’s lifetime; inheritance failure is comparable in scale. The opsec discipline should include inheritance planning explicitly.

The “I’m not a target” assumption. Targets are not just whales. Mid-six-figure holders are increasingly targeted as the attacker base expands. Threat model accordingly.

Believing that strong technical setup compensates for weak opsec. It doesn’t. A maximally-secure multisig operated by an undisciplined holder is meaningfully less safe than a simpler setup operated with strong discipline.

Not building delay into the system. The cognitive-state rule is hard to enforce through willpower alone. Build it into the configuration (time locks, multi-party signing, remote confirmers).

Tooling and resources

The synthesis document (canonical for the section):

  • Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices, LegacyCipher discussion, April 2026 — opsec treated as the behavioural-layer foundation.

Primary practitioner sources:

  • Lopp — 21 tips for securing your bitcoin; the don’t-talk-about-Bitcoin rule; ongoing essays. See Jameson Lopp.
  • Casa — case studies; the cognitive-state rule
  • Unchained — operational-security guides
  • Nunchuk — sovereignty-focused opsec; the political-philosophical foundation
  • Blockchain Commons — Smart Custody Book; opsec chapters

Supporting tools:

  • Password managers: 1Password, Bitwarden, KeePassXC — autofill discipline against phishing
  • Pseudonymous identity tooling: Tor, dedicated email aliases, separate-profile browsers
  • Privacy-focused operating systems: Tails (for high-stakes operations), Qubes
  • Personal security consultation: for Tier 3 holders, specialized firms exist

As of 2026-05-14: opsec discipline is the slow-changing element. The specific tools and threats evolve; the principles are stable.

Open questions for further development

  • The “don’t talk about Bitcoin” rule is widely endorsed but conflicts with the community’s cultural orientation. How does the framework reconcile individual operational security with collective advocacy?
  • The 2024-2025 physical-attack surge is documented. What additional opsec practices have emerged in response, and which are working?
  • AI-generated phishing is becoming more sophisticated. The “verify by separate channel” defence is still valid but the volume of attempts is rising. What additional procedural defences should the framework recommend?
  • Time-locked transactions and remote-confirmer multisig configurations are structurally stronger against coercion than decoys. What are the operational costs, and is wider adoption warranted?
  • The cognitive-state rule depends on the holder’s self-awareness. For holders experiencing early cognitive decline, the rule becomes harder to apply. Should the framework include cognitive-decline-aware planning?

The framing context:

Adjacent operational notes:

Backup, recovery, rehearsal:

Storage and key concepts:

Hardware wallets:

Custody configurations:

Inheritance:

The moral framework:

The principal practitioner:

The sub-MOC home:

Graph View

Backlinks