Bitcoin Vault est un mode de garde dans lequel un retrait ordinaire passe par une phase d’attente. Pendant ce temps, les fonds peuvent être redirigés par une voie de secours prédéfinie. L’objectif est de laisser au propriétaire le temps de réagir au vol d’une clé. Les modèles diffèrent : le mot vault dans une application ne garantit pas cette protection.
Anna conserve une partie de son épargne en bitcoin. 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. Avec un portefeuille ordinaire contrôlé par une seule clé, un voleur qui l’obtient peut signer un paiement directement vers sa propre adresse. Bitcoin Vault cherche à changer ce scénario : la clé utilisée au quotidien ne fait que lancer un processus, laissant à Anna une occasion de sauver les fonds. Imaginez un coffre avec un délai d’ouverture et une sortie de secours. Cette image ne vaut que si les conditions de dépense du réseau imposent réellement les restrictions. Un compte à rebours dans une application ne suffit pas. Une Hardware Wallet, appareil protégeant les clés de signature, n’est pas non plus automatiquement un vault : elle répond à un autre besoin de sécurité. [1] [6]
Une sortie de transaction enregistre un montant et les conditions permettant de le dépenser ensuite. Bitcoin enregistre des sorties de transaction disponibles pour une dépense, appelées UTXO. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Dans un modèle simple, la transaction initiale dépense la sortie conservée et en crée une nouvelle assortie d’une condition d’attente. Cette étape s’appelle unvault. Le paiement final pourra suivre plus tard, tandis qu’une voie de secours autorise une intervention anticipée. Supposons la sortie intermédiaire confirmée au bloc H avec un délai de 144 blocs : la voie normale devient utilisable au plus tôt en H+144, si les autres conditions sont remplies. Ce ne sont pas exactement 24 heures, car les blocs n’arrivent pas à heure fixe. Il ne s’agit pas non plus d’annuler un paiement terminé : la transaction de secours doit être confirmée avant la dépense finale. [1] [5] [7]
Anna repère un retrait qu’elle n’a pas demandé. Il lui faut maintenant une surveillance du réseau opérationnelle, une transaction de secours valide et de quoi payer ses frais. Un Mempool rassemble les transactions non confirmées ; y être accepté ne suffit pas. La congestion ou le pinning, qui permet à un attaquant de compliquer le remplacement ou la confirmation d’une transaction, peuvent retarder la réaction. Revault prévoit CPFP : une transaction suivante ajoute des frais pour inciter les mineurs à confirmer les deux ensemble. Certains secours utilisent ALL | ANYONECANPAY, un mode de signature autorisant des entrées supplémentaires, c’est-à-dire des références à d’autres montants non dépensés servant à financer les frais. Ces outils propres à un modèle ne garantissent pas une confirmation à temps. Les anciens tarifs de la spécification ne constituent pas une recommandation actuelle. [1] [4]
Un transfert protecteur peut arrêter le voleur tout en laissant Anna face à un autre problème : le portefeuille de destination doit rester utilisable. Son adresse ne suffit pas. Anna a besoin des clés requises, de la description des conditions et des éventuelles transactions préparées à l’avance. Le droit de déclencher un transfert de protection diffère aussi du droit de dépenser depuis sa destination. Un système de surveillance peut recevoir le premier sans obtenir le second. Toutefois, une voie de secours trop facilement accessible peut permettre de bloquer sans cesse des retraits légitimes. Un bon modèle traite donc la récupération de l’accès et les abus du mécanisme lui-même, en plus du vol. [1] [4]
Certains vaults utilisent les règles actuelles et des transactions présignées. Les signatures nécessaires sont créées à la mise en place ; la sécurité peut ensuite dépendre de l’effacement de clés à usage unique ou de cosignataires indépendants refusant les autres voies. Le réseau ne peut pas vérifier que toutes les copies d’une clé ont réellement été effacées. Une copie cachée peut contourner la protection. La sauvegarde peut aussi exiger davantage qu’une Seed Phrase, les mots permettant de dériver les clés du portefeuille. Ces mots ne recréent pas nécessairement une signature manquante d’une clé à usage unique déjà supprimée. Transactions présignées et données associées peuvent donc être indispensables à la récupération. [1] [4]
Revault montre que savoir qui possède une clé n’est qu’un début. Les stakeholders détiennent les pouvoirs principaux ; les managers gèrent les retraits courants et les cosigning servers les cosignent. Le dépôt exige N-of-N, soit toutes les signatures des stakeholders désignés : c’est du Multisig, une autorisation commune utilisant plusieurs clés. La sortie intermédiaire peut être dépensée par la voie des stakeholders ou, après X blocs, par celle des managers et serveurs. Cancel la ramène aux conditions initiales du dépôt ; un transfert d’urgence va vers Emergency Deep Vault. Les stakeholders disposent aussi d’une voie directe, bypass. Qui obtient toutes leurs clés n’a pas à attendre. Cette organisation décrit une spécification, pas tous les vaults. [4]
Un BIP décrit une proposition ou une norme Bitcoin ; son numéro ne prouve pas son activation. À la vérification du 17 octobre 2026, BIP 345 est Closed et indique BIP 443 dans Proposed-Replacement. Il associait OP_VAULT et OP_VAULT_RECOVER à OP_CHECKTEMPLATEVERIFY, des instructions limitant les voies de retrait. BIP 443 propose OP_CHECKCONTRACTVERIFY, ou OP_CCV, plus général, et reste Draft ; son mécanisme d’activation n’est pas fixé. BIP 119, consacré à OP_CHECKTEMPLATEVERIFY, est également Draft. Ces textes participent au débat sur les Covenants, restrictions portant sur l’utilisation future d’une sortie. Du code publié ou une démonstration ne prouvent pas que le mainnet, le réseau principal de Bitcoin, impose la protection. [1] [2] [3]
Avant de confier son épargne à un vault, Anna doit comprendre le retrait normal, le secours et chaque voie bypass. Les essais se font dans un environnement de test séparé : retrait normal, tentative avant l’échéance, unvault inattendu, panne de surveillance et absence de fonds pour les frais. Il faut distinguer signature valide, acceptation dans le mempool et confirmation dans un bloc. Une démonstration réussie ne teste pas les autres branches. Pour débuter, retenez qu’un vault donne du temps pour réagir, mais ajoute des tâches que quelqu’un doit accomplir de façon fiable. Ce texte n’invite pas à placer de vrais fonds dans un script expérimental. [1] [4]
Pour une vision complète, lisez aussi Covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Auto-garde. Cette entrée est également citée par Dead Man’s Switch.