Dead Man’s Switch

Anna wants a plan for her family: while she can, she manages her bitcoin herself; if she becomes unavailable for a long time, other options should exist. A wallet is an application or device for receiving and sending bitcoin. Signing here means using a private key, a secret numerical value, to create verifiable proof of authorization for a payment. Others can check the signature without knowing that secret. A transaction output records an amount and the conditions for spending it later. A Dead Man’s Switch evaluates a particular signal, such as a missed check-in or the age of an output. It cannot tell why the owner has stopped checking in. Hospitalization, a broken phone or forgotten maintenance can satisfy the same condition. Start by identifying what the system actually observes and what may follow. Even a correctly working mechanism cannot establish who is the rightful heir. It supports a plan rather than replacing every decision around it. [1] [5] [8] [9]

The service deadmansswitch.net illustrates the messaging approach: someone prepares emails, chooses recipients and periodically checks in. After missed confirmations, the service sends the messages. This differs from Bitcoin Script, the rules the network checks when funds are spent. An email can tell the family where to find records without supplying the signatures they need. Undelivered messages, lost accounts and premature disclosure all need consideration. A Seed Phrase, the words used to derive wallet keys, is not an ordinary note: if it leaks, changing a timer cannot revoke another person’s knowledge. Moving exposed funds under new keys must also be addressed. [7]

Another approach is built into the wallet’s spending conditions. Liana, for example, distinguishes a primary path available immediately from a recovery path that opens after a delay. In that model, Anna’s original authority does not expire when the wait ends. An additional option becomes available; someone still has to create, sign and broadcast a valid transaction. If both holders have usable paths, they may race to spend the same UTXO, a particular unspent transaction output. The confirmed spend in the chain decides, not an owner or heir label in the app. Missed maintenance can therefore give another person access while Anna is still alive. [1] [5]

Practical preparation starts well before the nearest deadline. Anna needs reliable reminders, spare time and funds for any transaction fees. More frequent renewal costs fees; a longer wait delays access through the recovery path. The family needs both the right keys and an understandable wallet description with suitable software. An Output Descriptor is a machine-readable description of keys and conditions used to locate and spend outputs; the configuration alone cannot replace required signatures. Recovery records must not be trapped in an account unlocked only by Anna’s unavailable phone. Such a backup exists, but cannot help when needed. [5] [6]

With a relative time restriction, each UTXO has its own waiting period. A block groups transactions into a batch added to the shared history. If an output confirmed in block H and another branch requires 1000 blocks, that branch can become usable no earlier than H+1000, subject to its other conditions. Logging in or receiving another payment does not reset its age. Anna must spend that specific output and have a new one confirmed with the intended conditions. Renewing only part of the wallet can leave old outputs close to their deadline. Opening the wallet today is therefore different from renewing the schedule for all the coins. [1] [2] [9] [10]

A Timelock restricts when a spending path can be used. BIP 65 and OP_CHECKLOCKTIMEVERIFY enforce an absolute boundary, such as a block height. BIP 112 and OP_CHECKSEQUENCEVERIFY, together with BIP 68, can require a particular UTXO to reach a given age. The time-based relative variant uses units of 512 seconds and median-time-past, a time derived from blocks. BIP 113 describes the median of the previous 11 block timestamps: the middle value after sorting. This is not the phone’s time or a promise of an exact calendar instant. These documents specify the rules; the everyday reader needs to know which clock their own plan uses. [1] [2] [3] [4]

Another plan may give the family an already signed transaction with a delay. Its nLockTime field limits when that transaction can confirm; it does not by itself forbid the key holder from signing another transaction. The presigned plan refers to particular UTXOs, intended destinations and a way to pay the fee. If another confirmed transaction spends an input first, the old presigned transaction becomes unusable. Editing a document therefore does not update the funds or the records the family holds. A changed plan requires checking actual outputs, signing permissions and whether recipients received a new usable set of information. [3]

Liana publishes instructions for Signet, a separate test network whose test coins have no real value. It can be used to try an early attempt, a recovery branch becoming available and renewal of a particular UTXO. For your own plan, also consider missed notifications, loss of the primary key and recovery from the records actually saved for a test wallet. After changing a recipient, check what old keys and old outputs still permit. A valid signature, acceptance into the mempool of unconfirmed transactions and confirmation in a block are separate steps. One successful demonstration does not show that a plan handles every failure. [6] [1]