Bitcoinのマルチシグ復元：2つの鍵のほかに何が必要か

資金について：CypherpunkGuideは、リンク先の購入ガイドを通じて紹介報酬を得る場合がある。この記事に直接の購入用紹介リンクはない。今回の作業について、ウォレット事業者からスポンサー料は受けていない。

署名を取りまとめる管理アプリが使えなくなり、署名用端末も1台故障した。それでも、鍵のもとになる秘密情報であるシードのバックアップは2つ残っている。「3つのうち2つ」で使える仕組みなら、まさに備えていた故障のはずだ。

復元できる可能性はある。ただし、2-of-3という数字が表すのは必要な署名数であって、復元手順のすべてではない。残った鍵が署名していたウォレットを、同じ構成で再現できるかが問われる。

この記事で扱うのは、通常のBitcoinのP2WSH方式でsortedmultiを使うウォレットである。P2WSHは送金条件を記述したスクリプトを使う方式で、sortedmultiでは導出した公開鍵を一定の順序に並べ、その集合から所定数の署名を求める。ハードウェア端末、Taprootの署名方式、製品をまたぐ復元互換性は評価していない。一般的な自己管理の準備がまだなら、受領・署名・復旧の確認手順から始めるとよい。

署名用の鍵と、ウォレット全体の構成を分ける

#

2-of-3の送金条件は2つの鍵で満たせるが、アドレスの再現には構成全体が必要だ。対象の導出位置にある3つすべての公開鍵、必要な署名数、スクリプトの形式が含まれる。鍵が3つあることは、管理する人が3人いることを意味しない。

**ディスクリプタ（descriptor）**は、ウォレットが認識するスクリプトを一定の形式で記述した情報である。複数の公開鍵を順に作れる拡張公開鍵や、鍵を作る道筋にあたる導出経路を記録できる。BIP380は、秘密鍵だけのバックアップでは、スクリプトの形式や導出経路が不明になる場合を説明している。BIP383は、マルチシグの記述形式と、sortedmultiで導出後の公開鍵を並べ替える規則を定めている。

点検する材料は、次の3つに分けられる。

アプリによっては、1つのウォレットファイルが複数の役割を担う。ディスクリプタに構成情報の多くが含まれる場合もある。確認すべきなのは、書き出したファイルに何が入っているか、復元先のソフトウェアがその形式を扱えるかだ。ファイル名や誤記検出符号だけでは判断できない。

Sparrowのバックアップ画面の実装は、必要なシードとすべての拡張公開鍵に言及し、構成の保存先としてウォレットファイルやディスクリプタを挙げている。これはソースコードの確認結果であり、現行画面を実際に操作した評価でも、別製品での読み込み互換性を試した結果でもない。

隔離した復元実験で分かったこと

#

2026年9月24日、Bitcoin Core 31.1のregtest（外部ネットワークから切り離した試験用チェーン）で、アドレスの再現、指定した試験用出力の発見、署名の完成、ローカルノードでの受理を分けて測定した。実験区間は13.3秒で、開始前の版・ファイルのハッシュ確認と、終了処理・後片付けは含まない。公開された実験用の入力だけを使い、実資金は使っていない。終了時もピア通信は無効で、接続数は0件だった。

最初の5条件では、それぞれ新しい監視専用ウォレットを作り、構成情報を読み込んだ。比較対象は、取引によって作られる資金の単位である「出力」で、金額は0.01000000 regtest BTCだった。鍵A・B・Cは公開された実験用の入力から導出した。実機へシードを入力する試験ではない。

最後の3条件では、入金先にした番号1の受取アドレスを比較し、読み込んだ範囲で残高が見つからないことを確認した。範囲外のアドレスについては判定していない。Cを除いた条件も、あらゆる復元方法を試したわけではない。2-of-3を2-of-2へ置き換えた誤構成の試験であり、別のバックアップや過去のスクリプトが復元の手掛かりになるかは調べていない。

続いて、A/Bで署名した取引を試験用チェーンへ送った。受取用とお釣り用の両方を含むウォレットは、0.00599000 regtest BTCのお釣り出力を発見した。一方、元の入金を発見できていた受取用だけのウォレットでは、このお釣りを発見できなかった。比較したのは特定の出力であり、受取用だけのウォレットの総残高がゼロになったという意味ではない。実験には、採掘によって作った別の出力もあった。

誤記検出用のチェックサムを意図的に壊したディスクリプタも拒否された。その直前と直後には、元のディスクリプタが正常に処理されることを確認している。

実験プログラム、実測結果、安全上の制約を確認するテスト、未記入の復元点検表を添付した。アドレスの読み込み範囲は0〜2、過去の取引を再走査する基準時刻は0である。署名試験には、導出した実験用秘密鍵と、完全な参照用ウォレットから取得した正しいスクリプト・過去出力情報を渡している。シードからの復元手順全体、ハードウェアウォレットの復元、製品間の互換性を実証したものではない。ローカルでの受理判定そのものは、取引を送信しない。この条件付きの試験から、現実の復元成功率は推定できない。

再現に必要な環境と実行方法は、実験の説明書に記載した。公開されている実験用の鍵を、実資金の保管に使ってはいけない。

資金の発見と、送金できることを別々に確認する

#

復元したウォレットが出力を認識できても、それを使って送金できるとは限らない。反対に、探索条件が不足しているために、本来ある資金が表示されないこともある。

受取用とお釣り用のアドレスは、通常、別の導出経路を使う。復元した構成にお釣り用のスクリプトが含まれなければ、支払い後に残る資金が、そのウォレットの認識範囲から外れる場合がある。internalという内部用の分類フラグと、導出経路そのものを含めるか省くかは、同じことではない。

Coreのディスクリプタ読み込み処理とヘルプでは、読み込みの基準時刻、アドレスの範囲、内部用の分類を区別している。同期状態や利用できる過去のブロックも関係する。残高ゼロは原因を調べるべき表示であり、それだけで資金が消えた証拠にはならない。

読み込みの成功表示や、solvableという項目も、署名できることの証明には足りない。署名を確認するには、スクリプトの条件を満たす取引が完成している必要がある。ローカルのregtestで分かるのは、管理された条件下での動作だ。本番ネットワークでの承認や、端末の互換性を確かめたことにはならない。

公開構成情報も、渡す相手を限定する

#

公開情報だけのディスクリプタは、それ単独では署名できない。ただし、含まれる公開鍵と導出経路から作れるアドレスを明らかにする。共有すれば、その範囲の残高や取引を関連づけて追跡されるおそれがある。

「公開鍵」という名称は、ウォレットの構成情報を誰にでも公開してよいという意味ではない。閲覧できる人を限定し、秘密鍵を含むディスクリプタとも区別すること。公開鍵の漏えいは資金へ常に無害だ、と言い切れない理由もある。BIP32は、親の拡張公開鍵と、そこから通常導出（non-hardened）された子の秘密鍵を組み合わせると、親の秘密鍵を割り出せる場合を説明している。

この複合的な漏えいと、公開情報だけのディスクリプタ単独の漏えいは異なる。どちらの説明も、原因調査のためにウォレット情報を復元相談の掲示板へ投稿してよい理由にはならない。取引の関連づけによる問題は、Bitcoinのオンチェーン・プライバシーでも扱っている。

秘密情報を書き出さずに復元計画を点検する

#

点検表に記録するのは、必要な材料があるか、確認済みかという状態でよい。秘密情報を集め、気軽に共有してしまう新たな保管場所にしてはいけない。

添付の点検表では、必要な署名数、構成情報のバックアップ、受取用・お釣り用の対象範囲、読み込める形式、資金の発見と署名の個別確認を問う。シードの単語、パスフレーズ、公開鍵、実際のディスクリプタを書く欄はない。値ではなく確認状況を記録するためのものだ。

復元の確認には、利用しているウォレットや署名用端末の提供元が文書化した手順を使うこと。実際のシードをウェブサイト、チャット、この記事の実験プログラムへ入力してはいけない。誰でも再現できる実験用の鍵は、実資金の保管には適さない。一般的な暗号化バックアップの復元テストで確認できるのは、保存したファイルを取り出せるかまでだ。その内容だけで、特定のBitcoinウォレットから送金できるとは証明できない。

マルチシグでは、保管・調整・試験するものが増える。それらの管理が難しい状況で署名用端末だけを増やしても、復元計画が自動的によくなるわけではない。この記事は、その複雑さを点検するためのものであり、追加購入を勧めるものではない。

押さえておきたいこと

#

復元時によくある疑問

#

ディスクリプタを失うと、復元は不可能ですか？

#

必ずしも不可能ではありません。互換性のある別のバックアップに、構成情報が残っている場合があります。既知のスクリプトにも一部の情報が残ります。たとえばBIP141で定めるP2WSH出力を使って送金すると、その送金条件を示すwitness scriptが公開されます。ただし、それだけですべての拡張公開鍵が分かったり、ウォレット全体のアドレスを復元できたりするわけではありません。何が残っているかによって復元の条件が変わります。

チェックサムが正しければ、構成情報も正しいと判断できますか？

#

できません。チェックサムは、ディスクリプタの転記ミスを検出する助けになります。しかし、別のディスクリプタにも、それに合う正しいチェックサムを付けられます。信頼できるバックアップと、復元しようとしているウォレットに照らして構成を確認してください。記述形式が正しいことと、情報が真正であることは別です。

出典と保存版

#

上記の説明は次の一次資料に基づく。保存版は参照した資料を後から確認するために併記する。