本シリーズではこれまで、multisig とは何かとどの閾値を選ぶかを扱ってきた。どちらの記事も multisig ウォレットの 振る舞い を描いていた — n 本のうち m 本の鍵が署名し、チェーンが閾値を確認し、お金が動く。どちらも、その下でウォレットが 実際にどう組み立てられているか についてはあまり語っていなかった。本稿がそれだ。
短い版：SSP があなたにウォレットを作るとき、ただ 2 本の鍵をランダムに生成して終わりにしているわけではない。BIP48 と呼ばれる文書化された標準に従う仕方で生成しているので、出来上がるウォレットは相互運用可能で、SSP 以外のソフトウェアでも復元でき、オンチェーンでの検査でも予測可能だ。これが BIP48 とは何か、なぜ存在するか、そして「このウォレットは BIP48 を使っている」がなぜ multisig で最も退屈で最も重要な文の一つなのかを説明する記事だ。
TL;DR
- 派生パスは、ひとつの seed phrase からウォレット内の特定の鍵（とアドレス）へと至る道だ。BIP44 / BIP48 のような標準化されたパスにより、異なるウォレットソフトウェアが同じ seed から同じ鍵に到達できる。
- BIP48 は multisig ウォレット専用の仕様だ。次のように言っている：ここに、主要な出力スクリプトタイプを横断する 2-of-3、3-of-5 などのウォレットを構成する
m本の鍵のための正規派生パスがある。 - SSP は BIP48 を使う。つまり、あなたの SSP ウォレットが生成した二つの seed は、任意の他の BIP48 互換ウォレット（Sparrow、Electrum、Bitcoin Core のディスクリプタ）から使える — SSP 自身からだけではない。
- BIP48 は以前の multisig 仕様（BIP45）が抱えていた問題を直す：異なるスクリプトタイプ（legacy、P2SH-wrapped SegWit、native SegWit、Taproot）の鍵をきれいに分離し、ひとつの seed phrase でそれらすべてを衝突なく保持できるようにする。
- SSP を使うために派生パスを手作業で扱う必要はない。だが、それらが存在すると知っているべきだ — 「ウォレットの復元」が魔法のように感じられず、自分の seed が本当に何にマップされているかを理解できるように。
派生パスの 30 秒ツアー
BIP48 が意味を持つ前に、下にある機構が存在していなければならなかった。その機構が BIP32：hierarchical deterministic（HD）ウォレットだ。中心となる発想は、seed phrase から派生する一つのマスター鍵が、無限の子鍵の木を決定的に生成できる、というもの。木の中で特定のパスを歩けば、必ず同じ子鍵に行き着く。違うパスを歩けば、違う鍵に行き着く。
パスはこうした見た目だ：
m / purpose' / coin_type' / account' / change / index
例えば、BIP44 パス m / 44' / 0' / 0' / 0 / 0 は、BIP44 のルール下で Bitcoin の最初のアカウントの最初の受取アドレスに到達する。coin_type を 60' に変えれば Ethereum の空間、purpose を 84' に変えれば BIP84（native SegWit）の空間、というふうに進む。アポストロフィ（'）は hardened 派生 — 子は親に逆変換できない。マスターより後の各セグメントは、慣習で分割された 32 ビットの数だ。
ここがしばしば軽く流される部分だ：パスはメタデータであって、秘密ではない。あなたのパス と あなたの秘密鍵（または拡張鍵）を知る人は誰でも、同じアドレスを派生できる。パスはウォレットに どこを見るか を伝える。Seed は そこに何があるか を伝える。
seed そのものが何かについての親しみやすい復習として、seed phrase best practices の記事が前提読み物だ。
BIP48 が規定すること
BIP48 は m / 48' / coin_type' / account' / script_type' / change / index に住んでいる。興味深い追加は script_type' — 末尾から 2 番目のセグメントだ。
そのセグメントは、そのパスがどの multisig 出力に対応するかを符号化する：
0'→ P2SH（レガシー multisig）1'→ P2SH-wrapped SegWit（P2WSH-in-P2SH）2'→ native SegWit（P2WSH）3'→ Taproot 相当 multisig（BIP48 の修正による）
これが大事なのは、実際には同じ m-of-n の共同署名者集合でも、どの出力スクリプトを使うかによって チェーン上では異なるアドレス が生まれるからだ。BIP48 が無いと、あるウォレットは黙って一方を使い、復元ソフトはもう一方を仮定し、結果として、同じコインを派生するべきように見える 二つのウォレットが、実は異なるアドレスを計算しているせいで異なるコインを派生してしまう。
BIP48 はまた purpose' セグメントを 48' に固定するので、multisig パスは single-sig の BIP44/BIP49/BIP84 のパスと衝突しない。ひとつの seed が BIP84 の single-sig ウォレットと BIP48 の 2-of-2 multisig ウォレットを、干渉なく同居させられる。それぞれが自分の部分木に住む。
パスそのものを超えて、BIP48 は共同署名者の公開鍵（「xpubs」）を multisig 出力の構築時にどう順序付けるかを規定する。正規ルールは、redeem スクリプトに入る前に公開鍵を 辞書順 に並べること。これは曖昧さを除く — 同じ xpubs から構築する BIP48 準拠ウォレットは、いずれも 同じ アドレスを計算する。そのルールが無ければ、二つのウォレットが同じ鍵を異なる順序で組み合わせ、同じ redeem ルールでも異なるアドレスに行き着き得てしまう。
仕様そのものを読みたければ、Bitcoin BIPs リポジトリにある（bips/bip-0048.mediawiki）。
SSP は実務で BIP48 をどう使うか
SSP のウォレットをセットアップすると、二つの seed phrase が生成される — ひとつはブラウザ拡張に、ひとつはモバイルアプリ SSP Key に。それぞれの seed phrase はマスター秘密鍵に対応する。各マスターから、SSP は該当チェーン（Bitcoin、Ethereum、Flux、SSP がサポートする残りの集合）の BIP48 パスを script_type' = 2' で派生する（Bitcoin では native SegWit；他のチェーンでも該当する正規形）。
両方の署名者の xpubs はその後交換される。双方は今、BIP48 に従って辞書順に並んだ 同じ 二つの xpubs の集合を持つ。そのペアから、双方が独立に同じアドレスを計算する。二つの半身は決して秘密鍵を共有しない — 公開鍵だけがデバイス間を移動する。
お金を受け取るとき、表示されるアドレスは二つの xpubs から計算された BIP48 由来のアドレスだ。支払うとき、各デバイスは同じトランザクションを自分自身の秘密鍵で署名する。オンチェーンの redeem スクリプトは両方の公開鍵を参照する；ネットワークは両方の署名を検証する。それがプロトコルのすべてだ。
これが 復元 シナリオで重要な理由：もし SSP というプロダクトが明日消えても、あなたは依然として二つの BIP48 準拠の seed phrase を持っている。両方を Sparrow（または SSP が使う BIP48 パスをサポートする任意の multisig 対応ウォレット）に読み込めば、同じウォレットが、同じアドレスで、完全な使用能力をもって再構築される。ウォレットは SSP の中には住んでいない — オンチェーンに住み、seed と BIP48 仕様があれば、どこからでも届く。
この性質が、self-custody-without-cold-storage の記事が 2-of-2 SSP ウォレットを custodial 風味の好奇心ではなく本格的なウォレットとして扱う大きな理由だ。オープンな標準から復元できる。
なぜ BIP45 ではなく BIP48 か（そして BIP44 でもない）
前世代の multisig 仕様は BIP45 だった。正直な最初の試みだった：m / 45' / cosigner_index' / change / index、cosigner_index' がウォレット内のどの共同署名者かを符号化する。振り返ると、二つの問題があった。
第一に、cosigner_index' が順序をパス自体に焼き付けてしまった。これは署名者を追加する順序が派生に影響することを意味し、共同セットアップを脆く ── 順序を間違えれば、共同署名者と異なるアドレスを派生してしまう。BIP48 は cosigner index をパスから完全に取り除き、公開鍵の辞書順がそれを担うことでこれを解決する。
第二に、BIP45 はスクリプトタイプで分けなかった。ウォレットが legacy P2SH multisig を使っていようと、SegWit-wrapped multisig を使っていようと、同じパスが使い回された。これが先ほどの「アドレス衝突だが同じコインではない」問題を生んだ。
より一般的な HD 仕様の BIP44 は、multisig を扱うとは決して主張しなかった。BIP44 に multisig パスを過剰積載しようとすれば、独自の衝突を生んだ。BIP48 はその明示的修正だ：専用の purpose 番号、明示的なスクリプト型スロット、決定的な鍵順序。今日、ほとんどの現代的 multisig ウォレットがそれに収束している；事実上の標準だ。
これが multisig の次章 ── Schnorr 集約、複数署名がひとつに圧縮される ── にどうつながるかの、より深い歴史については、本シリーズの次稿 Schnorr signatures and multisig aggregation がその糸を拾う。
これは相互運用性にとって何を意味するか
「この multisig ウォレットは本当に self-custodial か？」の最もきれいなテストはこれだ：ウォレットのソフトウェア無しでこれを復元できるか？答えがイエス ── 文書化された seed、文書化された派生パス、標準的なツールを使って ── ならウォレットは本当にあなたのものだ。答えがノーなら、ウォレットには隠れた custodial 要素がある。
SSP の BIP48 適合は イエス と答えられることの根拠だ。Seed phrase は BIP39（標準 mnemonic）、派生は BIP48、アドレス構築は BIP48 正準。同じ標準を話す任意のウォレットがウォレットを再構築できる。
だからこそ導入 Meet SSP Wallet は SSP を managed サービスではなく「2-of-2 multisig による self-custody」と位置づける。下にある標準が、その位置づけを誠実なものにしている。
あなたにとってこれが意味すること
要点 3 つ：
- SSP を使うのにパスを暗記する必要はない。
m/48'/0'/0'/2'/0/0という数字は、普通のユーザが手で打つべきものではない。だが、それが 存在する と知ることが、「SSP 無しでこのウォレットを復元できる」を本当の主張にし、マーケティングではなくする。 - あなたの二つの seed は相互運用可能。 いつかサードパーティの multisig ウォレットへ復元する必要が出たら、BIP48 と二つの BIP39 seed と該当チェーンの
coin_typeがレシピだ。self-custody チェックリスト がこれをリハーサルステップとして名指しているのには理由がある。 - BIP48（または同等のもの）を使わない multisig ウォレットは疑う価値がある。 製品があなたの鍵からアドレスがどう派生されるかを正確に説明できないなら、それは self-custody ではない ── 余計な手順を伴う custody だ。標準への適合こそが、「あなたの鍵、あなたのコイン」という主張を検証可能にする。
