Bitcoin Inheritance with Shamir Backup: A Developer's Guide

Bitcoin inheritance using Shamir's Secret Sharing splits the cryptographic material needed to recover a wallet into threshold shares, where K of N shares are required to reconstruct the secret and fewer than K shares reveal zero information. This guide covers the two primary implementation approaches (SLIP-39 at the seed level and application-layer splitting), their threat models, and how to build a self-hosted inheritance system with automated dead man's switch triggers.

The Developer's Problem Statement

If you hold Bitcoin in self-custody, you control private keys derived from a BIP-39 mnemonic (the standard 12 or 24-word seed phrase). That mnemonic is the single point of failure for your entire Bitcoin holdings. Lose it, and the funds are gone. Expose it, and the funds are stolen.

For inheritance, you need a system that satisfies four constraints simultaneously:

1. Confidentiality during your lifetime. No single person (including any individual beneficiary) can access your Bitcoin while you are alive.
2. Availability after your death. A defined group of beneficiaries can access your Bitcoin after you die or become permanently incapacitated.
3. Fault tolerance. The system survives individual beneficiary loss (death, relocation, key loss) up to a defined threshold.
4. Automated trigger. The transition from "confidential" to "available" happens without requiring anyone to make a judgment call about whether you are dead.

Multisig addresses constraints 1-3 but not 4. A simple safe deposit box addresses none of them. Shamir's Secret Sharing, combined with a dead man's switch, addresses all four.

SLIP-39: The Seed-Level Standard

What SLIP-39 Is

SLIP-39 (Satoshi Labs Improvement Proposal 39) is a standard for creating Shamir backups of cryptocurrency seed phrases. Developed by the team behind Trezor, it defines a specific encoding for Shamir shares of a master secret, along with a checksum and word list for human-readable representation.

Unlike BIP-39, which encodes a seed as 12 or 24 words from a 2048-word list, SLIP-39 encodes each share as 20 or 33 words from a different 1024-word list. The shares are organized into groups, supporting two-level thresholds (e.g., require 2 of 3 groups, where each group requires 2 of 3 members).

How SLIP-39 Works Technically

1. A master secret (128 or 256 bits) is generated.
2. The master secret is split using Shamir's Secret Sharing over GF(256) (the Galois field of order 256).
3. Each share is encoded as a sequence of 10-bit words mapped to the SLIP-39 word list.
4. A 3-round Feistel cipher is applied to the master secret before derivation to ensure that the master secret cannot be used directly as a BIP-39 mnemonic (preventing confusion between standards).
5. HD wallet keys are derived from the master secret using SLIP-39's own derivation function, which differs from BIP-39's PBKDF2 derivation.

SLIP-39 Strengths

• Standardized. Hardware wallets (Trezor Model T, Trezor Safe 3) support SLIP-39 natively. Shares can be generated and verified on the device itself.
• Offline. Share generation and reconstruction happen entirely offline on the hardware wallet. No network interaction required.
• Human-readable. Shares are word sequences that can be written on paper, stamped into metal, or stored physically.
• Group support. Two-level threshold allows complex access structures (e.g., "any 2 of: [family group, lawyer group, backup group]").

SLIP-39 Limitations

• Static shares. Once generated, shares cannot be rotated without creating a new wallet and transferring funds. If you need to remove a share holder, you must move all Bitcoin to a new wallet with new shares.
• No automated trigger. SLIP-39 is a backup format, not a delivery mechanism. It has no concept of timing, conditions, or triggers. Someone must decide when to assemble the shares.
• Recovery requires compatible software or hardware. Not all wallets support SLIP-39 recovery. The beneficiary needs a Trezor or compatible software to reconstruct the seed.
• Seed-only scope. SLIP-39 protects the seed phrase. It cannot store additional documents, instructions, exchange credentials, or other inheritance data.
• No notification system. There is no way for SLIP-39 to notify share holders that reconstruction is needed.

Application-Layer Shamir: The BAP Approach

An alternative to seed-level splitting is application-layer Shamir, where the inheritance document (which contains the seed phrase among other data) is encrypted, and the encryption key is split using Shamir's Secret Sharing.

How It Works in BAP

Burning Ash Protocol implements this as follows:

1. Document encryption. The host uploads an inheritance document containing their seed phrase, wallet instructions, and any other relevant data. This document is encrypted with AES-256-GCM using a randomly generated 256-bit Data Encryption Key (DEK).

2. Key splitting. The DEK (not the seed phrase directly) is split into N shares using Shamir's Secret Sharing. Each survivor receives one share.

3. Dead man's switch. Configurable liveness checks (HCIT: check-in interval, HCRT: response time window, HCRAC: missed check count before trigger) monitor the host. Multi-channel notifications (email, SMS, WhatsApp, Telegram) ensure the host is reached.

4. Trigger and distribution. When the host fails enough consecutive checks, the Will Transfer Protocol initiates. Survivors are notified through their configured channels and authenticate via OTP to receive their individual key shares.

5. Reconstruction. K survivors combine their shares to reconstruct the DEK, decrypt the document, and access its contents.

Application-Layer Advantages Over SLIP-39

Application-Layer Limitations

• Server dependency. The system must be running when the trigger fires and when survivors retrieve their shares. Self-hosting mitigates third-party risk but introduces operational responsibility.
• Not standardized. Unlike SLIP-39, application-layer implementations are specific to each tool. Lock-in is a consideration.
• Additional attack surface. The server, database, and network stack are attack vectors that don't exist in a purely offline SLIP-39 setup.

Threat Model Analysis

A rigorous inheritance plan requires explicit threat modeling. Here are the primary threats and how each approach handles them.

Threat: Single Share Holder Compromise

An attacker gains access to one survivor's share.

• SLIP-39: The attacker has one share of K. With K > 1, this reveals zero information about the master secret (information-theoretic security). However, if the attacker is patient, they now need K-1 more shares rather than K.
• BAP: Same mathematical guarantee for the DEK. Additionally, share retrieval requires OTP authentication, so possessing the share data alone is insufficient without access to the survivor's authentication channel.

Verdict: Both secure at the cryptographic layer. BAP adds an authentication layer.

Threat: Server Compromise (BAP Only)

An attacker gains full access to the BAP server.

• Encrypted documents. Documents are encrypted with AES-256-GCM. Without the DEK, they are inaccessible.
• Encrypted DEK shares. Individual shares are encrypted and associated with survivor identities. The master key encrypts the DEK, and shares are derived from the DEK.
• Master key exposure. If the attacker also obtains the MASTER_KEY environment variable, they can decrypt the DEK and access all documents. This is the critical secret for a self-hosted deployment.

Mitigation:

• Self-host on infrastructure you control.
• Store MASTER_KEY in hardware security module (HSM) or secure enclave where available.
• Use full-disk encryption on the host machine.
• Network-isolate the server (no public internet exposure if possible; use VPN or Tailscale for check-in access).
• Monitor for unauthorized access with intrusion detection.

Threat: Host Coercion (Rubber-Hose Attack)

An attacker forces the host to disable the dead man's switch or surrender the documents.

• SLIP-39: If the host has a backup copy of the master secret (which they typically do), coercion yields the secret directly.
• BAP: The host can respond to check-ins under duress, preventing the trigger from firing. However, the host cannot unilaterally decrypt the will without survivor cooperation (the DEK is split). The host can cancel the will, which is a design decision that prioritizes host control.

Mitigation: This is a physical security problem, not a cryptographic one. Duress resistance is limited in any system where the host has administrative control.

Threat: Long-Term Unavailability of the System

The BAP server ceases to operate (hardware failure, hosting provider shutdown) before the trigger fires.

• SLIP-39: Not affected; shares are physical objects.
• BAP: If the server is gone, survivors cannot retrieve their shares through the system.

Mitigation:

• Self-host with automated backups (database + encrypted documents).
• Use SLIP-39 as a secondary offline backup.
• Document the recovery procedure: if the BAP server is unavailable, survivors can reconstruct from SLIP-39 physical shares.

Threat: Quantum Computing

A future quantum computer attempts to break the cryptographic protections.

• Shamir's Secret Sharing: Information-theoretically secure. Quantum computers provide no advantage against Shamir's scheme. K-1 shares contain zero information regardless of computational power.
• AES-256-GCM: Grover's algorithm reduces AES-256 effective security to 128 bits against quantum search, which is still considered secure.
• BIP-39/SLIP-39 seed derivation: Not directly affected, though ECDSA signatures on the blockchain are vulnerable to Shor's algorithm. This is a Bitcoin-wide concern, not specific to inheritance.

Verdict: Shamir-based inheritance is quantum-resistant at the secret sharing layer.

Self-Hosting for Maximum Security

For developers with the highest security requirements, self-hosting the inheritance system eliminates third-party trust entirely. Here is how to deploy BAP on your own infrastructure.

Infrastructure Requirements

• A server or VM that will remain operational for the duration of your plan (potentially decades). Consider a low-power device (Raspberry Pi, Intel NUC) on a UPS with automatic restart.
• A domain name for check-in access (optional; can use IP or VPN).
• Docker and Docker Compose installed.
• Backup storage (external drive, second machine, or encrypted cloud backup).

Deployment

# Clone the repository
git clone https://github.com/baprotocol/bap.git
cd bap

# Generate secrets
make generate-key
# This creates JWT_SECRET and MASTER_KEY

# Configure environment
cp .env.example .env
# Edit .env:
#   DEPLOY_MODE=selfhosted
#   DB_TYPE=sqlite
#   MASTER_KEY=<generated key>
#   JWT_SECRET=<generated key>

# Build and start
make docker-up

The self-hosted deployment runs as a single-tenant system. There is no multi-user management, no billing, and no platform-managed connectors. You provide your own SMTP server for email notifications, your own Twilio credentials for SMS, or your own Telegram bot token for Telegram notifications.

Security Hardening

# 1. Restrict network access
# Use firewall rules to limit inbound connections
# Only port 8080 (API) and 3000 (web) need to be accessible

# 2. Enable full-disk encryption on the host
# For Linux: LUKS encryption at install time
# For Raspberry Pi: dm-crypt on the data partition

# 3. Automated encrypted backups
# Back up the SQLite database and uploaded documents
# Encrypt the backup with a separate key stored offline

Backup Strategy

The critical data to back up:

1. The SQLite database (./data/bap.db): Contains encrypted documents, survivor information, and configuration.
2. The MASTER_KEY: Without this, the database contents are useless. Store it separately from the database backup.
3. The .env file: Contains all configuration including notification credentials.

Back up the database automatically (cron job, systemd timer) to a separate physical location. Back up the MASTER_KEY to a different separate location. The principle: no single location contains both the encrypted data and the key to decrypt it.

Monitoring

For a self-hosted system that may need to operate for years or decades:

• Set up uptime monitoring (UptimeRobot, Healthchecks.io, or a self-hosted alternative) that pings your BAP instance and alerts you if it goes down.
• Monitor disk space. SQLite databases grow over time with check-in logs.
• Set up automatic OS security updates.
• Test the backup restoration process at least annually.

Hardware Wallet Integration

The recommended architecture combines hardware wallet security with application-layer Shamir:

Primary Layer: Hardware Wallet with SLIP-39

1. Initialize your hardware wallet (Trezor Model T or Safe 3) with SLIP-39 backup.
2. Generate a 3-of-5 Shamir backup. This produces 5 word sequences of 20 or 33 words each.
3. Record each share on durable media (stainless steel backup plates, not paper).
4. Distribute shares to 5 geographically distributed locations or people.
5. Store Bitcoin in wallets derived from this seed.

This layer provides the offline, standardized, physically resilient backup.

Secondary Layer: BAP with Dead Man's Switch

1. Deploy BAP (self-hosted or SaaS).
2. Create a will document containing:
   • Which hardware wallet model was used.
   • SLIP-39 share locations and holders (but not the shares themselves).
   • Step-by-step recovery instructions for someone with no crypto experience.
   • Any additional credentials (exchange accounts, DeFi positions).
3. Add survivors (matching or overlapping with SLIP-39 share holders).
4. Configure the dead man's switch with appropriate intervals.
5. The will document is encrypted with AES-256-GCM and the DEK is split via Shamir.

This layer provides the automated trigger, notifications, and supplementary documentation.

Recovery Scenarios

Scenario A: BAP triggers successfully. Survivors are notified, authenticate, reconstruct the DEK, decrypt the will document, follow its instructions to locate SLIP-39 shares and reconstruct the seed.

Scenario B: BAP server is unavailable. Survivors were previously informed (via the sealed envelope in the attorney's custody or the "break glass" instructions) that SLIP-39 shares exist. They locate the physical shares and reconstruct the seed directly using a compatible hardware wallet.

Scenario C: Some SLIP-39 shares are lost. If fewer than 5 but at least 3 shares are available, reconstruction still succeeds (3-of-5 threshold). The BAP document may help locate the remaining shares.

Scenario D: Some survivors are unreachable. If fewer than N but at least K survivors are available for the BAP threshold, they can still reconstruct the DEK. The BAP document then guides them to the SLIP-39 shares.

The two layers provide redundancy: either layer alone is sufficient to recover the Bitcoin, and both failing simultaneously requires multiple independent failures.

Implementation Checklist

For developers implementing this plan:

• Generate SLIP-39 shares on a hardware wallet (air-gapped, never connected to network during generation).
• Record each share on durable, fireproof media.
• Distribute shares to geographically separated holders or locations.
• Verify reconstruction by recovering the seed on a second hardware wallet (test with a small amount first).
• Deploy BAP (self-hosted: Docker; SaaS: baprotocol.com).
• Create the inheritance document with complete instructions.
• Add survivors and configure the Shamir threshold.
• Configure liveness check parameters (interval, response window, escalation count).
• Set up notification channels (at least two per survivor for redundancy).
• Create sealed "break glass" instructions for at least one trusted person.
• Set up automated backups of the BAP database.
• Store the MASTER_KEY in a separate, secure location.
• Test the full flow: check-in response, survivor notification, share retrieval.
• Schedule quarterly review of the plan (holdings, survivor info, share locations).

Summary

SLIP-39 and application-layer Shamir are complementary, not competing. SLIP-39 provides standardized, offline, physically resilient seed backups. Application-layer systems like BAP provide automated triggers, multi-channel notifications, document storage, and threshold-encrypted delivery. The most robust Bitcoin inheritance plan uses both: SLIP-39 for the cryptographic foundation and a self-hosted dead man's switch for the operational layer that turns "someone should probably check on this" into "the system has already handled it."