Extended Public Key (xpub)

アンナはハードウェア機器で Bitcoin の鍵を管理しています。顧客から支払いがあったかをスマートフォンで確認するため、選んだ口座の公開設定を転送します。その中には xpub が入っていますが、秘密鍵はありません。スマートフォンは Watch-only Wallet として、対象のアドレスを確認し、新しいアドレスを用意し、未署名の取引を組み立てられます。送金には、引き続き秘密鍵を持つ機器の署名が必要です。同じ仕組みで、オンラインショップも支払い用の秘密鍵をサーバーに置かずに、注文ごとに異なる受取用アドレスを作れます。サーバー侵入時の被害を抑えられますが、万能ではありません。攻撃者が新たな支払い先として自分のアドレスを顧客に表示することはあり得ます。 [1] [5]

通常、支払ってもらう相手には Bitcoin アドレスを一つ渡します。xpub を渡すと、見える範囲が大きく広がります。口座の xpub とアドレス作成規則を知る人は、受取用とお釣り用のアドレスを導出し、それぞれの履歴や残高を結び付けられます。対象は導出可能な枝であり、ウォレット内の全口座が自動的に見えるわけではありません。会計サービスや外部のブロックエクスプローラーに渡した xpub は、保存され、将来の入金の監視にも使われる可能性があります。アプリで連携を解除しても、渡したコピーを無効にはできません。一度の支払いなら、通常はアドレス一つで十分です。より広い情報を渡すのは、必要な理由があるときに限りましょう。 [1] [5]

BIP32 のウォレットは、一つの起点から木のように鍵を導出します。ここでいう「枝」は導出された鍵のまとまりで、ネットワークやブロックチェーンの一部ではありません。xpub から先へ進めるのは、non-hardened と呼ばれる導出だけです。もう一種類の Hardened Derivation は秘密情報を必要とするため、xpub だけでは越えられない境界になります。一般的な BIP44 の構成では、各口座の手前にこの境界を設けます。そのため、一つの口座の xpub を書き出しても、それだけで他の口座を見られるようにはなりません。書き出す階層も重要です。受取用の枝だけの xpub は、通常お釣りも含む口座全体の xpub より、見える範囲が狭くなります。 [1] [6]

同じ公開鍵でも、作成規則によって異なる Bitcoin アドレスになります。取引の出力には金額と、その資金を後で使うための条件が記録されます。アプリは Native SegWit や Taproot などの出力形式と、導出する枝や番号を知る必要があります。SLIP-0132 の ypub、zpub という接頭辞はアドレス形式の手掛かりになりますが、ウォレット全体の説明ではありません。より正確に伝えられるのが Output Descriptor です。鍵と、アドレスや支出条件を作る規則を文章形式で記述します。鍵の出所、導出パス、入力ミスを検出するチェックサムを含めることもできます。チェックサムが確かめるのは文字列の整合性であり、送信者の信頼性ではありません。また、すべての descriptor が公開情報だけとは限りません。秘密鍵を含むものもあるので、共有する前に区別する必要があります。 [2] [3] [4]

最初に、ネットワーク、選んだ口座、アドレス形式、導出パスを確認します。導出パスは、鍵の木のどの位置を使うかを示す指示です。複数の受取用アドレスを元のウォレットと比較し、ハードウェアウォレットならメーカーの手順に従って機器の信頼できる画面で確認します。口座名が同じだけでは不十分です。読み込み後の残高がゼロでも、資金を失ったとは限りません。別の口座や形式を見ていたり、調べるアドレス番号の範囲が狭すぎたりする場合があります。その解決のために復元用の単語を見知らぬサイトへ入力してはいけません。確認だけが目的なら、Seed Phrase や拡張秘密鍵である xprv ではなく、公開設定のエクスポートを使います。 [4] [5]

xpub 自体は署名用の鍵ではありません。しかし BIP32 には重要な関係があります。親の xpub、資料でいう parent xpub と、non-hardened の子孫の秘密鍵がそろうと、親の秘密鍵を計算できます。さらに下の階層の子孫なら、その親までの全段階が non-hardened であり、対応する経路が計算時に分かっている必要があります。アドレスを知っただけで盗めるという話ではありません。同じ枝の公開情報と秘密鍵が組み合わさって漏れることが危険なのです。攻撃者は、その親の下にある他の鍵も得られる可能性があります。hardened の境界は口座を分離しますが、すでに漏れた秘密鍵そのものを保護し直すことはできません。 [1]

Multisig ウォレットは、例えば三つの鍵のうち二つによる署名を要求します。ただし、二つの鍵を復元できると分かっているだけでは十分ではありません。正しい支出条件を再現するには、他の参加鍵の公開情報、鍵の並び方、必要な署名数、導出規則も必要です。そのため秘密のバックアップに加え、必要な xpub をすべて含む公開 descriptor などの設定を保存します。設定だけで支出はできませんが、復元に欠かせないことがあります。master fingerprint は起点の鍵を示す十六進数八文字の識別子で、設定の対応付けに役立ちます。ただし、必ず一意の身分証ではありません。異なる鍵の fingerprint が一致することもあります。 [4] [5]

公開鍵は、対応する秘密鍵で作られた署名を検証するための情報です。BIP32 はこれに、次の鍵を導出するための三十二バイトの値 chain code を加えます。この組が拡張公開鍵です。持ち運び用の形式には、バージョンと木の中の位置も入ります。具体的には、深さ、直近の親の fingerprint、子の番号です。これは、ウォレットの最初の鍵からの完全な導出パスとは異なります。xpub は一つの受取用アドレスでも、口座のパスワードでもなく、取引一覧も持っていません。確認用ウォレットが対象アドレスの取引をブロックチェーンから探します。 [1]

BIP32 の CKDpub 関数は、親の公開鍵、chain code、子の番号を受け取ります。これらを入力とする暗号学的な計算 HMAC-SHA512 を使い、次の公開鍵と新しい chain code のための値を作ります。公開情報だけで導出できる番号は 0 から 2³¹−1 までです。hardened の番号は 2³¹ から始まり、パスでは通常アポストロフィーや h を付けて表します。こちらは xpub だけの CKDpub では導出できません。許された手順を繰り返して得られるのは、書き出した鍵の子孫であって、兄弟や祖先ではありません。BIP32 に定められたまれな無効結果が出た場合、実装は次の番号を試します。利用者が手計算する必要はありません。大事なのは設定を正しく移すことです。 [1]

標準 BIP32 の記録は、文字列に変換する前には 78 バイトです。内訳はバージョン 4、深さ 1、親の fingerprint 4、子の番号 4、chain code 32、鍵データ 33 バイトです。Base58Check がチェックサムを加え、111 文字に符号化します。Bitcoin のメインネット用の公開形式は xpub、テストネット用は tpub で始まります。対応する秘密形式は xprv と tprv です。tpub は Taproot の意味ではありません。接頭辞はバージョンのバイトから決まり、アドレスの全規則を表すものではありません。読み込み時には、ソフトウェアが先頭の文字や長さだけでなく、公開鍵そのものの有効性も検証する必要があります。 [1] [3]