Bitcoin Inheritance Plan définit comment les successeurs habilités découvrent les fonds, obtiennent les éléments nécessaires et effectuent la récupération après le décès ou l’incapacité du propriétaire à agir. Il dépasse le fichier contenant un seed : habilitation juridique, connaissance du portefeuille et capacité technique à signer un paiement sont des parties distinctes de la même tâche.
Même une excellente sauvegarde n’aide pas une personne qui ignore le portefeuille. Le plan nécessite un point de départ accessible : quels portefeuilles existent, qui coordonne la récupération et où commence l’accès aux éléments. Cet index n’a pas à contenir les clés secrètes. Un document juridique désigne les personnes habilitées, mais ne produit pas une signature manquante. Inversement, posséder les clés ne prouve pas techniquement un droit légal. Il faut prévoir l’indisponibilité de l’ancien gestionnaire et un successeur qui ignore ses habitudes. [Bitcoin Design — Inheritance wallet backup]
Seed Phrase restaure les clés, sans nécessairement décrire Multisig, les branches temporisées ou tous les comptes. Output Descriptor décrit les scripts, clés et informations de dérivation. Un descriptor public sans clés privées permet de surveiller, pas de signer, mais révèle des informations financières. Le format général accepte aussi des clés privées : le contenu exporté compte. Un portefeuille avec BIP39 passphrase exige en plus cette passphrase exacte. Ni le PIN du dispositif ni un autre portefeuille valide mais vide ne remplacent les données manquantes. [Bitcoin Core — Output Descriptors] [Trezor — What is a passphrase?]
Dans Multisig 2-of-3, deux signataires habilités quelconques satisfont le seuil. Si deux successeurs reçoivent leurs clés aujourd’hui sans autre restriction, ils peuvent signer aujourd’hui. Si le propriétaire possède deux clés et un assistant la troisième, l’assistant ne peut récupérer seul lorsque les deux clés du propriétaire disparaissent. Évaluez les combinaisons réellement disponibles après chaque défaillance, pas seulement le nombre de sauvegardes. Copier une même clé n’ajoute pas une signature indépendante ; la configuration doit elle aussi rester récupérable. [Bitcoin Design — Inheritance wallet backup] [Bitcoin Core — Output Descriptors]
CHECKSEQUENCEVERIFY, selon BIP 112 et avec BIP 68, peut conditionner une branche du script à l’âge de la sortie dépensée. La politique simplifiée « A maintenant, ou B après 1000 blocs » retarde la signature de B, pas celle de A. Elle ne vérifie ni décès, ni capacité juridique, ni héritier légitime. À l’échéance, B peut utiliser sa branche même si A est vivant. Il s’agit d’un nombre relatif de blocs depuis la confirmation de cet UTXO, pas d’une date calendaire fixe ; la durée réelle du minage varie. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]
Dans ce modèle, un UTXO confirmé au bloc H peut être dépensé par la branche différée au plus tôt à H+1000, si les autres conditions sont satisfaites. Un nouveau paiement entrant ou l’ouverture de l’application ne remet pas son âge à zéro. Renouveler le délai exige de dépenser cet UTXO vers une nouvelle sortie dotée de la bonne politique, puis d’attendre sa confirmation. Liana utilise des branches de récupération et un refresh sweep. Le plan doit suivre toutes les sorties concernées, les frais et la disponibilité de la signature normale, pas seulement la dernière activité du portefeuille. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [Liana — Inheritance guide]
Instructions, secrets de signature et éventuel mot de passe de déchiffrement peuvent être répartis entre plusieurs voies d’accès, mais leur enchaînement doit rester réalisable. Un mot de passe uniquement stocké dans un compte dont la récupération dépend du téléphone du défunt peut créer une dépendance circulaire. Les successeurs ont besoin de contacts responsables et d’une procédure alternative en cas de stockage ou d’assistant indisponible. Plus de copies améliore la disponibilité tout en multipliant les lieux de fuite possibles ; les données publiques de configuration présentent un risque différent des clés autorisant une dépense immédiate. [Bitcoin Design — Inheritance wallet backup]
Un mode d’emploi lisible n’est pas une procédure de récupération testée. Sur un portefeuille de test distinct, le successeur prévu doit retrouver les éléments sans la mémoire du propriétaire, reconstruire les adresses attendues, identifier la bonne branche et créer une transaction de test vérifiable. Pour une branche temporisée, il faut tester le rejet avant l’échéance et l’utilisation après, par exemple en regtest. Afficher un solde prouve moins que pouvoir signer. L’essai ne doit ni exposer de vrais seeds ni déplacer l’héritage réel. [Bitcoin Design — Inheritance wallet backup] [BIP 112 — CHECKSEQUENCEVERIFY]
Un changement d’héritier, une clé perdue ou une nouvelle politique de signature exigent de vérifier où les fonds sont réellement verrouillés. Modifier un nom dans les instructions ou créer un descriptor ne change pas en soi les anciens UTXO. Modifier les conditions on-chain exige de déplacer les fonds vers la nouvelle politique. Après vérification des nouvelles sauvegardes, il faut actualiser contacts, versions des instructions et adresses de réception. Les anciennes adresses peuvent encore recevoir des paiements et ne doivent pas être simplement oubliées. Le plan est un processus entretenu, pas une enveloppe scellée une fois. [Bitcoin Design — Making changes]
Pour une vision complète, lisez aussi Dead Man’s Switch, Multisig, Timelock, Collaborative Custody, Seed Phrase, BIP39 passphrase. Cette entrée est également citée par Shamir Secret Sharing, Bitcoin Vault, Dead Man’s Switch, Collaborative Custody.