Dead Man’s Switch

Anna veut préparer un plan familial : tant qu’elle le peut, elle gère ses bitcoins ; si elle devient longtemps indisponible, d’autres possibilités doivent exister. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Signer signifie ici utiliser une clé privée, une valeur numérique secrète, pour créer une preuve vérifiable de l’autorisation du paiement. Les autres peuvent vérifier la signature sans connaître ce secret. Une sortie de transaction enregistre un montant et les conditions permettant de le dépenser ensuite. Un Dead Man’s Switch évalue un signal précis, comme une confirmation absente ou l’âge d’une sortie. Il ne peut pas savoir pourquoi le propriétaire ne répond plus. Hospitalisation, téléphone cassé ou entretien oublié peuvent remplir la même condition. Il faut donc définir ce que le système observe réellement et ce qui pourra suivre. Même un mécanisme parfaitement fonctionnel ne détermine pas l’héritier légitime. Il participe au plan, sans remplacer toutes les décisions qui l’entourent. [1] [5] [8] [9]

Le service deadmansswitch.net illustre l’approche par messages : on prépare des courriels, choisit les destinataires et confirme régulièrement sa présence. Après des confirmations manquées, le service envoie les messages. C’est différent de Bitcoin Script, les règles vérifiées par le réseau lors d’une dépense. Un courriel peut indiquer où chercher les documents sans fournir les signatures nécessaires. Il faut envisager les messages non reçus, les comptes perdus et la divulgation prématurée. Une Seed Phrase, les mots servant à dériver les clés du portefeuille, n’est pas une simple note : si elle fuit, changer un minuteur n’efface pas ce qu’autrui sait. Le transfert des fonds exposés sous de nouvelles clés doit aussi être traité. [7]

Une autre approche s’inscrit dans les conditions de dépense du portefeuille. Liana distingue par exemple une voie principale disponible immédiatement et une voie de récupération après un délai. Dans ce modèle, les droits initiaux d’Anna ne disparaissent pas à l’échéance. Une possibilité s’ajoute ; quelqu’un doit encore créer, signer et diffuser une transaction valide. Si les deux détenteurs ont un accès utilisable, ils peuvent se disputer le même UTXO, une sortie précise encore non dépensée. C’est la dépense confirmée dans la chaîne qui tranche, pas l’étiquette propriétaire ou héritier de l’application. Un entretien oublié peut donc donner accès à quelqu’un d’autre du vivant d’Anna. [1] [5]

La préparation commence bien avant l’échéance la plus proche. Anna a besoin de rappels fiables, d’une marge de temps et de fonds pour les frais éventuels. Renouveler plus souvent coûte des frais ; attendre davantage retarde l’accès par la récupération. La famille doit posséder les bonnes clés, une description compréhensible du portefeuille et un logiciel adapté. Un Output Descriptor décrit sous forme informatique les clés et conditions permettant de retrouver et dépenser les sorties ; cette configuration ne remplace pas les signatures exigées. Les documents ne doivent pas rester enfermés dans un compte déverrouillable uniquement avec le téléphone inaccessible d’Anna. Cette sauvegarde existe, mais ne sert pas au moment nécessaire. [5] [6]

Avec une contrainte temporelle relative, chaque UTXO possède sa propre attente. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Si une sortie est confirmée au bloc H et qu’une autre voie exige 1000 blocs, elle devient utilisable au plus tôt en H+1000, sous réserve des autres conditions. Se connecter ou recevoir un autre paiement ne remet pas son âge à zéro. Anna doit dépenser cette sortie précise et faire confirmer une nouvelle sortie avec les conditions voulues. Ne renouveler qu’une partie du portefeuille peut laisser d’anciennes sorties près de l’échéance. Ouvrir son portefeuille aujourd’hui ne signifie donc pas renouveler le calendrier de tous les fonds. [1] [2] [9] [10]

Un Timelock limite le moment où une voie de dépense peut être utilisée. BIP 65 et OP_CHECKLOCKTIMEVERIFY imposent une limite absolue, par exemple une hauteur de bloc. BIP 112 et OP_CHECKSEQUENCEVERIFY, associés à BIP 68, peuvent exiger un certain âge pour un UTXO. La variante relative temporelle utilise des unités de 512 secondes et median-time-past, un temps issu des blocs. BIP 113 décrit la médiane des horodatages des 11 blocs précédents : la valeur du milieu après classement. Ce n’est ni l’heure du téléphone ni la garantie d’un instant calendaire exact. Ces textes précisent les règles ; le lecteur doit surtout savoir quelle horloge utilise son propre plan. [1] [2] [3] [4]

Un autre plan peut remettre à la famille une transaction déjà signée avec un délai. Son champ nLockTime limite quand cette transaction peut être confirmée ; il n’interdit pas à lui seul au détenteur de la clé d’en signer une autre. Le plan présigné vise des UTXO précis, des destinations et un financement des frais. Si une autre transaction confirmée dépense d’abord une entrée, l’ancienne transaction présignée devient inutilisable. Modifier un document n’actualise donc ni les fonds ni les pièces détenues par la famille. Changer le plan exige de vérifier les sorties réelles, les droits de signature et la remise aux destinataires d’informations nouvelles et utilisables. [3]

Liana publie un guide pour Signet, un réseau de test séparé dont les unités n’ont pas de valeur réelle. On peut y essayer une tentative prématurée, l’ouverture de la voie de récupération et le renouvellement d’un UTXO. Pour son propre plan, il faut aussi envisager une notification non reçue, la perte de la clé principale et la récupération à partir des documents réellement sauvegardés d’un portefeuille de test. Après un changement de destinataire, vérifier ce que permettent encore les anciennes clés et sorties. Signature valide, acceptation dans le mempool des transactions en attente et confirmation dans un bloc sont des étapes distinctes. Une démonstration réussie ne prouve pas que le plan résiste à toutes les défaillances. [6] [1]