HD Wallet

Aliceが受取画面を開くと、ウォレットにアドレスが表示されます。そこに10 000 satoshiが届きました。satoshiはBitcoinの小さな単位です。次の受け取りではアプリが別のアドレスを提示し、そこに20 000 satoshiが届きます。この二つだけが未使用の入金なら、ウォレットには合計30 000 satoshiと表示されます。新しいアドレスで独立した口座ができたわけでも、前のお金が自動的に移動したわけでもありません。アプリが両方の入金に対応する鍵を管理しています。これを使いやすくするのがHD Walletです。HDはHierarchical Deterministicの略です。鍵が枝分かれした構造を持つので「階層的」、同じシードとパスからは復元時にも同じ鍵を得られるので「決定論的」と呼びます。パスとは、どの枝のどの鍵を計算するかを指定する数字の並びです。日常の受け取りでAliceが意識することは少なくても、復元には正しいパスが必要です。そのため、出発点となる秘密のバックアップは将来のアドレスもカバーできますが、ウォレットの設定も保存しておく必要があります。新しいアドレスはアドレスの使い回しを避けるのに役立つものの、それだけで匿名性が保証されるわけではありません。 [1] [12]

拡張公開鍵は一般にxpubと呼ばれ、この構造の一部の公開鍵を計算するために使います。支払いに署名する秘密鍵は含まれません。そのためxpubだけで資金を使うことはできず、具体的なアドレスを作るには、その形式もアプリに知らせる必要があります。適切な xpub を持つ watch-only ウォレットは、署名鍵なしでアドレスを生成し、入金を追跡できます。ただし xpub が漏れると、その枝の過去と将来のアドレス、残高、取引が結び付けられる可能性があります。必要な枝だけを共有してください。正しい xpub でも、侵害されたコンピューターが他人のアドレスを表示することは防げません。そのウォレットを認識している信頼できる署名機器で受取アドレスを確認します。 [1] [12] [14]

店は注文ごとに別のアドレスを作れます。ウェブサイトにはアドレスが必要ですが、売上を使う鍵まで持たせるべきではありません。BIP32 はこの受取用の枝を、ウォレットの残りの部分から分離できます。提案の著者は Pieter Wuille で、割り当て日は2012年2月11日です。これはウォレットの標準であり、コンセンサス規則ではありません。BIP39 のバックアップ単語、スクリプトの種類、復元手順全体は別の層が扱います。 [1] [11] [12]

BIP32 は鍵に256ビットの chain code、つまり次の導出に使う32バイトを加えます。秘密形式は secp256k1 のスカラー k と chain code c、公開形式は K = point(k) と同じ c で構成されます。マスター鍵の生成には HMAC-SHA512 を使い、関数の鍵を正確な文字列「Bitcoin seed」、データをシードとします。左の32バイトが秘密鍵候補、右の32バイトが chain code です。候補がゼロ、または曲線の位数 n 以上ならマスター鍵は無効です。 [1]

導出は計算であり、保存済みの一覧を検索する処理ではありません。 導出には通常の方式とhardened方式があります。通常の方式では親の拡張公開鍵から次の公開鍵を計算できますが、hardenedの段階では親の拡張秘密鍵が必要です。 CKDpriv は I = HMAC-SHA512(cpar, data) を計算し、IL と IR に分け、parse256(IL) を親秘密鍵に加えて n を法とします。IR が新しい chain code です。通常の導出は serP(Kpar) || ser32(i)、hardened は 0x00 || ser256(kpar) || ser32(i) を使い、i ≥ 2^31 です。CKDpub は Kpar に point(parse256(IL)) を加え、通常の公開鍵の枝だけを作れます。枝番号が変われば、その先の鍵も変わります。 [1]

パスが hardened の段階を越えない限り、xpub から公開鍵を導出できます。ただし代償があります。親の xpub と、漏洩した通常の子秘密鍵がそろうと、親秘密鍵を逆算できます。その親から分かれる他の枝も危険になります。hardened はこの逆算を防ぎますが、シードの盗難、弱い乱数、悪意ある取引の誤承認は防ぎません。 [1]

mainnet の標準的な公開鍵表現は xpub、秘密鍵表現は xprv で始まり、バージョンはそれぞれ 0x0488B21E と 0x0488ADE4 です。Base58Check 符号化前は78バイトで、バージョン4、深さ1、親の指紋4、子番号4、chain code 32、鍵データ33で構成されます。符号化後は111文字です。短い指紋は鍵の対応確認用で、身元の証明ではありません。SLIP132 の ypub/zpub はスクリプトの種類を示す場合がありますが、接頭辞だけを変えても鍵やウォレットの規則は変わりません。 [1] [9]

BIP43 は最初の hardened 階層を用途に割り当てました。BIP44 は m / 44' / coin_type' / account' / change / address_index を使います。アカウントの次は受取用の枝0か、お釣り用の枝1、その後がアドレス番号です。アポストロフィまたは h は、インデックスに 2^31 を加えることを示します。BIP44 の探索には gap limit 20 があり、未使用の受取アドレスが20個続くと停止します。BIP48 は Multisig、BIP84 の用途 84' はネイティブ SegWit、BIP86 の 86' は単一鍵の Taproot を扱います。これらはシード自体に保存されず、ノードが強制する規則でもありません。 [2] [3] [4] [5] [6]

鍵だけでは、資金を保護するスクリプトは決まりません。Output Descriptor は鍵の由来、パス、wpkh() などの構造、必要署名数、他の Multisig 参加者、チェックサムを記録できます。Multipath descriptor なら受取とお釣りの枝をまとめられます。一人のシードでは、他の xpub や共通規則は復元できません。検証済みの公開ディスクリプターや設定のエクスポートも保存し、そのプライバシーを守ってください。秘密鍵を含むエクスポートは秘密情報として扱います。 [7] [8] [10] [13]

シードから鍵を再導出できますが、アプリにはシード形式、使用した BIP39 passphrase、ネットワーク、スクリプトの種類、coin type、アカウント、両方の枝、探索範囲が必要です。Multisig には共通設定も必要です。復元後の残高がゼロでも、資金が失われたとは限らず、別のパスを探している場合があります。信頼できる機器での安全なテストでは、正しいUTXO、つまりまだ使われていない取引の出力を見つけ、署名できることを確認します。本物のシードやバックアップ単語を、ウェブツールや通常のオンラインコンピューターに入力してはいけません。 [3] [7] [10] [11]

BIP32 は、parse256(IL) ≥ n、導出した秘密鍵がゼロ、公開点が無限遠点となるような、まれな無効結果も扱います。その子鍵では次のインデックスを試します。復元でより起きやすいのは、パスやお釣りの枝の不足、スクリプト形式の非対応です。アプリを変える前に資金の検出と少額の試験送金を確認してください。新しい手順が機能するまで元のバックアップと設定を残します。xprv は署名に必要な鍵を導出でき、xpub は取引関係を明かし、ディスクリプターはウォレットの構成を説明します。 [1] [7] [9] [10]