Bitcoin Vault est une construction de garde comportant des étapes de retrait distinctes. Le déclenchement ouvre une période où ses règles permettent de transférer les fonds vers une voie de récupération sûre. Ce n’est ni le nom d’un opcode unique activé ni une simple autre appellation du portefeuille matériel.
Dans un portefeuille ordinaire à signature unique, un voleur possédant la clé peut créer un paiement direct. Le vault vise à limiter cette sortie immédiate : la clé opérationnelle déclenche le processus, mais ne doit pas contourner seule l’attente et la récupération. Il faut donc savoir quelles combinaisons de clés peuvent payer directement et lesquelles doivent passer par un état intermédiaire. L’étiquette vault ou un virement retardé dans l’application ne prouve pas une contrainte imposée par la blockchain. [BIP 345 — OP_VAULT]
Le modèle distingue l’UTXO déposé, la sortie intermédiaire unvault confirmée et le paiement terminé. Si la branche normale d’une sortie intermédiaire confirmée au bloc H exige 144 blocs, elle devient utilisable au plus tôt à H+144, sous réserve des autres conditions. La branche de récupération doit permettre une intervention antérieure. Ce ne sont ni exactement 24 heures ni une annulation automatique : l’intervention efficace doit précéder la dépense finale confirmée. [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]
Certaines constructions utilisent les règles actuelles et des transactions présignées. Elles limitent les dépenses alternatives en exigeant la suppression sûre des clés de signature à usage unique, ou l’accord d’autres parties indépendantes. Le réseau ne prouve pas lui-même la suppression d’une clé. Une copie secrète conservée peut contourner le chemin prévu. Les transactions présignées font aussi partie de la récupération : un seed seul peut ne pas recréer les signatures d’une clé supprimée. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
La spécification Revault distingue stakeholders, managers et cosigning servers. Sa sortie deposit utilise des clés de stakeholders N-of-N ; la sortie unvault autorise leur voie ou celle des managers et cosigners après X blocs. Cancel renvoie la sortie vers la politique deposit, tandis qu’emergency va vers un Emergency Deep Vault. Un bypass signé par les stakeholders existe aussi. Ce modèle ne garantit donc pas de délai si toutes leurs clés sont compromises et ne décrit pas tous les vaults. [Revault — Transaction specification]
À la révision du 8 septembre 2026, BIP 345 est Closed et désigne BIP 443 comme Proposed-Replacement. Il associait initialement OP_VAULT et OP_VAULT_RECOVER à OP_CHECKTEMPLATEVERIFY. BIP 443 propose le plus général OP_CHECKCONTRACTVERIFY, ou OP_CCV, et reste Draft ; son mécanisme d’activation est indéterminé. BIP 119 est également Draft. Un numéro BIP, une implémentation de test ou un exemple de vault publié ne démontre pas à lui seul l’activation de ces règles sur Bitcoin mainnet. [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]
Un moniteur doit reconnaître un retrait inattendu, pas seulement voir une transaction. Réagir exige une transaction de secours valide, un réseau accessible et des frais suffisants. L’envoi au mempool n’est pas une confirmation ; congestion, pinning ou mauvaise stratégie de hausse des frais peuvent faire perdre la fenêtre. Revault décrit CPFP et, pour certains secours, ALL | ANYONECANPAY afin d’ajouter des entrées payant les frais. Ses tarifs historiques ne recommandent pas les frais actuels. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Rediriger vers un script de récupération n’aide que si le propriétaire légitime peut ensuite en satisfaire les conditions. Clés indisponibles, configuration manquante ou présignatures perdues peuvent remplacer un vol par un blocage définitif pour le propriétaire. Une branche de secours trop facile à déclencher peut aussi permettre du harcèlement par annulations répétées. Distinguez le droit de déclencher le transfert protecteur du droit de dépenser depuis sa destination, et vérifiez ces deux rôles. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
La vérification doit lister tous les chemins de retrait et de bypass, les hypothèses de consensus, les sauvegardes nécessaires et le temps de réaction. Une installation de test séparée doit couvrir retrait normal, tentative prématurée, unvault inattendu, panne du moniteur et indisponibilité des fonds pour frais. Les résultats doivent distinguer signature valide, acceptation au mempool et confirmation. Démontrer un scénario ne prouve pas toutes les branches sûres ; ces modèles n’invitent pas à déposer des fonds réels dans un script expérimental. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Pour une vision complète, lisez aussi Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Auto-garde. Cette entrée est également citée par Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Dead Man’s Switch.