Un Bitcoin Inheritance Plan organise la transmission de bitcoins après le décès de leur propriétaire ou lorsqu’il ne peut plus agir. Imaginons Anna : elle connaît bien son portefeuille, mais sa famille ne l’a jamais utilisé. Le plan doit conduire ses proches de « Anna possédait des bitcoins » à un portefeuille utilisable en sécurité. Il rassemble donc consignes, sauvegardes, personnes responsables et cadre juridique. Avec la garde personnelle des clés, aucun administrateur ne peut simplement remplacer des clés manquantes. L’accès technique et le droit sur les biens restent distincts.
Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Les clés privées sont des nombres secrets permettant d’autoriser la dépense de bitcoins. Anna conserve soigneusement une sauvegarde sans dire à personne qu’elle existe. Pour sa famille, le résultat peut ressembler à une absence de sauvegarde. Le premier repère utile indique les portefeuilles et une personne à contacter pour la suite. Il n’a pas besoin de contenir les clés secrètes. Il doit expliquer où chercher les éléments nécessaires, même si Anna ne peut plus compléter les informations. Un document juridique peut déterminer qui doit recevoir les biens ; il ne fournit pas la signature numérique qui autorise un paiement. Réciproquement, pouvoir signer ne prouve pas un droit sur les biens. L’organisation juridique doit tenir compte du pays compétent et de la situation particulière. [1] [8]
Une Seed Phrase est une sauvegarde en mots permettant de reconstituer les données secrètes des clés. Si Anna utilise une passphrase BIP39, un texte secret supplémentaire, celle-ci doit également rester disponible. Le PIN déverrouille généralement l’appareil ; il ne remplace pas une passphrase perdue. Une autre passphrase peut ouvrir un portefeuille valide, mais vide. Les montages plus complexes exigent aussi la configuration : clés, comptes et conditions utilisés. Un Output Descriptor décrit ces éléments pour le logiciel, y compris les données de dérivation des adresses. Il est notamment important pour Multisig, qui demande plusieurs signatures. Un descriptor public sans clés privées permet de surveiller, pas de dépenser. Il révèle néanmoins les adresses et l’historique ; le format général peut aussi contenir des clés privées. Il faut donc examiner le contenu réel de l’export. [2] [3]
Anna peut séparer les instructions, la sauvegarde et le mot de passe d’un fichier chiffré. Mais cette protection ne sert à rien si sa fille doit d’abord déverrouiller le téléphone d’Anna pour accéder au compte contenant les instructions de déverrouillage de ce même téléphone. Parcourez le chemin comme quelqu’un qui ignore vos habitudes. Il faut des contacts et une solution de rechange si une personne ou un lieu de stockage devient inaccessible. Davantage de copies réduit le risque de perte, mais multiplie les endroits où une fuite peut se produire. Une copie de configuration publique et un secret autorisant un paiement immédiat demandent donc des précautions différentes. [1]
Au lieu de demander seulement « tu as compris ? », faites ensemble un essai avec un portefeuille de test distinct. En suivant les consignes, le successeur prévu retrouve les éléments, reconstitue les adresses attendues et produit une transaction de test vérifiable, sans puiser dans la mémoire d’Anna. Voir un solde ne suffit pas : un portefeuille d’observation peut afficher les fonds sans pouvoir signer un paiement. Si une condition de temps s’applique, testez le refus avant l’échéance et l’utilisation après. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Regtest, un réseau privé de test où l’on contrôle la production des blocs, permet cette vérification. On teste la procédure, sans publier la vraie sauvegarde ni déplacer le véritable héritage. [1] [4] [9]
Multisig 2-of-3 signifie que les signatures de deux clés quelconques parmi trois clés déterminées suffisent à autoriser un paiement. Si deux successeurs reçoivent leurs clés aujourd’hui et qu’aucune autre condition ne s’applique, ils peuvent signer aujourd’hui. Le seuil ne sait pas que le paiement devait attendre la succession. À l’inverse, si Anna possède deux clés et une personne aidante la troisième, la perte des deux clés d’Anna laisse cette personne incapable de signer seule. Il faut examiner les combinaisons encore disponibles lorsqu’une personne ou un appareil manque. Deux copies d’une même clé ne donnent pas deux signatures indépendantes. La configuration du portefeuille doit rester disponible avec les clés. [1] [2]
Un verrou temporel retarde une possibilité de dépense. Avec « Anna maintenant, ou Boris après 1000 blocs », c’est la branche de Boris qui attend, pas celle d’Anna. Une branche désigne ici un chemin autorisé vers un paiement. CHECKSEQUENCEVERIFY, décrit dans BIP 112, peut avec BIP 68 conditionner la dépense à l’âge d’un UTXO : une sortie de transaction non dépensée, soit un montant particulier assorti de ses propres conditions. Le réseau ne constate ni décès ni qualité d’héritier. Une fois le délai écoulé, Boris peut utiliser sa branche même du vivant d’Anna, si les autres conditions sont remplies. L’exemple compte des blocs, pas des jours calendaires ; leur rythme réel varie. [4] [5]
Si l’UTXO de l’exemple est confirmé dans le bloc H, la branche retardée peut permettre une dépense au plus tôt au bloc H+1000, sous réserve des autres conditions. Une nouvelle réception ou l’ouverture de l’application ne remet pas l’âge de l’ancienne sortie à zéro. Un nouveau délai pour cette valeur exige de la dépenser vers une nouvelle sortie soumise à la règle voulue, puis de faire confirmer la transaction. Liana propose des branches de récupération et un refresh sweep, un transfert de ses propres fonds vers de nouvelles sorties. Il faut vérifier toutes les sorties concernées, les frais et la disponibilité des clés de signature habituelles. « J’ai utilisé le portefeuille récemment » ne dit pas quelles sorties ont réellement été renouvelées. [4] [5] [6] [10]
Un changement de successeur, une clé perdue ou de nouvelles règles ne se règlent pas en modifiant un nom dans les consignes. Les conditions des UTXO existants restent identiques. Un nouveau descriptor décrit un autre montage, sans y transférer les fonds. Pour changer les conditions inscrites sur le réseau, il faut préparer le nouveau portefeuille, vérifier ses sauvegardes et y transférer les fonds par une transaction valide. Consignes, contacts et adresses de réception doivent ensuite être actualisés. Les anciennes adresses peuvent toujours recevoir des paiements ; leur surveillance et les informations nécessaires ne doivent pas être abandonnées sans réflexion. Le plan doit fonctionner au moment utile, pas seulement le jour de sa rédaction. [7]
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.