Bitcoin Vault は、通常の出金に待機段階を設け、その間にあらかじめ決めた復旧経路へ資金を移せるようにする保管方式です。鍵の盗難に所有者が対応する時間を確保することを目指します。設計はさまざまで、アプリに vault と表示されているだけでは、この保護は保証されません。
アンナは貯蓄の一部をビットコインで持っています。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。ここでの署名は、秘密の数値である秘密鍵を使い、支払いを許可したことを検証できる証拠を作る操作です。他の人は、その秘密を知らなくても署名を確認できます。単一の鍵で管理する普通のウォレットでは、盗人がその鍵を得ると、自分のアドレスへの支払いにすぐ署名できます。Bitcoin Vault はこの場面を変えようとする仕組みです。普段の出金用の鍵は手続きを始めるだけで、アンナには資金を救う機会が残ります。待ち時間と緊急避難口のある金庫に似ています。ただし、この例えが成り立つのは、ネットワーク上の使用条件が実際に制限を強制する場合だけです。アプリのタイマーでは足りません。署名用の鍵を守る機器である Hardware Wallet も、自動的に vault になるわけではありません。守る対象が異なるからです。 [1] [6]
取引出力には、金額と、それを後で使うための条件が記録されています。Bitcoin は、使用できる取引出力を UTXO として記録します。ブロックは、共有する履歴に追加する取引のまとまりです。単純なモデルでは、最初の取引が保管中の出力を使い、待機条件のある新しい出力を作ります。この最初の段階を unvault と呼びます。最終的な支払いは後から可能になり、その前に復旧用の分岐で介入できます。中間出力がブロック H で承認され、待機が 144 ブロックなら、通常経路を使えるのは早くても H+144 で、ほかの条件も満たす必要があります。ブロックは時刻表どおりに生まれないため、厳密な 24 時間ではありません。完了済みの支払いを取り消すわけでもなく、救済取引は最終支出より先に承認されなければなりません。 [1] [5] [7]
アンナが身に覚えのない出金を見つけました。ここからは、稼働中のネットワーク監視、有効な救済取引、手数料を払う手段が必要です。Mempool は未承認の取引を置く場所で、受け入れられただけでは不十分です。混雑や pinning、つまり攻撃者が取引の置換や承認を難しくする行為で、対応が遅れることもあります。Revault は CPFP を想定しています。後続取引で手数料を上乗せし、マイナーに両方を一緒に承認する動機を与える仕組みです。一部の救済取引は、手数料に充てるほかの未使用の金額を指す入力を追加できる署名方式 ALL | ANYONECANPAY を使います。いずれも特定の設計の道具であり、期限内の承認を保証しません。仕様書の過去の手数料も、現在の推奨値ではありません。 [1] [4]
保護用の送金で盗人を止めても、アンナに別の問題が残る可能性があります。移動先のウォレットを後で本当に使えなければならないのです。アドレスを知っているだけでは足りず、必要な鍵、条件の説明、場合によっては事前に準備した取引が必要です。また、保護用の移動を開始できる権限と、移動先から使える権限は別です。監視役には前者だけを与えることもできます。ただし復旧経路を簡単に起動できすぎると、正常な出金を繰り返し妨害されるおそれがあります。よい設計は盗難だけでなく、アクセスの復旧と保護機能自体の悪用も考えます。 [1] [4]
現在のルールと事前署名済み取引を使う vault もあります。必要な署名を設定時に作り、その後の安全性を使い捨て鍵の削除や、別経路を拒否する独立した共同署名者に依存させる方法です。ネットワークには、鍵のコピーがすべて本当に削除されたかを確かめることはできません。隠したコピーが保護を迂回する可能性があります。バックアップも、ウォレットの鍵を導出する単語列である Seed Phrase だけでは足りない場合があります。削除済みの使い捨て鍵の署名が失われると、その単語から再作成できるとは限りません。事前署名済み取引と関連データも、復旧に不可欠になり得ます。 [1] [4]
Revault では、誰が鍵を持つかという問いだけでは不十分です。Stakeholders が主要な権限を持ち、managers が日常の出金を扱い、cosigning servers が共同署名します。預入出力には N-of-N、つまり指定した stakeholders 全員の署名が必要です。複数の鍵で共同承認する Multisig です。中間出力は stakeholders の経路、または X ブロック後に managers とサーバーの経路で使用できます。Cancel は元の預入条件へ戻し、緊急送金は Emergency Deep Vault へ送ります。Stakeholders には直接の bypass 経路もあります。全員の鍵を得た者は待たずに済みます。これは特定の仕様であり、すべての vault の説明ではありません。 [4]
BIP は Bitcoin の提案や標準を記す文書で、番号があっても有効化されたとは限りません。確認日である2026年10月17日時点で、BIP 345 は Closed で、Proposed-Replacement に BIP 443 を挙げています。元の提案は OP_VAULT、OP_VAULT_RECOVER と OP_CHECKTEMPLATEVERIFY を組み合わせ、出金経路を制限するものでした。BIP 443 はより汎用的な OP_CHECKCONTRACTVERIFY、略称 OP_CCV を提案し、まだ Draft です。有効化の仕組みは未定です。OP_CHECKTEMPLATEVERIFY の BIP 119 も Draft です。これらは出力の将来の使い方を制限する Covenants の議論に含まれます。公開コードや実演は、Bitcoin の本番ネットワークである mainnet が保護を強制している証拠ではありません。 [1] [2] [3]
アンナが貯蓄を預ける前には、通常の出金、救済、すべての bypass 経路を理解する必要があります。実演は独立したテスト環境で行います。正常な出金、期限前の試行、予期しない unvault、監視停止、手数料資金の不足を確かめます。有効な署名、mempool への受け入れ、ブロック承認は別々です。一つの成功例でほかの分岐まで検証したことにはなりません。初心者にとって大切なのは、vault が対応時間を増やす一方、誰かが確実に果たすべき仕事も増やすことです。この記事は実験的なスクリプトへ実際の資金を入れる手順ではありません。 [1] [4]
理解を深めるには、この項目とあわせて次もお読みください Covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, セルフカストディ. 次の項目からも参照されています Dead Man’s Switch.