Bitcoin Inheritance Plan

A wallet is an application or device for receiving and sending bitcoin. Private keys are secret numbers that let you authorize spending bitcoin. Anna carefully stores a backup but tells nobody it exists. For her family, the result may be much like having no backup at all. A useful starting point is discoverable information about the wallets and a contact who can help with the next steps. This signpost need not contain secret keys. It should explain where to begin finding the required material even when Anna cannot fill in the gaps. A legal document may establish who should receive the property; it cannot supply the digital signature that authorizes a payment. Equally, being able to sign does not establish legal entitlement. The legal arrangements must fit the relevant jurisdiction and circumstances. [1] [8]

A Seed Phrase is a backup written as words, from which secret material for keys can be recovered. If Anna uses a BIP39 passphrase, an additional secret text, that must also remain available. A PIN usually unlocks the device; it cannot replace a missing passphrase. Recovery with another passphrase may open a valid but empty wallet. More complex setups also need the wallet configuration: which keys, accounts and conditions it uses. An Output Descriptor records that description for software, including information for deriving addresses. It matters especially for Multisig, where several signatures are required. A public descriptor without private keys allows monitoring, not spending. It still exposes addresses and history, and the general format can also contain private keys. What matters is the actual export. [2] [3]

Anna may separate the instructions, backup and password for an encrypted file. But protection is useless if her daughter must first unlock Anna’s phone to get into an account containing the instructions for unlocking that phone. Follow the path as someone unfamiliar with your habits. They need contacts and an alternative if a helper or storage location is unavailable. More copies reduce the risk of loss but create more places from which information can leak. A copy of public configuration and a secret that permits immediate payment therefore call for different treatment. [1]

Rather than asking “do you understand?”, try a separate test wallet together. Following the instructions, the intended successor finds the material, restores the expected addresses and creates a verifiable test transaction without relying on Anna’s memory. Seeing a balance is not enough: a watch-only wallet can show funds without being able to sign a payment. If the plan includes a time condition, test rejection before the delay and use after it. A block groups transactions into a batch added to the shared history. Regtest, a private test network with controlled block generation, can help. The exercise tests the process; it does not involve publishing the real backup or moving the actual inheritance. [1] [4] [9]

Multisig 2-of-3 means that signatures from any two of three specified keys can authorize a payment. If two successors receive their keys today and no further condition applies, they can sign today. The threshold cannot tell that the payment was meant to wait for inheritance. The reverse problem arises if Anna holds two keys and a helper the third: losing both Anna’s keys leaves the helper unable to sign alone. Work through the combinations that remain available when a person or device is lost. Two copies of one key do not provide two independent signatures. The wallet configuration must remain available alongside the keys. [1] [2]

A timelock delays a particular way of spending. With a rule of “Anna now, or Boris after 1000 blocks”, Boris’s branch waits; Anna’s does not. A branch here means one permitted route to a payment. CHECKSEQUENCEVERIFY, described in BIP 112, together with BIP 68 can base the condition on the age of a UTXO: an unspent transaction output, an individual amount with its own conditions. The network does not verify death or identify the rightful heir. Once the delay expires, Boris may use his branch even while Anna is alive, provided the other conditions are met. This example counts blocks, not calendar days; their actual production time varies. [4] [5]

If the UTXO in the previous example confirms in block H, the delayed branch can permit spending no earlier than block H+1000, provided the other conditions are met. Receiving another payment or opening the app does not reset the old output’s age. A new delay for that value begins only after it is spent into a new output with the appropriate rule and that transaction confirms. Liana uses recovery branches and a refresh sweep, a transaction sending your own funds into a new set of outputs. All relevant outputs, fees and the availability of ordinary signing keys need attention. Saying “I used the wallet recently” does not establish which outputs were actually refreshed. [4] [5] [6] [10]

When a successor changes, a key is lost or the rules are revised, editing a name in the instructions is not enough. The conditions on existing UTXOs stay the same. A new descriptor describes a new setup but does not move money into it. Changing the conditions recorded on the network requires preparing the new wallet, checking its backups and transferring funds with a valid transaction. Instructions, contacts and receiving addresses then need updating. Old addresses may still receive payments, so their monitoring and necessary records cannot simply be discarded. The point is for the plan to work when needed, not just on the day it was written. [7]