138 / 736COV

Covenants

ビットコインの将来の支出を制限する仕組み

盗まれた鍵だけでは、貯蓄をすぐに引き出せないとしたらどうでしょう。Covenants は、ビットコインを次にどう使えるかを制限できるルールです。保管庫の例を通して、その可能性と、具体的な設計や実際に使える段階かどうかを確かめる大切さを説明します。

Covenant は、誰がビットコインを使えるかだけでなく、次の送金をどのように構成するかも定められる条件です。たとえば、資金をまず待機期間付きの出力に移すよう要求できます。この制限はアプリの設定にとどまらず、その出力の支出ルールに含まれます。Covenants はさまざまな構成や提案の総称であり、どのウォレットでも使える一つの機能ではありません。

アンナは Bitcoin で貯蓄しています。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。ウォレットに表示される残高は、過去のトランザクションから生まれ、まだ使われていない出力、UTXO の集まりです。各出力には金額と、それを使うための条件が記録されています。条件を表す短いプログラムが Bitcoin Script です。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。Multisig は複数の署名を、Timelock は待機条件を要求できます。Covenant はさらに、資金の移動先となる出力など、次のトランザクションの構成を制限できます。正しい鍵を盗んだ人も、このルールを満たさなければなりません。ただし、利用可能な支出経路をすべて確認する必要があります。別の分岐で制限を回避できるなら、その制限を保護として頼ることはできません。 [1] [5] [9] [11]

アンナが貯蓄を待機期間付きの保管庫に入れる場面を考えましょう。ここでいう保管庫は特殊な機器ではなく、支出ルールの組み合わせです。普段使う鍵で引き出しを開始できても、資金はまず待機用の出力に移ります。待機期間が終わって初めて、予定した受取人へ送れるようになります。盗んだ人が引き出しを始めた場合、アンナは待機中に、あらかじめ用意した救済経路を使って資金をより安全な条件の下へ移せます。ただし、引き出しに気づき、救済トランザクションを時間内にブロックで承認してもらう必要があります。ブロックは、共有する履歴に追加する取引のまとまりです。完了した支払いを取り消す仕組みでも、介入せず自動で資金を救う仕組みでもありません。できることは保管庫の設計によって異なります。 [6] [10]

引き出しを遅らせるというアプリの約束は、運営者の約束にすぎない場合があります。一方、Bitcoin のスクリプトに書かれたルールはノードが確認します。ノードとは、ネットワーク共通のルールに従ってトランザクションを検証するソフトウェアです。対応する covenant の構成では、制限に違反する送金を拒否しなければなりません。提案されている道具の一つが、BIP119 に記載された OP_CHECKTEMPLATEVERIFY、略して CTV です。BIP は Bitcoin に関する提案文書です。CTV は検証中のトランザクションから選んだデータのハッシュを、事前に保存した指紋と比較します。ハッシュは、データから計算できる短い照合用の指紋と考えられます。指定した受取人や金額が変われば指紋も変わり、テンプレートと異なる送金は検証に通りません。アプリの「保管庫」という名前だけでは、この強制力は得られません。 [2]

CTV は出力を含めたトランザクションの構成を、事前に用意したテンプレートに結び付けます。研究されているのはこの方法だけではありません。BIP443 の OP_CHECKCONTRACTVERIFY は、特定のデータへの検証可能なコミットメントを持つ出力を提案しています。ここでいうコミットメントとは、後から別の値に差し替えると検証で不一致が分かる仕組みです。データは共同資金の現在の配分など、契約の状態を表せます。定められたルールを満たせば、次の出力に更新後の状態を引き継ぐこともできます。したがって CTV とこの提案は同じものの別名ではありません。何を事前に決める必要があり、何を後から変えられ、全体の構成にどのような追加の道具が必要なのかを、それぞれ確認します。 [2] [7]

再帰的な構成では、次の出力にも再び一定の制限を持たせられます。契約の状態が段階的に変わる場合などに、複数のトランザクションを通じてルールが引き継がれます。単一のスクリプトの検証中に無限ループを実行するという意味ではありません。Russell O’Connor と Marta Piekarska は2017年の論文でこうした構成を説明しました。繰り返しが可能かどうかは個々の提案によります。 [3]

事前署名済みトランザクション、時間制限、鍵管理を組み合わせて、一部の制限を準備することもできます。ただし、鍵の確実な削除、全トランザクションの保存、追加の協力が必要になる場合があります。別の署名者が不適切な支払いを拒むことに依存する Multisig には、別の信頼前提があります。使い勝手が似ていても、強制力や復旧方法まで同じとは限りません。 [5] [6]

保管庫以外にも、UTXO の共有や、決済を時間的に分散させる支払いの準備が研究されています。継続的な協力を減らしたり、ブロック領域を有効に使ったりすることが目的になりえます。無制限のトランザクションや低手数料が保証されるわけではありません。参加者が単独で離脱する方法、他者が応答しない場合、混雑時の手数料の払い方も説明が必要です。 [2] [7]

2026年10月17日時点で、BIP119 と BIP443 は Draft、つまり検討中の提案です。以前の BIP345、OP_VAULT は Closed となっており、代替案として BIP443 を挙げています。この文書が閉じられたことは、保管庫の研究が終わったことを意味しません。また、BIP 番号が付いてもネットワークが変更を採用したとは限りません。テストネットやデモ用ウォレットでは、Bitcoin の本番ネットワークである mainnet のルールが変わっていなくても機能を実演できます。Covenant を使う保管庫サービスでは、実際にどのネットワークとルールで動くのかを確認してください。 [6] [8]

狭すぎるテンプレートや、金額、スクリプト、手数料処理の誤りは、予定した支出を不可能にすることがあります。命令が増えれば、実装が安全に検証すべき範囲も広がります。コンセンサスの変更は、正確な仕様と障害時の挙動に基づいて評価する必要があります。Covenant 自体が、他人に既存のあなたの UTXO の条件を後から変更する権利を与えるわけではありません。 [4] [8]

具体的な仕組みでは、誰が引き出しや救済を開始できるか、対処時間はどれだけか、誰かが常時チェーンを監視する必要があるかを確認してください。バックアップ、手数料、離脱手段、実際に動くネットワークも重要です。Covenants は資金に対する自分の管理能力を広げる可能性がありますが、製品説明にその単語があるだけでは証明になりません。 [3] [6]

理解を深めるには、この項目とあわせて次もお読みください Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, コンセンサスルール, UTXO, Multisig. 次の項目からも参照されています OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.

DOC · 001Bitcoin Optech — Covenants文書 DOC · 002BIP 119 — CHECKTEMPLATEVERIFY仕様 DOC · 003Enhancing Bitcoin Transactions with Covenants一次資料 DOC · 004Bitcoin Core — Script interpreter文書 DOC · 005Bitcoin Developer Reference — Contracts and scripts文書 DOC · 006BIP 345 — OP_VAULT仕様 DOC · 007BIP 443 — OP_CHECKCONTRACTVERIFY仕様 DOC · 008BIP 2 — BIP process仕様 DOC · 009Bitcoin Developer Guide — Wallets文書 DOC · 010Bitcoin Developer Guide — Block Chain文書 DOC · 011Bitcoin Developer Reference — Transactions文書
改訂日: 一次資料を優先 · 投資助言ではありません