BIP 32 — 階層的決定性ウォレット

最近の変更:

• (2013 年 4 月 16 日) i ≥ 0x80000000 に対する秘密鍵導出を追加 (親秘密鍵の漏洩リスクが低減される)
• (2013 年 4 月 30 日) I_L による乗算から I_L の加算に変更 (高速化、実装の簡素化)
• (2013 年 5 月 25 日) テストベクトルを追加
• (2014 年 1 月 15 日) インデックスが ≥ 0x80000000 の鍵をハードン化鍵に名称変更し、明示的な変換関数を追加
• (2017 年 2 月 24 日) 先頭ゼロを含むハードン化導出のテストベクトルを追加
• (2020 年 11 月 4 日) 先頭ゼロを含むハードン化導出向けの新しいテストベクトルを追加

BIP: 32
  Layer: Applications
  Title: Hierarchical Deterministic Wallets
  Authors: Pieter Wuille <pieter.wuille@gmail.com>
  Status: Deployed
  Type: Informational
  Assigned: 2012-02-11
  License: BSD-2-Clause

概要

本書は階層的決定性ウォレット (HD ウォレット) について述べる。これは、コインを使用する機能を備えるか否かを問わず、複数の異なるシステム間で部分的または全体的に共有可能なウォレットである。

本仕様は、異なるクライアント間で相互運用可能な決定性ウォレットの標準を定めることを意図している。本書で示すウォレットは多数の機能を備えるが、対応するクライアント側にすべての実装が要求されるわけではない。

仕様は 2 部から成る。第 1 部では、単一のシードから鍵ペアのツリーを導出する仕組みを示す。第 2 部では、そのツリーの上にウォレット構造を構築する方法を示す。

著作権

本 BIP は 2-clause BSD ライセンスの下で公開される。

動機

ビットコインのリファレンスクライアントはランダム生成された鍵を用いる。トランザクションごとにバックアップを取る必要を避けるため、(デフォルトで) 100 個の鍵を予備鍵のプールにキャッシュしている。それでもなお、これらのウォレットは複数のシステム上で同時に共有・使用する用途に向けて設計されてはいない。ウォレットの暗号化機能を用いてパスワードを共有しないことで秘密鍵を隠す運用は可能だが、その種の「去勢された」ウォレットは公開鍵を生成する能力までも失ってしまう。

決定性ウォレットはそうした頻繁なバックアップを必要とせず、また楕円曲線の数学的性質により、秘密鍵を明かすことなく公開鍵を計算する方式が可能になる。これにより、たとえばウェブショップ事業者は、対応する秘密鍵 (受領した資金を使用するために必要な鍵) へのアクセスを与えることなく、ウェブサーバーに注文ごと・顧客ごとの新しいアドレス (公開鍵ハッシュ) を生成させることができる。

しかしながら、決定性ウォレットは通例、鍵ペアの単一の「チェーン」から成る。チェーンが 1 本しかないということは、ウォレットの共有が「全部か無か」の単位でしか行えないことを意味する。だが場面によっては、(公開) 鍵の一部のみを共有・復元できるようにしたい場合もある。ウェブショップの例で言えば、ウェブサーバーは商店側ウォレットのすべての公開鍵にアクセスする必要はない。必要なのは顧客の支払いを受領するアドレスのみであって、商店が支払いを行う際に生成される釣銭アドレスなどは不要である。階層的決定性ウォレットは複数の鍵ペアチェーンを単一のルートから導出することで、そうした選択的共有を可能にする。

仕様: 鍵導出

慣習

本書の以降では、ビットコインで用いられている公開鍵暗号 — すなわち secp256k1 (http://www.secg.org/sec2-v2.pdf) で定義された体と曲線のパラメーターを用いる楕円曲線暗号 — を前提とする。以下に登場する変数は次のいずれかである。

• 曲線の位数 (n と呼ぶ) を法とする整数。
• 曲線上の点の座標。
• バイト列。

座標ペア 2 つの加算 (+) は、楕円曲線群演算の適用として定義される。 連結 (||) は、あるバイト列を別のバイト列の末尾に追加する演算である。

標準的な変換関数として、以下を仮定する。

• point(p): secp256k1 のベースポイントに整数 p を乗じた楕円曲線点乗算 (楕円曲線群演算の反復適用) の結果として得られる座標ペアを返す (すなわち、秘密鍵から公開鍵を計算するために用いられる演算)。
• ser₃₂(i): 32 ビット符号なし整数 i を、最上位バイトを先頭とする 4 バイト列としてシリアライズする。
• ser₂₅₆(p): 整数 p を、最上位バイトを先頭とする 32 バイト列としてシリアライズする。
• ser_P(P): 座標ペア P = (x,y) (すなわち公開鍵) を、SEC1 (https://www.secg.org/sec1-v2.pdf) の圧縮形式 (0x02 または 0x03) || ser₂₅₆(x) を用いてバイト列としてシリアライズする。先頭バイトは省略された y 座標の偶奇に依存する。
• parse₂₅₆(p): 32 バイト列を、最上位バイトを先頭とする 256 ビット整数として解釈する。

拡張鍵

以降では、親鍵から複数の子鍵を導出する関数を定義する。これらの子鍵が鍵そのものだけに依存することを避けるため、まず秘密鍵と公開鍵の両方を、追加の 256 ビットのエントロピーで拡張する。この拡張部分はチェーンコードと呼ばれ、対応する秘密鍵と公開鍵で同一であり、32 バイトから成る。

拡張秘密鍵は (k, c) と表す。ここで k は通常の秘密鍵、c はチェーンコードである。拡張公開鍵は (K, c) と表す。ここで K = point(k)、c はチェーンコードである。

各拡張鍵は 2³¹ 個の通常の子鍵と、2³¹ 個のハードン化子鍵を持つ。各子鍵にはインデックスが付与される。通常の子鍵はインデックス 0 から 2³¹-1 を使用する。ハードン化子鍵はインデックス 2³¹ から 2³²-1 を使用する。ハードン化鍵のインデックス表記を簡潔にするため、i_H は i+2³¹ を表す。

子鍵導出 (CKD) 関数

親拡張鍵とインデックス i が与えられたとき、対応する子拡張鍵を計算することが可能である。そのアルゴリズムは、子鍵がハードン化鍵か否か (すなわち i ≥ 2³¹ であるか否か)、また対象が秘密鍵か公開鍵かによって異なる。

親秘密鍵 → 子秘密鍵

関数 CKDpriv((k_par, c_par), i) → (k_i, c_i) は、親拡張秘密鍵から子拡張秘密鍵を計算する。

• i ≥ 2³¹ であるか (すなわち子鍵がハードン化鍵であるか) を確認する。
  • そうである場合 (ハードン化子鍵): I = HMAC-SHA512(Key = c_par, Data = 0x00 || ser₂₅₆(k_par) || ser₃₂(i)) とする。(注: 0x00 は秘密鍵を 33 バイト長にするためのパディングである。)
  • そうでない場合 (通常の子鍵): I = HMAC-SHA512(Key = c_par, Data = ser_P(point(k_par)) || ser₃₂(i)) とする。
• I を 32 バイト列 2 つ、I_L と I_R に分割する。
• 返される子鍵 k_i は parse₂₅₆(I_L) + k_par (mod n) である。
• 返されるチェーンコード c_i は I_R である。
• parse₂₅₆(I_L) ≥ n または k_i = 0 となる場合、結果として得られる鍵は無効であり、次の i の値で処理を続行すべきである。(注: この事象の確率は 2¹²⁷ 分の 1 を下回る。)

HMAC-SHA512 関数は RFC 4231 (http://tools.ietf.org/html/rfc4231) で定義されている。

親公開鍵 → 子公開鍵

関数 CKDpub((K_par, c_par), i) → (K_i, c_i) は、親拡張公開鍵から子拡張公開鍵を計算する。この関数は非ハードン化子鍵に対してのみ定義される。

• i ≥ 2³¹ であるか (すなわち子鍵がハードン化鍵であるか) を確認する。
  • そうである場合 (ハードン化子鍵): 失敗を返す。
  • そうでない場合 (通常の子鍵): I = HMAC-SHA512(Key = c_par, Data = ser_P(K_par) || ser₃₂(i)) とする。
• I を 32 バイト列 2 つ、I_L と I_R に分割する。
• 返される子鍵 K_i は point(parse₂₅₆(I_L)) + K_par である。
• 返されるチェーンコード c_i は I_R である。
• parse₂₅₆(I_L) ≥ n または K_i が無限遠点となる場合、結果として得られる鍵は無効であり、次の i の値で処理を続行すべきである。

親秘密鍵 → 子公開鍵

関数 N((k, c)) → (K, c) は、拡張秘密鍵に対応する拡張公開鍵を計算する (トランザクションへの署名能力を取り除くため「去勢された」版と呼ばれる)。

• 返される鍵 K は point(k) である。
• 返されるチェーンコード c は、渡されたチェーンコードそのものである。

親秘密鍵から子公開鍵を計算する場合:

• N(CKDpriv((k_par, c_par), i)) (常に動作する)。
• CKDpub(N(k_par, c_par), i) (非ハードン化子鍵に対してのみ動作する)。 両者が等価であるという事実こそが非ハードン化鍵を有用たらしめている (任意の秘密鍵を知ることなく、ある親鍵の子公開鍵を導出できる)。また、それがハードン化鍵との区別をなす要因でもある。より有用である非ハードン化鍵を常に使用しない理由はセキュリティにある。詳細は後述する。

親公開鍵 → 子秘密鍵

これは不可能である。

鍵ツリー

次の段階は、複数の CKD 構成をカスケードしてツリーを構築することである。まず 1 つのルート、すなわちマスター拡張鍵 m から始める。CKDpriv(m,i) を複数の i の値で評価することで、レベル 1 の導出ノードを複数得る。これらもそれぞれ拡張鍵であるため、CKDpriv を再度適用することができる。

表記を簡潔にするため、CKDpriv(CKDpriv(CKDpriv(m,3_H),2),5) を m/3_H/2/5 と書く。同様に公開鍵については、CKDpub(CKDpub(CKDpub(M,3),2),5) を M/3/2/5 と書く。この結果として次の恒等式が成立する。

• N(m/a/b/c) = N(m/a/b)/c = N(m/a)/b/c = N(m)/a/b/c = M/a/b/c。
• N(m/a_H/b/c) = N(m/a_H/b)/c = N(m/a_H)/b/c。 ただし、N(m/a_H) は N(m)/a_H として書き換えることはできない。後者が不可能であるためである。

ツリー内の各葉ノードは実際の鍵に対応し、内部ノードはそこから派生する鍵の集合に対応する。葉ノードのチェーンコードは無視され、そこに埋め込まれた秘密鍵または公開鍵のみが意味を持つ。この構成により、拡張秘密鍵を知ることは派生するすべての秘密鍵と公開鍵の再構成を可能にし、拡張公開鍵を知ることは派生するすべての非ハードン化公開鍵の再構成を可能にする。

鍵識別子

拡張鍵は、シリアライズされた ECDSA 公開鍵 K の Hash160 (SHA256 後の RIPEMD160) によって、チェーンコードを無視した形で識別できる。これは従来のビットコインアドレスで使用されるデータと完全に一致する。ただし、このデータを base58 形式で表現することは推奨されない。アドレスとして解釈されてしまう可能性があるためである (またウォレットソフトウェアにはチェーン鍵そのものへの支払いを受け付ける義務はない)。

識別子の先頭 32 ビットは鍵フィンガープリントと呼ばれる。

シリアライズ形式

拡張公開鍵および拡張秘密鍵は、以下のようにシリアライズされる。

• 4 バイト: バージョンバイト (メインネット: 公開鍵 0x0488B21E、秘密鍵 0x0488ADE4。テストネット: 公開鍵 0x043587CF、秘密鍵 0x04358394)
• 1 バイト: 深さ (depth)。マスターノードは 0x00、レベル 1 の導出鍵は 0x01、以下同様。
• 4 バイト: 親鍵のフィンガープリント (マスター鍵の場合は 0x00000000)
• 4 バイト: 子番号。これは x_i = x_par/i における i に対する ser₃₂(i) であり、x_i がシリアライズ対象の鍵となる。(マスター鍵の場合は 0x00000000)
• 32 バイト: チェーンコード
• 33 バイト: 公開鍵または秘密鍵データ (公開鍵の場合は ser_P(K)、秘密鍵の場合は 0x00 || ser₂₅₆(k))

この 78 バイトの構造は、他のビットコインデータと同様に、まず 32 ビットのチェックサム (二重 SHA-256 チェックサムから導出される) を付加し、次に Base58 表現に変換することで Base58 エンコードできる。これにより、ちょうど 111 文字の Base58 エンコード文字列が得られる。バージョンバイトの選択により、Base58 表現はメインネットでは “xprv” または “xpub”、テストネットでは “tprv” または “tpub” で始まる。

なお、親フィンガープリントはソフトウェアにおいて親ノードと子ノードを高速に検出する手段にすぎず、ソフトウェアは衝突に対処できなければならない。内部的には、完全な 160 ビット識別子を用いてもよい。

シリアライズされた拡張公開鍵をインポートする際、実装は公開鍵データ内の X 座標が曲線上の点に対応するかを検証しなければならない。対応しない場合、その拡張公開鍵は無効である。

マスター鍵の生成

取りうる拡張鍵ペアの総数はおよそ 2⁵¹² であるが、生成される鍵の長さは 256 ビットしかなく、セキュリティ強度としては約その半分しか提供しない。そのため、マスター鍵は直接生成されるのではなく、相対的に短くてもよいシード値から生成される。

• (P)RNG から、選択した長さ (128 ビットから 512 ビットの範囲。256 ビットを推奨) のシードバイト列 S を生成する。
• I = HMAC-SHA512(Key = “Bitcoin seed”, Data = S) を計算する。
• I を 32 バイト列 2 つ、I_L と I_R に分割する。
• parse₂₅₆(I_L) をマスター秘密鍵、I_R をマスターチェーンコードとして用いる。 parse₂₅₆(I_L) が 0 または parse₂₅₆(I_L) ≥ n となる場合、そのマスター鍵は無効である。

仕様: ウォレット構造

前の各節では鍵ツリーとそのノードを定義した。次の段階は、このツリーの上にウォレット構造を課すことである。本節で定義するレイアウトはあくまでデフォルトであり、すべての機能を実装するわけではない場合でも、互換性のためにクライアントがこれに倣うことを推奨する。

デフォルトのウォレットレイアウト

HD ウォレット (HDW) は複数の「アカウント」として構成される。アカウントには番号が振られ、デフォルトアカウント ("") は番号 0 である。クライアントは複数のアカウントに対応する必要はなく、対応しない場合はデフォルトアカウントのみを用いる。

各アカウントは内部 (internal) と外部 (external) の 2 本の鍵ペアチェーンから構成される。外部キーチェーンは新しい公開アドレスの生成に用いられ、内部キーチェーンはそれ以外のすべての操作 (釣銭アドレス、生成アドレス、…、対外的に伝える必要のないものすべて) に用いられる。これら 2 種類のキーチェーンを区別しないクライアントは、すべての用途で外部キーチェーンを用いるべきである。

• m/i_H/0/k は、マスター m から導出された HDW のアカウント番号 i の外部チェーンにおける k 番目の鍵ペアに対応する。
• m/i_H/1/k は、マスター m から導出された HDW のアカウント番号 i の内部チェーンにおける k 番目の鍵ペアに対応する。

利用ケース

ウォレット全体の共有: m

2 つのシステムが単一の共有ウォレットにアクセスする必要があり、双方が支払いを実行できる必要がある場合は、マスター秘密拡張鍵を共有する必要がある。ノードは外部チェーン向けに N 個の先読み鍵プールをキャッシュし、受信支払いを監視できる。内部チェーンの先読みは極めて小さくてよい。この箇所ではギャップが発生する想定がないためである。最初の未使用アカウントのチェーンに対して、追加の先読みを有効化することもできる — その鍵が使用された時点で新しいアカウントの作成を引き起こすという仕組みである。なお、アカウントの名称は依然として手動で入力する必要があり、ブロックチェーン経由で同期させることはできない。

監査: N(m/*)

監査人が受払一覧へのフルアクセスを必要とする場合、すべてのアカウントの公開拡張鍵を共有することができる。これにより監査人はウォレットの全アカウントにおけるすべての送受信トランザクションを参照できるが、秘密鍵は 1 つも漏れない。

拠点別残高: m/i_H

事業者が複数の独立した拠点を持つ場合、それらの拠点はすべて単一のマスターから導出されたウォレットを用いることができる。これにより本社は、すべての拠点の受払トランザクションを参照できるスーパーウォレットを保持でき、さらには拠点間で資金を移動することも可能になる。

反復的な事業者間トランザクション: N(m/i_H/0)

2 つの事業パートナーが頻繁に資金を移動させる場合、特定のアカウントの外部チェーンの拡張公開鍵 (M/i h/0) を一種の「スーパーアドレス」として用いることができる。これにより、(容易には) 関連付けが行えない頻繁なトランザクションを、支払いごとに新しいアドレスを要求することなく実現できる。 このような仕組みはマイニングプール運営者が可変的な支払先アドレスとして用いることも可能である。

安全でない受領サーバー: N(m/i_H/0)

電子商取引サイトを運営するために安全でないウェブサーバーが用いられる場合、そのサーバーは受領用の公開アドレスを把握する必要がある。ウェブサーバーが知る必要があるのは、単一アカウントの外部チェーンの拡張公開鍵のみである。これは、ウェブサーバーに不正にアクセスした者がせいぜい受信支払いを観測できるにとどまり、資金を盗むことも、送信トランザクションを (自明には) 識別することも、複数のウェブサーバーが存在する場合に他のウェブサーバーが受領した支払いを参照することもできないことを意味する。

互換性

本標準に準拠するためには、クライアントは少なくとも拡張公開鍵または拡張秘密鍵をインポートでき、その直接の子をウォレット鍵として利用可能にできなければならない。仕様の第 2 部で提示されたウォレット構造 (master/account/chain/subchain) はあくまで助言的位置付けだが、互換性を確保しやすくするための最小構造として推奨される — 別個のアカウントを設けない場合や、内部チェーンと外部チェーンを区別しない場合でも同様である。ただし、実装は特定の要件に応じてこの構造から逸脱してもよく、より複雑なアプリケーションではより複雑なツリー構造を要する場合もある。

セキュリティ

楕円曲線公開鍵暗号そのものに対する期待に加えて — すなわち、

• 公開鍵 K が与えられたとき、攻撃者は楕円曲線離散対数問題 (2¹²⁸ 回の群演算を要すると想定される) を解くよりも効率的に対応する秘密鍵を見つけることはできない。

本標準が意図するセキュリティ特性は以下のとおりである。

• 子拡張秘密鍵 (k_i,c_i) と整数 i が与えられたとき、攻撃者は HMAC-SHA512 に対する 2²⁵⁶ 回の総当たりよりも効率的に親秘密鍵 k_par を見つけることはできない。
• 互いに異なる i_j を持つ (インデックス、拡張秘密鍵) のタプル (i_j,(k_ij,c_ij)) を任意の個数 (2 ≤ N ≤ 2³²-1) 与えられたとき、これらが共通の親拡張秘密鍵から導出されたか否か (すなわち、各 j ∈ (0..N-1) について CKDpriv((k_par,c_par),i_j)=(k_ij,c_ij)) を満たす (k_par,c_par) が存在するか否か) を判定することは、HMAC-SHA512 に対する 2²⁵⁶ 回の総当たりよりも効率的には行えない。

ただし、以下の特性は成立しないことに留意せよ。

• 親拡張公開鍵 (K_par,c_par) と子公開鍵 (K_i) が与えられたとき、i を見つけることは困難である。
• 親拡張公開鍵 (K_par,c_par) と非ハードン化子秘密鍵 (k_i) が与えられたとき、k_par を見つけることは困難である。

含意

秘密鍵と公開鍵は通常どおり安全に管理されなければならない。秘密鍵の漏洩はコインへのアクセスを意味し、公開鍵の漏洩はプライバシーの喪失を意味する可能性がある。

拡張鍵についてはやや慎重な扱いが要求される。これは鍵の (部分) ツリー全体に対応するためである。

直ちには明らかでないかもしれない弱点として、親拡張公開鍵に加えてそこから派生する非ハードン化秘密鍵を 1 つ知ることは、親拡張秘密鍵 (したがってそこから派生するすべての秘密鍵と公開鍵) を知ることと等価である、という性質がある。これは、拡張公開鍵が通常の公開鍵よりも慎重に扱われなければならないことを意味する。 これがハードン化鍵が存在する理由でもあり、ツリー内のアカウント階層でハードン化鍵が用いられる理由でもある。このようにすることで、アカウント固有 (またはそれ以下) の秘密鍵が漏洩しても、マスターや他のアカウントを危険にさらすことは決してない。

テストベクトル

テストベクトル 1

Seed (hex): 000102030405060708090a0b0c0d0e0f

• Chain m
  • ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8
  • ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
• Chain m/0_H
  • ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
  • ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7
• Chain m/0_H/1
  • ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ
  • ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs
• Chain m/0_H/1/2_H
  • ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5
  • ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM
• Chain m/0_H/1/2_H/2
  • ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV
  • ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334
• Chain m/0_H/1/2_H/2/1000000000
  • ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy
  • ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76

テストベクトル 2

Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542

• Chain m
  • ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB
  • ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
• Chain m/0
  • ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH
  • ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt
• Chain m/0/2147483647_H
  • ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a
  • ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9
• Chain m/0/2147483647_H/1
  • ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon
  • ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef
• Chain m/0/2147483647_H/1/2147483646_H
  • ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL
  • ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc
• Chain m/0/2147483647_H/1/2147483646_H/2
  • ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt
  • ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j

テストベクトル 3

これらのベクトルは先頭ゼロの保持を検証する。詳細は bitpay/bitcore-lib#47 (https://github.com/bitpay/bitcore-lib/issues/47) および iancoleman/bip39#58 (https://github.com/iancoleman/bip39/issues/58) を参照。

Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be

• Chain m
  • ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13
  • ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6
• Chain m/0_H
  • ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y
  • ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L

テストベクトル 4

これらのベクトルは先頭ゼロの保持を検証する。詳細は btcsuite/btcutil#172 (https://github.com/btcsuite/btcutil/issues/172) を参照。

Seed (hex): 3ddd5602285899a946114506157c7997e5444528f3003f6134712147db19b678

• Chain m
  • ext pub: xpub661MyMwAqRbcGczjuMoRm6dXaLDEhW1u34gKenbeYqAix21mdUKJyuyu5F1rzYGVxyL6tmgBUAEPrEz92mBXjByMRiJdba9wpnN37RLLAXa
  • ext prv: xprv9s21ZrQH143K48vGoLGRPxgo2JNkJ3J3fqkirQC2zVdk5Dgd5w14S7fRDyHH4dWNHUgkvsvNDCkvAwcSHNAQwhwgNMgZhLtQC63zxwhQmRv
• Chain m/0_H
  • ext pub: xpub69AUMk3qDBi3uW1sXgjCmVjJ2G6WQoYSnNHyzkmdCHEhSZ4tBok37xfFEqHd2AddP56Tqp4o56AePAgCjYdvpW2PU2jbUPFKsav5ut6Ch1m
  • ext prv: xprv9vB7xEWwNp9kh1wQRfCCQMnZUEG21LpbR9NPCNN1dwhiZkjjeGRnaALmPXCX7SgjFTiCTT6bXes17boXtjq3xLpcDjzEuGLQBM5ohqkao9G
• Chain m/0_H/1_H
  • ext pub: xpub6BJA1jSqiukeaesWfxe6sNK9CCGaujFFSJLomWHprUL9DePQ4JDkM5d88n49sMGJxrhpjazuXYWdMf17C9T5XnxkopaeS7jGk1GyyVziaMt
  • ext prv: xprv9xJocDuwtYCMNAo3Zw76WENQeAS6WGXQ55RCy7tDJ8oALr4FWkuVoHJeHVAcAqiZLE7Je3vZJHxspZdFHfnBEjHqU5hG1Jaj32dVoS6XLT1

テストベクトル 5

これらのベクトルは、無効な拡張鍵が無効として認識されることを検証する。

• xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6LBpB85b3D2yc8sfvZU521AAwdZafEz7mnzBBsz4wKY5fTtTQBm (公開鍵バージョン / 秘密鍵の不一致)
• xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGTQQD3dC4H2D5GBj7vWvSQaaBv5cxi9gafk7NF3pnBju6dwKvH (秘密鍵バージョン / 公開鍵の不一致)
• xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6Txnt3siSujt9RCVYsx4qHZGc62TG4McvMGcAUjeuwZdduYEvFn (無効な公開鍵プレフィックス 04)
• xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGpWnsj83BHtEy5Zt8CcDr1UiRXuWCmTQLxEK9vbz5gPstX92JQ (無効な秘密鍵プレフィックス 04)
• xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6N8ZMMXctdiCjxTNq964yKkwrkBJJwpzZS4HS2fxvyYUA4q2Xe4 (無効な公開鍵プレフィックス 01)
• xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFAzHGBP2UuGCqWLTAPLcMtD9y5gkZ6Eq3Rjuahrv17fEQ3Qen6J (無効な秘密鍵プレフィックス 01)
• xprv9s2SPatNQ9Vc6GTbVMFPFo7jsaZySyzk7L8n2uqKXJen3KUmvQNTuLh3fhZMBoG3G4ZW1N2kZuHEPY53qmbZzCHshoQnNf4GvELZfqTUrcv (深さが 0 にもかかわらず親フィンガープリントが非ゼロ)
• xpub661no6RGEX3uJkY4bNnPcw4URcQTrSibUZ4NqJEw5eBkv7ovTwgiT91XX27VbEXGENhYRCf7hyEbWrR3FewATdCEebj6znwMfQkhRYHRLpJ (深さが 0 にもかかわらず親フィンガープリントが非ゼロ)
• xprv9s21ZrQH4r4TsiLvyLXqM9P7k1K3EYhA1kkD6xuquB5i39AU8KF42acDyL3qsDbU9NmZn6MsGSUYZEsuoePmjzsB3eFKSUEh3Gu1N3cqVUN (深さが 0 にもかかわらずインデックスが非ゼロ)
• xpub661MyMwAuDcm6CRQ5N4qiHKrJ39Xe1R1NyfouMKTTWcguwVcfrZJaNvhpebzGerh7gucBvzEQWRugZDuDXjNDRmXzSZe4c7mnTK97pTvGS8 (深さが 0 にもかかわらずインデックスが非ゼロ)
• DMwo58pR1QLEFihHiXPVykYB6fJmsTeHvyTp7hRThAtCX8CvYzgPcn8XnmdfHGMQzT7ayAmfo4z3gY5KfbrZWZ6St24UVf2Qgo6oujFktLHdHY4 (未知の拡張鍵バージョン)
• DMwo58pR1QLEFihHiXPVykYB6fJmsTeHvyTp7hRThAtCX8CvYzgPcn8XnmdfHPmHJiEDXkTiJTVV9rHEBUem2mwVbbNfvT2MTcAqj3nesx8uBf9 (未知の拡張鍵バージョン)
• xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21Teqt1VvEHx (秘密鍵 0 が 1..n-1 の範囲外)
• xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFAzHGBP2UuGCqWLTAPLcMtD5SDKr24z3aiUvKr9bJpdrcLg1y3G (秘密鍵 n が 1..n-1 の範囲外)
• xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6Q5JXayek4PRsn35jii4veMimro1xefsM58PgBMrvdYre8QyULY (無効な公開鍵 020000000000000000000000000000000000000000000000000000000000000007)
• xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHL (無効なチェックサム)

謝辞

• Gregory Maxwell — 第 2 種決定性ウォレットの原案、およびそれに関する数多くの議論への貢献に対して。
• Alan Reiner — 本方式の Armory での実装、およびそこから派生した提案に対して。
• エリック・ロンブロゾ — 本 BIP のレビューと改訂に対して。
• Mike Caldwell — 人間が認識しやすい Base58 文字列を得るためのバージョンバイトの提案に対して。