Dead Man’s Switch

Un modèle peut donner au propriétaire une branche immédiate et à d’autres clés une branche accessible après un délai. Cette condition peut aussi survenir lors d’une hospitalisation, d’une perte d’appareil ou d’un entretien négligé. L’accès technique n’établit donc ni la situation personnelle ni l’identité d’un héritier légitime. Définissez d’abord l’événement exact réellement observé par le système. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net envoie des courriels préparés après des confirmations manquées. Cette couche diffère de Bitcoin Script. Dans votre propre conception, évaluez séparément la disponibilité du compte, la remise au destinataire et la divulgation prématurée. Un message peut indiquer l’emplacement d’une sauvegarde sans prouver que les conditions de dépense sont remplies. Modifier le minuteur ne rappelle pas une seed déjà envoyée ; une fuite exige aussi de traiter le contrôle des fonds. [Dead Man’s Switch — Service mechanism]

BIP 65 et OP_CHECKLOCKTIMEVERIFY vérifient un seuil absolu de hauteur ou de temps. BIP 112 et OP_CHECKSEQUENCEVERIFY, avec BIP 68, peuvent imposer l’âge d’un UTXO précis. Les verrous temporels relatifs utilisent des unités de 512 secondes et median-time-past, pas l’horloge du téléphone ; BIP 113 décrit la médiane des horodatages des 11 blocs précédents. Un délai en blocs n’est pas une échéance calendaire exacte. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Si un UTXO confirmé en H possède une branche de récupération après 1000 blocs, celle-ci peut devenir utilisable au plus tôt en H+1000, sous réserve des autres conditions. Une connexion à l’application ou une réception sur une autre sortie ne remet pas son âge à zéro. Renouveler le délai relatif exige de dépenser cette sortie et d’en confirmer une nouvelle avec la politique prévue. Suivez chaque UTXO séparément : un renouvellement partiel peut laisser d’anciennes sorties proches du seuil. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

Dans un modèle où la branche principale reste toujours accessible, l’expiration du délai ne supprime pas son autorité. Elle ajoute une branche de récupération utilisable ; quelqu’un doit encore signer et diffuser la transaction. Si les deux branches sont valides, une transaction confirmée détermine la dépense du même UTXO, pas l’étiquette « propriétaire » ou « héritier » de l’application. Il faut donc prévoir un renouvellement tardif et des dépenses concurrentes. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

nLockTime seul retarde une transaction donnée ; il ne prouve pas qu’une clé autorisée ne peut pas signer un autre paiement. Un plan présigné doit préciser les entrées, sorties, pouvoirs de signature et moyens de payer les frais. Si une autre transaction confirmée dépense son entrée, la présignature initiale devient inutilisable. Modifier le document ne suffit donc pas : vérifiez les UTXO réels et la disponibilité des nouveaux éléments auprès des destinataires. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Ces mécanismes impliquent une marge avant la prochaine échéance, des alertes fonctionnelles et des fonds pour les frais. Des renouvellements plus fréquents coûtent des frais ; une attente plus longue prolonge l’indisponibilité de la récupération. La personne qui récupère les fonds a besoin des bonnes clés, d’une description de la politique telle qu’un descriptor et d’un outil utilisable. Une sauvegarde verrouillée derrière le compte ou l’appareil du propriétaire indisponible crée une dépendance circulaire. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana propose un guide Signet. Un environnement de test séparé permet de vérifier une tentative prématurée, la maturité de la branche de récupération et le renouvellement d’une sortie précise. Ajoutez des alertes non remises, la perte de la clé principale et la restauration à partir des éléments sauvegardés. Vérifiez ce que les anciennes clés et les anciens UTXO autorisent encore après un changement de destinataire. Distinguez signature, admission en mempool et confirmation : un scénario réussi ne prouve pas l’absence de défauts du plan entier. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]