SLIP-39 は、複数の単語リストでウォレットをバックアップする標準です。それぞれのリストを復元用シェアと呼び、何個の異なるシェアが復元に必要かを事前に決めます。例えば三つのうち二つを必要とする方式なら、一つを失っても復元できます。一つだけでは足りません。SatoshiLabs が作成したこの標準は、秘密を数学的に分散する Shamir’s Secret Sharing を使います。通常の BIP 39 Seed Phrase を単に書き換えたものではありません。
アンナは三つのうち二つで復元するバックアップを選びます。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。ウォレットは異なる三つのシェアを作り、どの二つでも復元できます。この必要最小数が閾値です。同じシェアの写真を二枚持っていても、一つとしか数えません。単純な方式は一つのグループを使います。SLIP-39 では、3 グループ中 2 グループ、各グループで 3 シェア中 2 シェアが必要、といった複雑なルールも設定できます。A の二つと B の二つなら十分ですが、A の三つと B の一つでは A しか条件を満たしません。紙の枚数だけでなく、組み合わせが重要なのです。 [1] [6]
各リストには異なるデータと、正しく組み合わせるための情報が入っています。SLIP-39 は固定の 1024 語の英単語リストを使います。ウォレットの画面が日本語でも、バックアップの単語は翻訳しません。128 ビットの秘密なら各シェアは 20 単語、256 ビットなら 33 単語になります。ビットはデータの基本単位で、追加で書き留める単語ではありません。シェアにはセット、グループ、シェア位置の識別情報、必要な閾値、暗号化設定も含まれます。復元時にはそれらの整合性と、シェアが互いに異なることを確認します。同じ長さのリストなら何でも混ぜられるわけではありません。 [1]
アンナは passphrase、自分で決める追加のパスワードも使えます。必要なシェアを集めても、これを代用することはできません。正しいシェアの組み合わせでも、passphrase の入力ミスは直接判別できません。違う入力は別の主秘密を生み、別のウォレットを開くからです。そのため「有効なバックアップ」という表示だけでなく、既知のアドレスと結果を照合します。Passphrase を使わない場合は空の入力になります。SLIP-39 が許すのは印字可能な ASCII 32–126、空白を含むアクセント記号のない基本的なラテン文字などです。この制限はこの標準のもので、全ウォレット共通ではありません。Passphrase は機器を解除する PIN とは違います。 [1]
BIP 39 Seed Phrase は生成方法も単語リストも異なります。単語を数枚の紙に分けても SLIP-39 のシェアにはなりません。同じウォレットを維持するには、BIP 32 の鍵ツリーの秘密の入力データである seed と、使用する鍵へ至る正しい Derivation Path を保つ必要があります。単語を作る前のランダムなデータ、元のエントロピーを別形式で符号化するだけでは不十分です。BIP 39 は単語と passphrase から 512 ビットの seed を作ります。これを直接 SLIP-39 でバックアップすると、シェアは各 59 単語になります。一つのウォレットを変換しても、別の passphrase で開く他のウォレットまで自動的に移せるわけではありません。対応する具体的な手順を先に確認する必要があります。 [1] [3] [2]
extendable フラグ付きの対応バックアップなら、同じウォレットを保ったまま分け方を変更できます。Trezor は単一シェアから複数シェアへの変更をこの仕組みで説明しています。ただし、紙を交換してもアンナの秘密は変わっていません。十分な古い組み合わせは今も使えます。古いシェアと新しいシェアは混ぜません。技術的には、フラグが 1 の場合、salt と呼ばれる暗号化の補助入力からセット識別子を除きます。そのため同じ encrypted master secret（EMS、暗号化された主秘密）を、passphrase を知らずに新しい識別子で再分割できます。これは、使える古いバックアップが漏れたことへの対策にはなりません。 [1] [4]
秘密鍵は、ウォレットが資金を使うことを承認するデジタル署名を作るための秘密の数値です。アンナのウォレットは復元後、通常どおり署名できます。シェアの保有者が毎回の支払いを承認する必要はありません。SLIP-39 は一つの秘密を復元し、Multisig は支出条件に従って複数の署名を要求します。同じ住居に三つのシェアを置けば、一度の火災で全部失うかもしれません。配置は同時喪失と攻撃者による必要数の収集の両方を難しくするべきですが、複雑な方式ほど復元の負担も増えます。復元確認は信頼できる機器で、対応する手順に従って行います。参照ライブラリ python-shamir-mnemonic は、開発者が公開テスト例で互換性を調べるためのもので、本物のバックアップを処理するためのものではありません。秘密を十分に保護しないと明記されています。 [1] [4] [5] [6]
BIP 32 ウォレットの主秘密は入力 seed であり、計算済みの鍵ツリーの拡張秘密ルートではありません。まず seed を暗号化し、その結果の EMS を分割します。暗号化には Feistel 構造を四ラウンド使い、各ラウンドで PBKDF2-HMAC-SHA256 を 2500×2^e 回反復します。保存される指数 e が計算負荷を決めます。これは厳密に定義されたパスワード処理であり、ランダムな単語の追加ではありません。分割計算は、256 個の値を持つ数学的構造 GF(256) でバイトごとに行います。多項式の f(255) に秘密を置き、閾値が 2 以上なら f(254) に digest と呼ばれる検証値を置きます。 [1] [2]
シェアの最後の三単語は RS1024 チェックサムを構成します。最大三単語に影響する誤りを必ず検出しますが、作成者の署名や所有権の証明ではありません。標準が自動訂正を勧めないのは、ソフトウェアが有効でも別の単語を作ってしまう可能性があるからです。組み合わせ時には、さらに 32 ビットの digest が不正なセットの検出に役立ちます。ただし理論上の留意点もあります。閾値より一つ少ないシェアを持つ人は、総当たり探索で秘密の候補の一部を除外できます。したがって「閾値未満では情報が全く漏れない」という数学的主張は、そのまま適用できません。簡単に破れるという意味ではなく、十分に強い元の秘密を標準が要求する理由です。 [1]
理解を深めるには、この項目とあわせて次もお読みください Shamir Secret Sharing, BIP 39, Trezor, Multisig, HD Wallet, Seed Phrase. 次の項目からも参照されています BIP 39, Trezor, Pavol「Stick」Rusnák, Shamir Secret Sharing.