Collaborative Custody は、所有者と別の個人やサービスがビットコインの保護に関わる管理方式です。よくあるモデルでは、所有者が単独で送金できるだけの鍵を持ち、問題が起きたときにサービスが手助けします。ただし、その独立性は商品名ではなく、ウォレットの実際のルールで確かめる必要があります。
ピーターは自分のウォレットでビットコインを管理しています。ただ、端末やバックアップをなくすのが心配です。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。ここでの署名は、秘密の数値である秘密鍵を使い、支払いを許可したことを検証できる証拠を作る操作です。他の人は、その秘密を知らなくても署名を確認できます。Unchained が説明するのは 2-of-3 方式。三つの鍵のうち二つの署名が必要です。ピーターが A と B、サービスが C を持ちます。使える組み合わせは A+B、A+C、B+C で、C だけでは足りません。複数の署名を求める仕組みを Multisig と呼びます。ピーターはサービスなしで送金でき、鍵を一つなくしたら支援を求められます。ただし、同じ Seed Phrase、つまり同じ単語のバックアップから復元した二台の端末は独立していません。共通の秘密が漏れると両方が危険になります。 [1] [4] [8]
使える A+B とウォレットの完全な資料があれば、サービス停止だけでピーターの送金能力が失われるわけではありません。A しか残っていなければ、A+C のためにサービスが必要です。その停止や署名拒否で復旧できなくなることがあります。A と B の両方をなくしたら、C だけでは救えません。だから、自力で離脱する場合と支援を受けて復旧する場合は別々に試します。Casa の自社インフラを使わない復旧手順も、サービスの鍵を利用できない前提を明記しています。具体的な手順や機材は製品ごとに異なり、「collaborative」という言葉だけでは分かりません。 [1] [6]
ピーターがバックアップを持っていても、別のアプリはどのウォレットを再構築するかを知る必要があります。一般的な 2-of-3 では、サービスを含む三者すべての公開鍵と使用ルールが必要です。公開鍵は署名を検証し、秘密鍵は署名を作ります。Output Descriptor は、この構成やアドレスの導出方法をソフトウェアが読める形で記述したものです。自分の Seed Phrase が二つあっても、欠けたサービス側の公開鍵は再現できません。サービスが動いているうちにエクスポートして検証します。他人に渡す前には内容も確認します。汎用的な descriptor 形式には秘密鍵も含められるからです。 [4] [5]
コーディネーターは取引データを組み立て、署名者は承認用の鍵を持ちます。BIP 174 の PSBT 形式は、未完成の取引と必要な情報をソフトウェアや機器の間で受け渡します。ファイルを作っても不足する署名は補えません。ただし、鍵を持たないコーディネーターでも、別の送金先を提案して被害を与えることはできます。署名前に、アドレス、金額、手数料、change、つまり自分のウォレットへ戻る残額を確認します。Hardware Wallet は鍵をパソコンから切り離す助けになりますが、画面で何を確認でき、ピーターが何を承認したかも重要です。 [2] [3]
ミスは最初の送金より前、共同ウォレットを作る段階でも起こります。BIP 129 は、必要な署名数、参加する鍵、最初のアドレスを比較できるよう、鍵と設定を交換する方法を説明しています。支出条件を表すスクリプトの種類や、次の鍵を作る導出パスも対象です。設定をすり替えられると入金先を変えられるおそれがあります。ただし、この文書自体は端末内の保存領域の耐改ざん性や、その後の受取・change アドレスの検証を扱いません。標準への対応は、製品全体の安全認証ではありません。 [2]
XPUB は、ウォレットのある枝の公開鍵を導出する拡張公開鍵です。この情報と設定を知るサービスは、支出に必要な署名を持たなくても、アドレスや送金を追跡できる場合があります。顧客名のあるアカウントと結びつけば、身元との関連も生まれます。プライバシーと支出権限は別の問題です。「サービスだけでは送金できない」という説明にも条件があります。ピーターの別の鍵を入手したり、だまして不正な取引に署名させたりする可能性は残ります。権限を制限すれば一部のリスクは減りますが、すべてなくなるわけではありません。 [2] [4]
ピーターが鍵をなくし、アプリで新しい鍵を作ったとします。それだけで過去の入金に対する古い鍵が無効になるわけではありません。取引出力には、金額と、それを後で使うための条件が記録されています。資金は UTXO、つまりまだ使われていない取引出力として存在し、それぞれに支出条件があります。通常の Multisig では、新しい条件を作り、対象資金を確認済み取引でそこへ移す必要があります。その後、古いアドレスに残高がないか確認します。アカウントのパスワードや鍵の表示名を変えても移動の代わりにはなりません。設定と家族向けの手順も更新しなければ、相続人が現状に合わない計画を使うおそれがあります。 [4] [9]
有用な練習は、別のテスト用ウォレットで行います。ピーターは保存した設定を対応ソフトへ読み込み、アドレスを比較し、元のサービスなしで自分の鍵による署名ができるか確認します。Watch-only はアドレスや残高を表示するだけで、署名できる証明にはなりません。Caravan はオープンソースのコーディネーターですが、具体的な形式や機器への対応確認は必要です。支援付きの復旧、使えない鍵、手数料、change も試します。成果は残高表示による安心感ではなく、使用した版も含めた分かりやすい手順書にします。 [3] [6] [7]
理解を深めるには、この項目とあわせて次もお読みください Multisig, セルフカストディ, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. 次の項目からも参照されています Bitcoin Inheritance Plan, Institutional custody.