152 / 691INHERIT

Bitcoin Inheritance Plan

Passing on bitcoin: discovery, authority, keys and workable recovery

Bitcoin Inheritance Plan connects people, documentation and spending conditions so successors can actually recover funds without creating unintended early access.

Bitcoin Inheritance Plan specifies how authorized successors discover funds, obtain the necessary material and carry out recovery after the owner dies or becomes unable to act. It is more than a file containing a seed: legal authority, wallet knowledge and the technical ability to sign a payment are distinct parts of the same task.

Even an excellent backup cannot help someone unaware of the wallet. The plan needs a discoverable starting point: which wallets exist, who coordinates recovery and where the route to the material begins. This index need not contain secret keys. A legal document addresses authorized people but cannot create a missing signature. Conversely, holding keys is not technical proof of legal entitlement. The design must also account for the original administrator being unavailable and a successor unfamiliar with their habits. [Bitcoin Design — Inheritance wallet backup]

Seed Phrase restores keys; it may not describe Multisig, timed branches or every account. Output Descriptor describes scripts, keys and derivation information. A public descriptor without private keys permits monitoring, not signing, but exposes financial privacy; the general format can also contain private keys, so the export’s contents matter. A wallet using a BIP39 passphrase additionally needs that exact passphrase. Neither the device PIN nor another valid but empty wallet substitutes for missing information. [Bitcoin Core — Output Descriptors] [Trezor — What is a passphrase?]

In 2-of-3 Multisig, any two authorized signers can satisfy the threshold. If two successors receive their keys today with no further restriction, they can sign today. If the owner holds two keys and a helper holds the third, the helper cannot recover alone when both owner keys disappear. Assess the combinations actually available after each failure, not just the number of backups. A copy of the same key does not add another independent signature; the configuration must remain recoverable too. [Bitcoin Design — Inheritance wallet backup] [Bitcoin Core — Output Descriptors]

CHECKSEQUENCEVERIFY under BIP 112, together with BIP 68, can restrict a script branch by the age of the output being spent. The simplified policy “A now, or B after 1000 blocks” delays B’s signature, not A’s. It does not verify death, legal capacity or a rightful heir. Once the delay matures, B’s branch becomes usable even while A is alive. This is a relative block count from confirmation of the particular UTXO, not a fixed calendar date; actual mining time varies. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

In that model, a UTXO confirmed in block H has an earliest delayed-branch spending height of H+1000, provided the other conditions hold. A new incoming payment or opening the app does not reset its age. Renewing the delay requires spending that UTXO into a new output with the appropriate policy and waiting for confirmation. Liana uses recovery branches and a refresh sweep; the plan must track all relevant outputs, fees and availability of the ordinary signing path, not merely the wallet’s latest activity. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [Liana — Inheritance guide]

Instructions, signing secrets and any decryption password can be distributed across different access routes, but the sequence must remain workable. A password stored only in an account whose recovery depends on the deceased person’s phone can create a circular dependency. Successors need responsible contacts and an alternative procedure for unavailable storage or helpers. More copies improve availability while adding possible leak locations; public configuration data presents a different risk from keys permitting immediate spending. [Bitcoin Design — Inheritance wallet backup]

Readable instructions are not a tested recovery procedure. Using a separate test wallet, the intended successor must locate material without relying on the owner’s memory, reconstruct expected addresses, identify the correct branch and create a verifiable test transaction. A timed branch should be tested for rejection before maturity and use afterwards, for example in regtest. Displaying a balance proves less than the ability to sign. Such a rehearsal does not involve exposing real seeds or moving the actual inheritance. [Bitcoin Design — Inheritance wallet backup] [BIP 112 — CHECKSEQUENCEVERIFY]

A change of heir, lost key or new signing policy requires checking where funds are actually locked. Editing a name in the instructions or creating a new descriptor does not itself change old UTXOs; changing on-chain conditions requires moving funds to the new policy. After checking the new backups, update contacts, instruction versions and receiving addresses. Old addresses may still receive payments and should not simply be forgotten. The plan is a maintained process, not an envelope sealed once. [Bitcoin Design — Making changes]

For the clearest picture, read this entry together with Dead Man’s Switch, Multisig, Timelock, Collaborative Custody, Seed Phrase, BIP39 passphrase. The reverse links also lead from Shamir Secret Sharing, Bitcoin Vault, Dead Man’s Switch, Collaborative Custody.

DOC · 001Bitcoin Design — Inheritance wallet backupDocumentationDOC · 002Bitcoin Core — Output DescriptorsDocumentationDOC · 003Trezor — What is a passphrase?DocumentationDOC · 004BIP 112 — CHECKSEQUENCEVERIFYSpecificationDOC · 005BIP 68 — Relative lock-timeSpecificationDOC · 006Liana — Inheritance guideDocumentationDOC · 007Bitcoin Design — Making changesDocumentation
Source-first · No investment advice