本シリーズを multisig とは何か から追っているなら、プロトコルは理解しているはずだ：お金が動く前に、複数の秘密鍵が署名しなければならない。m-of-n のセレクター、BIP48 の配線、Schnorr 集約の地平線、ソーシャル・リカバリとの比較 を見てきた。これらすべては 機械装置 だ。本稿は 体験 についての話だ。
multisig に対する正直な歴史的批評は、それが使い手に対して敵対的だったということだ。複数のウォレット、手作業の PSBT のやりとり、コーディネーター・ソフトウェア、署名パーティー — プロトコルは堅実だったが、UX は罰だった。single-signer multisig は、それを直すというプロダクト上のアイデアだ：完全な multisig 支出ルールをオンチェーンで使うウォレットだが、それを使う人にとっては — ボタンが一つしかない単一のウォレットのように感じられる。SSP はこのアイデアを軸に作られている。
TL;DR
- 「single-signer」は鍵が一つという意味ではない。 プロトコルにはまだ
m本／n本の鍵があるが、署名 UX は単一のフローに畳まれているという意味だ。ユーザーは一箇所で署名する；ウォレットがデバイス間の調整を引き受ける。 - SSP の具体的な形：ブラウザ拡張一つ、モバイルアプリ一つ（SSP Key）、ウォレット ID 一つ。Send をクリックし、電話で確認し、トランザクションがブロードキャストされる。署名は二回起きる；あなたが体験するのは一回。
- 勝ちは、閾値の恩恵（盗難耐性、単一障害点なし）を保ちながら、調整コスト がほぼ single-sig UX にまで下がるところ。
- コストは、これが両方のデバイスが届く範囲にある限りでしか機能しないこと。UX が複数性を表に出さねばならない瞬間 — リカバリ、デバイス交換、第三者上での復元 — 抽象は壊れる、設計通りに。
- このパターンは、リテール規模のソロ self-custody に対して「妥協なし」に最も近い答えだ。SSP の賭けであり、近代的な multisig 製品すべての賭けになりつつある（Coinbase Wallet、Phantom の進化する custody 物語、Ethereum 上の Safe のスマート・アカウント・フロー）。
single-signer の理想：ユーザーが実際に望むもの
self-custody ユーザーに望みを訊くと、互いに矛盾した答えが返ってくる：
- 「コインが安全であってほしい。」 — multisig、ハードウェア、冗長性を含意する。
- 「5 秒で署名したい。」 — 単一デバイス、ワンタップを含意する。
- 「何かを失っても復元したい。」 — Seed バックアップ、冗長性を含意する。
- 「もう二度と Seed を書きたくない。」 — プラットフォーム管理の鍵 custody を含意する。
- 「安く済ませたい。」 — オンチェーン・フットプリントの最小化を含意する。
これらの目標はすべては並び立たない。self-custody ウォレットの設計史は、どの目標を尊び、どれを丁寧に拒むかの歴史だ。ハードウェア・ウォレットは UX のコストを払って安全と復元を尊ぶ。スマート・コントラクト・ウォレットはクロスチェーンの届きやすさを犠牲に UX と復元を尊ぶ。純粋なホット・ウォレットは安全性のコストを払って UX と安さを尊ぶ。
single-signer multisig は、プロトコルの意味論 と インターフェースの意味論 を分離することで、五つすべてを — 部分的に — 尊ぼうとする試みだ。ウォレットはオンチェーンで完全な multisig のダンスを踏み続ける；ユーザーがそのダンスにトランザクションあたり 1 回以上参加せずに済むだけだ。
SSP はどう届けるか
SSP の具体的な実装、平易に言うと：
- セットアップ時、ブラウザ拡張とモバイルアプリ（SSP Key）をインストールする。それぞれが自分の seed を生成し、別々にバックアップする（これは 最初の 1000 のチェックリスト のステップだ）。2 つのデバイスは公開鍵を交換し、その後はプロトコル・レベルで一つのウォレット ID を共有する。
- 日常の署名時、ブラウザ拡張で Send をクリックし、トランザクションを確認して承認する。拡張は部分署名されたトランザクションを構築し、電話に通知をプッシュする。モバイルアプリはトランザクションの詳細を表示し、あなたは承認をタップし、アプリは 2 つ目の署名を生成する。拡張は両方の署名を結合してブロードキャストする。所要時間：両デバイスが目の前にあるとき約 8 秒。
- 受け取り時、表示されるアドレスは両方の xpub から BIP48 で派生された multisig アドレスだ。スキャンするかコピーする；送信者には何も普通でないものは見えない。彼らの側からは、ほかの暗号アドレスと同じに見える。
- 決済時、ウォレットは残高、履歴、手数料などを single-sig ウォレットと同じように表示する。別の「multisig 画面」はない。プロトコル上の形は、通常使用中は不可視だ。
設計上の重要な選択は、ユーザーが考えなければならない複数性は二つ目の署名だけ であるということ。セットアップは 2 つのデバイス、署名は 1 回追加のタップ、それがユーザー視点から見る multisig プロトコルの表面積のすべてだ。
小さいが重要なディテール：SSP のブラウザ拡張と SSP Key は同居していない。異なる OS、異なるハードウェア、異なる攻撃面の上にある。これが、2 つの署名のセットアップを単なる UX のスピードバンプではなく、本物の盗難バリアにしている。（これは 7 つの障害モードの記事 と 2-of-2 multisig とは何か で解説している。）
ユーザーが決して見ないこと
ユーザーに multisig の配管をいじらせないために、たくさんの仕事が費やされる。具体的には：
- PSBT（Partially Signed Bitcoin Transactions） は共同署名デバイスのあいだを行き来する大きいデータ構造だ。伝統的な multisig のセットアップでは、これらを手でコピー＆ペーストする。SSP はそれを自前の調整チャネル経由でシリアライズして送る；ユーザーは通知を見るのであって、base64 文字列を見るのではない。
- 共同署名者の xpub の交換 はセットアップ時の一度きりのイベントだ。伝統的な multisig では、各共同署名者から xpub を明示的にインポートする。SSP はそれをセットアップ時のペアリング・フローでくるむ；QR コードか 6 桁のコードを確認し、下にある材料には決して触れない。
- 手数料の見積もり、お釣りの処理、アドレスのローテーション は single-sig ウォレットと同じ方法でウォレットが行う、ウォレット自体は内部では multisig であっても。
- redeem スクリプト — multisig のルールを記述する BIP48 正規スクリプト — はウォレットが自動で構築する。ユーザーはそれを見ず、一行ずつ承認せず、存在を知る必要もない。（block explorer で見ようと思えば見られる、これが multisig ウォレットで最もきれいな「自分の作業を見せる」性質だ。）
その抽象すべては必要な仕事だが、同時に リスク でもある — プロトコルがユーザーから隠されるたびに、ウォレットは隠された部分を正しくやる責任を引き受ける。SSP の監査作業（Halborn）の多くは、まさしくその目に見えないコード経路に関するものだ。
single-signer に感じられなくなるとき
抽象は完璧ではないし、どこで壊れるかを知ることが重要だ。single-signer UX は 両方のデバイスが利用可能な限り 保たれる。片方が使えないとき、ひびが見える：
- デバイス交換。 スマホを買い替えたら、新しいデバイスを再ペアリングする必要がある。それは一度きりだが本当に見える multisig 調整ステップだ — ウォレットが両デバイスをお互いに見せ合うフローを案内する。
- Seed リカバリ。 デバイスが破壊された場合、その seed フレーズから新しいデバイスにリカバリし、再ペアリングする。あなたが 2 つ の seed を（デバイス毎に 1 つずつ）持っているという事実が、通常使用中とは違う形でこの瞬間に表に出る。
- クロスソフトウェアでのリカバリ。 万一 2 つの SSP seed を別の multisig ウォレット（Sparrow、Electrum など）にロードすれば、すべての multisig 配管が表に出る — これはバグではなくフィーチャーだ、なぜならそれがあなたのウォレットが相互運用可能であることを証明するからだ。だが SSP の UX ではない。
- 片方のデバイスがオフラインのとき支出する。 ウォレットは両方のデバイスがないと共同署名できない；それが プロトコル だ。もう一方のデバイスがオンラインになるまで、「2 つ目の署名待ち」の状態を見ることになる。
最初の 3 つはまれにしか起きないので平均 UX をそれほど劣化させない。4 つ目が最も一般的な摩擦点 — そして 正しい 摩擦点だ。もしウォレットが 2 つ目のデバイスなしで支出を許したら、もう 2-of-2 ウォレットではなくなる。その摩擦こそがセキュリティだ；その性質を取り払わずに摩擦を工学的に取り去ることはできない。
single-signer UX をめぐる設計
SSP — そして他の現代的な multisig 製品 — がこの抽象を密に保つために守る 3 つの設計原則：
- 2 つの共同署名者は異なる脅威面に住まなければならない。 両方の共同署名鍵を同じ OS に置くウォレットは実際にはセキュリティ恩恵を与えない；ただ単一の攻撃面を 2 つの鍵に広げているだけだ。SSP のブラウザ拡張とモバイルアプリの分割はそれを自然に強制する。
- 調整チャネルは偽造不可能でなければならない。 ブラウザ拡張がモバイルアプリに送る PSBT は、正しいウォレットと正しいトランザクションに暗号学的に紐づいていなければならない；そうでなければ抽象がそれ自体で攻撃面になる。SSP はこの素材をプロトコル層で署名し検証する。
- ユーザー契約は、何が隠されているかについて誠実でなければならない。 リカバリで何が起きるか を説明せずに「完全にトラストレスな single-signer 体験」と謳うウォレットは、ユーザーを不快な驚きに備えさせている。SSP のオンボーディングは両方の seed、両方のバックアップ、両方のリカバリ・シナリオを明示的に通る — 抽象は使用中は隠されるが、後から待ち伏せされないようにオンボーディングで露わにされる。
Ethereum 上のアカウント・アブストラクション・ウォレットには 4 つ目のツールがある：スマート・コントラクト層だ。ERC-4337 を使えば、ウォレットはガス代を吸収したり、トランザクションをバッチ化したり、より「single-signer 風」の UX を提示しつつ、内部では multisig を実装できる。SSP は Bitcoin にはその層を持たない（スマート・コントラクトがない）ので、抽象はチェーン側の吸収ではなく UX エンジニアリングにより多くを依存している。両方の道は妥当だ；Ethereum の道は柔軟性を持つがチェーン特有である代償を持ち、SSP の道は UI 作業がより多いという代償を伴うがより可搬性が高い。
あなたにとってこれが意味すること
要点 3 つ：
- 「一つのウォレットのように感じる」体験こそが見出しの機能で、multisig 自体ではない。 友人に「SSP は multisig ウォレット？」と尋ねられたら、技術的に正しい答えは「はい」だが、有用な 答えは「電話を一度タップして支出を確認する、2 デバイスのウォレット」だ。これが人々が実際に感じることを捉えている。
- 見える摩擦は本物の仕事をしている。 SSP が電話で確認を求めるたびに、それは、侵害されたラップトップから資金を空にされるのを止めるプロトコルを強制している。その摩擦が、そもそも hot wallet ではなく 2-of-2 ウォレットを使う 主な理由 だ。
- 抽象を契約として扱え、魔法としてではなく。 本シリーズの最終記事 multisig の障害モードと SSP がそれをどう緩和するか は、抽象の各ピースが壊れたときに何が起こるかを辿る — デバイス紛失、鍵漏洩、署名サーバー停止。一度は読むこと。抽象はよく設計されているが、障害モードを理解することが、本シリーズ全体が想定する種の self-custody ユーザーを作る。
