Collaborative Custody désigne une organisation dans laquelle un propriétaire et une autre personne ou un service participent à la protection des bitcoins. Dans un modèle courant, le propriétaire garde assez de clés pour payer seul et le service l’aide en cas de difficulté. Cette autonomie doit découler des règles du portefeuille, pas simplement du nom du produit.
Pierre gère ses bitcoins dans son propre portefeuille. Il craint toutefois de perdre un appareil ou une sauvegarde. 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. Unchained décrit un modèle 2-of-3 : deux des trois clés doivent signer. Pierre détient A et B, le service C. Les combinaisons possibles sont A+B, A+C et B+C ; C seule ne suffit pas. Exiger plusieurs signatures s’appelle Multisig. Pierre peut payer sans le service et demander de l’aide s’il perd une clé. Deux appareils restaurés avec la même Seed Phrase, la même sauvegarde sous forme de mots, ne sont pas indépendants : révéler leur secret commun compromet les deux. [1] [4] [8]
Tant que Pierre dispose de A+B utilisables et du dossier complet du portefeuille, une panne du service ne l’empêche pas à elle seule de payer. S’il ne reste que A, il a besoin du service pour A+C. Une panne ou un refus de signer peut alors bloquer la récupération. S’il perd A et B, C seule ne le sauvera pas. Il faut donc tester séparément le départ autonome et la récupération assistée. Les instructions de Casa pour récupérer sans son infrastructure supposent elles aussi explicitement que sa clé est indisponible. La procédure et le matériel dépendent du produit ; le mot « collaborative » ne les définit pas. [1] [6]
Pierre a ses sauvegardes, mais une autre application doit savoir quel portefeuille reconstruire. Pour un 2-of-3 classique, il faut les clés publiques des trois participants, service compris, ainsi que leurs règles d’utilisation. Les clés publiques vérifient les signatures ; les privées les créent. Un Output Descriptor décrit cette configuration dans un format lisible par un logiciel, notamment la dérivation des adresses. Deux sauvegardes personnelles Seed Phrase ne recréent pas la clé publique manquante du fournisseur. Pierre enregistre et vérifie l’export tant que le service fonctionne. Avant de le partager, il en examine le contenu : le format général des descriptors peut aussi contenir des clés privées. [4] [5]
Un coordinateur rassemble les données de transaction ; le signataire détient la clé qui l’autorise. PSBT, le format décrit dans BIP 174, transporte une transaction inachevée et ses informations entre logiciels et appareils. Créer le fichier ne remplace pas une signature manquante. Même sans clé, un coordinateur peut nuire en proposant un autre destinataire. Avant de signer, il faut vérifier adresse, montant, frais et change : le reste renvoyé dans son propre portefeuille. Une Hardware Wallet sépare la clé de l’ordinateur ; encore faut-il savoir ce que son écran permet de vérifier et ce que Pierre approuve réellement. [2] [3]
Une erreur peut apparaître avant le premier paiement, lors de la création du portefeuille commun. BIP 129 décrit l’échange des clés et de la configuration pour comparer le seuil de signatures, les clés incluses et la première adresse. Cela comprend le type de script, qui exprime les conditions de dépense, et les chemins de dérivation des clés suivantes. Des réglages falsifiés peuvent détourner les dépôts. Le document ne couvre toutefois ni la résistance du stockage de l’appareil ni ses vérifications ultérieures des adresses de réception et de change. Prendre en charge ce standard ne certifie donc pas la sécurité du produit entier. [2]
Un XPUB est une clé publique étendue permettant de dériver les clés publiques d’une branche du portefeuille. Ces informations et la configuration peuvent permettre au fournisseur de suivre adresses et paiements sans avoir assez de signatures pour dépenser. Les associer à un compte au nom du client crée un lien supplémentaire. Confidentialité et pouvoir de dépense sont deux sujets distincts. Dire que le service ne peut pas payer seul suppose aussi certaines conditions : il pourrait obtenir une autre clé de Pierre ou le tromper pour obtenir une signature nuisible. Limiter les pouvoirs du fournisseur réduit certains risques, sans tous les supprimer. [2] [4]
Pierre perd une clé et en crée une nouvelle dans l’application. Cela n’invalide pas l’ancienne pour les dépôts passés. Une sortie de transaction enregistre un montant et les conditions permettant de le dépenser ensuite. Les dépôts passés existent sous forme d’UTXO, des sorties de transaction non dépensées avec leurs propres conditions. Avec un Multisig classique, il faut créer de nouvelles conditions et y transférer les fonds concernés par une transaction confirmée. Il reste ensuite à vérifier les anciennes adresses. Modifier le mot de passe du compte ou le nom d’une clé ne remplace pas ce transfert. La configuration et les consignes familiales doivent également évoluer, pour éviter que les héritiers suivent un plan devenu inexact. [4] [9]
Une répétition utile se fait sur un portefeuille de test distinct. Pierre importe la configuration sauvegardée dans un logiciel compatible, compare les adresses et vérifie qu’il peut signer avec ses propres clés sans le service initial. Le mode watch-only affiche adresses et solde, mais ne prouve pas qu’on peut signer. Caravan est un coordinateur à code ouvert ; il faut vérifier la prise en charge du format et des appareils concernés. Récupération assistée, clé indisponible, frais et change font aussi partie du test. Le résultat doit être une procédure compréhensible et documentée avec les versions utilisées, pas seulement le réconfort d’un solde affiché. [3] [6] [7]
Pour une vision complète, lisez aussi Multisig, Auto-garde, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. Cette entrée est également citée par Bitcoin Inheritance Plan, Institutional custody.