ビットコインの鍵削除コベナンツ(Deleted-key covenants)でできること

はじめに

現在、ビットコインにおいて送金先に制限のあるアドレスを作る仕様はありませんが、それを可能にする機能がコベナンツ¹と呼ばれています。コベナンツの実装方法は複数ありますが、今回はその中でも「n人のうち誰か一人でも信頼できる」(1-of-n existential honesty)という仮定の下で、ソフトフォーク不要で実装が可能なコベナンツである、「鍵削除コベナンツ」（deleted-key covenants²; 使い捨ての一時鍵³による鍵削除コベナンツ）を紹介します。

鍵削除コベナンツとは

n人がn-of-nマルチシグを作り、マルチシグとその他の条件cを満たすことでアンロックされるアドレスAを作ります。条件cは何でもよく、例えば鍵kによる署名とでもしておきます。
Aに入金するトランザクションIDを知った上で、許可したい出金トランザクションを全て作成し、n-of-nのマルチシグで部分的に署名しておきます。cを満たす鍵kによる署名は行わずに、トランザクションを保存しておきます。その後、Aに実際のトランザクションを入金します。

出金トランザクションへの部分的な署名が完了したら、n-of-nマルチシグの参加者n人全員が鍵を削除します。このとき、n人のうち1人でも正直に鍵を削除したならば、それ以降このアドレスAからの出金はできなくなり、保存したトランザクションのみ使用できるようになります。

トランザクションを実際にブロードキャストしたいときには、cを満たす鍵kによって保存した部分的に署名したトランザクションに署名すれば、有効なトランザクションになります。

1-of-n の形でトラストを要求する暗号プリミティブとしては、他にも zk-SNARKs Groth16プロトコルの鍵セットアップなどがあります。

鍵削除コベナンツの問題点

ここでは、コンセンサス上でコベナンツが有効化された場合と比較して、鍵削除コベナンツが劣っている点を挙げます。

1-of-nの信頼が必要

上記で説明したとおり信頼が必要です。コンセンサス上で有効化されたコベナンツでは第三者への信頼が不要です。

トランザクションを保存しておく必要がある

n-of-nで部分的に署名したトランザクションを紛失すると、鍵kを持っていても出金することができなくなります。今後使用する全てのトランザクションを保存しておく必要があります。

再帰コベナンツが実装できない

実装方法にもよりますが、コンセンサス上でコベナンツを実装すると、アドレスAの出金先をアドレスAに限定するようなトランザクションを作成できます。鍵削除コベナンツでは、これが有限階層までしか実装できなくなります。

追加での入金に対応できない

事前に全てのUTXOとトランザクションに署名しておく必要があるため、後からアドレスに入金があっても使用できません。また、手数料を変更することもできません。

鍵削除コベナンツの使いみち

Bitcoin Vault

ほとんど資金移動を行うことがないような保管業者などが、ビットコインを安全に管理する方法として Bitcoin vault⁴⁵を作ることができます。
この場合1-of-nの仮定を使わなくても、自分が管理するコインが必ずオンチェーンで指定されたフローを通るという点が重要なので、自分で鍵を作って自分で鍵を削除することになります。

BitVM Bridgeの構成要素

BitVM Bridge⁶はそもそも Groth16という1-of-nの信頼が必要なプロトコルに依存しており、また他の制約が存在してもBitVM Bridgeのプロトコルを実現する上で影響がないため、コベナンツを鍵削除コベナンツで代替するプロトコルを採用しています。コベナンツのソフトフォーク採用後には通常のコベナンツを使用することが期待されています。

その他コベナンツが実現したらできること

OP_CTVによるコベナンツなので若干違う部分もあるのですが、コベナンツでできることは大体⁷で網羅されています。

おまけ: 鍵回復コベナンツ (recovered-key covenants)とは何か

ECDSAにおいてメッセージと署名値がわかっていれば以下のように公開鍵が割り出せることが知られています。この性質を利用して、与えられたメッセージmに対してランダムな署名値(r,s)を生成して計算することで、「誰も秘密鍵を知らないような公開鍵P」が入手できます。

P = r^{-1} (s\cdot R - \text{Hash}(m)\cdot G)

この公開鍵Pに対して入金トランザクションdを発行すると、mに対応したトランザクションでのみ消費が可能になり、結果的にコベナンツ（鍵回復コベナンツ²）が実現できます。

この鍵回復コベナンツは現在のビットコインでは実現不可能です。
理由は以下のとおりです。

• 「入金トランザクションdを消費するためのトランザクション」に対応したメッセージmはdを消費することになりますが、dの中には宛先としてPの情報が含まれている必要があります。
• そのため、mはPに間接的に依存していることになってしまいます。これはmの作り方から言って不可能です（誰にも予測できないアドレスを生成する必要があるため）。

もしもSIGHASH_NOINPUT, SIGHASH_ANYPREVOUTのようなスキームがソフトフォークによって導入されて、メッセージmがdに依存しないようなトランザクション形式が可能になると、上記の方法が有効になります。

参考文献