アドレスを一つ公開したままでも追跡されない方法

寄付ページにビットコインアドレスを一つ掲載している人がいるとしよう。bc1qで始まるその文字列は、半年後に何になっているだろうか。寄付者名簿であり、リアルタイムの残高開示であり、寄付金額と時刻の完全な記録である。ブロックエクスプローラーにその文字列を貼り付けるだけで誰でも見られる。さらに厄介なのは、寄付した側まで露出することだ。支援者のUTXOがそのアドレスに流れ込んだ瞬間、その人がどこでコインを得ていくら残しているかが同じ画面に付いてくる。

アドレスを再利用するなという原則は、ビットコインプライバシーの第一戒である。問題は、この原則が「毎回新しいアドレスを相手に手渡せる人」にしか当てはまらないことだ。寄付を受ける団体、インターネット上に決済情報を掲示する販売者、名刺にアドレスを印刷した開発者、毎月同じ相手から給与を受け取る人には、それができない。一度公開して何度も受け取るアドレスは、これまでプライバシーを放棄する代償としてのみ存在できた。

サイレントペイメント（Silent Payments、BIP-352）はこのジレンマを取り除く。静的なアドレスを一つ永久に公開しておきながら、そのアドレス宛の決済はブロックチェーンのどこにもアドレスと結びつく痕跡を残さない。オンチェーンに記録されるのは、毎回異なる、ごく平凡に見えるタップルートアウトプットだけである。

従来の解法が止まった地点

静的アドレス問題への挑戦は、サイレントペイメントが最初ではない。

対話的なアドレス交換。 決済のたびに受取人が新しいアドレスを生成して送金者に渡す方式だ。プライバシーは完璧だが、双方が同時にオンラインである必要があり、アドレスを渡す別のチャネルも要る。寄付者一人ひとりとメッセージを往復する寄付ページなど存在しえない。BTCPay Serverのような決済サーバーはこの過程を自動化してくれるが、サーバーを運用しなければならず、アドレスを発行するそのサーバーがすべての決済を知ることになる。

BIP-47の再利用可能な決済コード。 一度公開した決済コードから決済ごとに新しいアドレスを導出する方式である。考え方はサイレントペイメントと同じだが、送金者が最初に支払う前にオンチェーンへ通知トランザクション（notification transaction）を一件送る必要がある。これが問題だ。手数料がかかるうえ、何より「誰がこの決済コードに関心を示したか」が永久にチェーンに残る。寄付者名簿を消そうとして、寄付の意思表明名簿を作ってしまったことになる。BIP-47を主軸に据えていたウォレットのエコシステムが2024年以降大きく縮小したことも、普及が停滞した理由の一つである。

サイレントペイメントは通知トランザクションを不要にする。送金者は受取人に何も知らせず、事前の接触も一切なく、トランザクション一件だけで決済が完結する。「静かな決済」という名前の由来だ。

送金者がアドレスを計算する

核心にあるのは順序の反転である。通常は受取人がアドレスを作って送金者に渡す。サイレントペイメントでは送金者が自らアドレスを計算して作り出す。 材料は二つだ。受取人が公開したspアドレスと、送金者がこれから使うインプットの秘密鍵である。

spアドレスの中身

サイレントペイメントアドレスはsp1qで始まるbech32m文字列である（テストネットはtsp1）。最低117文字と、見慣れたbc1qアドレスよりはるかに長い。長さの理由は、中に33バイトの圧縮公開鍵が二つ入っているからだ。

• スキャンキー（B_scan）: 自分宛の決済を見つけるために使う鍵。対応する秘密鍵は常時オンラインである必要がある。
• 支出キー（B_spend）: 見つけたコインを実際に使うときに必要な鍵。ハードウェアウォレットに隔離しておける。

この分離が実務上重要である。スキャンにはスキャン秘密鍵さえあればよいので、常時稼働するノードにスキャンキーだけを置き、支出キーはコールドのまま保てる。ウォッチオンリーウォレットが残高を見るのと同じ構図だ。

送金者が行う計算

送金側のウォレットは、おおよそ次の手順でアウトプットを作る。

1. このトランザクションで使う適格インプットの秘密鍵をすべて足す。その和をaとし、対応する公開鍵をA = a·Gとする。
2. インプットのアウトポイントのうち辞書順で最小のものを選び、input_hash = hash(outpoint_L || A)を計算する。
3. 受取人のスキャンキーとECDHで共有秘密を作る。共有秘密 = input_hash · a · B_scan
4. アウトプットごとにトゥイークを導出する。t_k = hash(共有秘密 || k)（kは0から始まる）
5. 最終的なアウトプット鍵を作る。P_k = B_spend + t_k·G

P_kはそのままBIP341のタップルートアウトプットになる。つまりチェーンに記録されるのはbc1pで始まる平凡なタップルートアウトプットであり、他のタップルート決済と区別する方法がない。サイレントペイメントを使っているという事実自体がオンチェーンに現れないということだ。

3の手順になぜinput_hashが掛かっているのかが、この設計の微妙な部分である。同じ送金者が同じ受取人へ二度送るとき、もし共有秘密がインプットと無関係なら、同じアウトプット鍵が二度出てきて結局アドレス再利用になる。アウトポイントは世界に一度しか存在しないため、インプットの集合が異なれば共有秘密は必ず変わる。トランザクションごとに新しいアウトプットが出るのは偶然ではなく保証である。

受取人は同じ計算を反対側から行う

受取人は送金者の秘密鍵を知らない。代わりに、トランザクションに公開されたインプット公開鍵の和Aを見ることができる。楕円曲線の性質により、input_hash · b_scan · Aは送金者が計算したinput_hash · a · B_scanとまったく同じ値になる。双方が異なる材料から同じ秘密に到達する。

共有秘密が得られればt_kを導出してP_kを計算し、そのトランザクションのタップルートアウトプット鍵と照合する。一致するものがあれば自分宛の決済だ。一致を見つけたらkを一つ上げてもう一度確認する。一つのトランザクションが自分宛に複数のアウトプットを送ることがあるからである。

受取人が代わりに払う代償：スキャン

ここまでが良い知らせだ。代償は受取側に集中している。

送金者が何の通知もなくアウトプットを作るため、受取人は自分宛の決済があるかを自力で探し出さなければならない。 新しいブロックが来るたびに、その中のトランザクションを一つずつ検査するほかない。従来のウォレットのように「自分のアドレス一覧に該当するアウトプットがあるか」を文字列で照合するのではなく、トランザクションごとに楕円曲線演算を回す必要がある。

コストが爆発しない理由は、演算がアウトプットごとではなくトランザクションごとに一回だからである。トランザクション一件に対してECDHを一度計算し、その結果でアウトプットを比較する。それでもノートパソコンで数秒で終わる作業ではなく、スマートフォンのウォレットが単独で担うのはさらに難しい。

検査対象は思ったより少ない

BIP-352はスキャン対象を絞る条件を明示している。次をすべて満たすトランザクションだけが候補だ。

• タップルートアウトプットが一つ以上あること
• 適格インプットが一つ以上あること：P2TR、P2WPKH、P2SH-P2WPKH、P2PKH
• SegWitバージョン1を超えるアウトプットを使うインプットがないこと

適格インプットから外れるものも明確である。条件分岐のあるスクリプト、複数の公開鍵を使うマルチシグスクリプト、非圧縮公開鍵を使う旧来のインプットは除外される。送金者が「このインプットの秘密鍵を確実に持っている」と断定できる形式だけを残す規則だ。タップルートのスクリプトパス支出は含まれるが、内部鍵にNUMSポイントを使った場合は除外される。支出できる内部鍵がそもそも存在しないためである。

スキャンを誰に任せるかが分かれ道

プライバシーが実際にどこまで守られるかは、この選択で決まる。

フルノードで自らスキャンする。 自分のノードがすべてのブロックを受け取って直接検査する。外部に何も尋ねないのでプライバシーは完全だ。その代わりノードを運用し、インデックスの負担を自分で負うことになる。

SP対応のインデクサー／サーバー。 サーバーがあらかじめトゥイークデータを計算してウォレットに渡す。Sparrow 2.5.0はこの方式で受取機能を実装し、frigate.2140.devというSP対応Electrumサーバーを必須として自動選択する。接続したサーバーは少なくとも「この人はサイレントペイメントをスキャンしている」という事実を知る。

フィルタベースのライトクライアント。 BlindBit系はサーバーがブロックごとのトゥイークとフィルタのみを配布し、マッチング判定はクライアント側で行う。サーバーは誰が何を受け取ったかを知りえない。通信量とプライバシーの折衷案である。

復元は確実に遅くなる

シードフレーズからウォレットを復元する場面を考えてみよう。通常のHDウォレットはアドレスを順に導出して照会すれば終わる。サイレントペイメントウォレットはウォレットが作られた時点から現在までのブロックを再スキャンしてはじめて残高を再構成できる。ウォレット生成高（birth height）をシードとともに書き留めておく習慣が、ここで実質的な差を生む。バックアップの封筒に「2026-08-20、ブロック912000」と一行足しておくだけで、復元時間は大きく短縮される。

ラベル：アドレス一つで送金元を区別する

静的アドレスの裏返しは「誰が送ったか分からない」ことだ。寄付ページを一つ運用するだけなら構わないが、複数の経路から入ってくる資金を区別しなければならない場合がある。

BIP-352のラベル（label）がこの問題を解く。支出キーにラベル整数mから作った値を足してB_m = B_spend + hash(b_scan || m)·Gを作り、これを支出キーの位置に入れたspアドレスを発行する。スキャンキーは変わらないのでスキャンは一度で済み、マッチしたアウトプットから引き算をすれば、どのラベル経由で入った資金かが分かる。実質的に「チャネル別の口座番号」を無限に発行できるわけだ。

注意点が二つある。

m=0は予約されている。 自分のお釣りを認識するために使うラベルなので、このアドレスは決して公開してはならない。

ラベルアドレス同士は結びつく。 すべてのラベルアドレスが同じスキャンキーを共有するため、二つのラベルアドレスを公開の場に掲示すれば、観察者は即座に同一人物のものだと分かる。ラベルは入ってきた資金を分類する道具であって、異なる身元を作る道具ではない。身元を分けたいならウォレットを分ける必要がある。

2026年8月時点で実際に使えるのか

BIP-352の仕様は2024年5月にBIPリポジトリへマージされ、2026年に入って受取実装が本格的に登場し始めた。現状を整理するとこうなる。

ウォレット	送金	受取
Cake Wallet	対応	対応
Sparrow Wallet	対応	対応（2.5.0、2026年5月）
Dana Wallet	対応	対応
BlindBit Desktop	対応	対応
BlueWallet	対応	非対応
BitBox	対応	非対応
Nunchuk	対応	非対応
Wasabi Wallet	対応	非対応
Bitcoin Core	開発中	開発中

ハードウェア署名デバイスの状況はより良い。BitBox02、Coldcard、Krux、SeedSignerがソフトウェアウォレットと組み合わせたときにサイレントペイメントの署名に対応する。Sparrow 2.5.0はエアギャップのハードウェア署名機を含めて受取ウォレットを構成できる。

注目すべきは、Bitcoin Coreにまだリリース済みのウォレット機能がないという点である。受取機能のPRは開いているが、送金PRとSPインデックスPRはマージされずにクローズされた。仕様の参照実装の位置にあるソフトウェアが最後に到着する構図であり、これが普及速度を最も大きく左右する。

まとめると、送る側はすでに広く対応済みで、受け取る側はまだ選択肢が狭い。 spアドレスを公開しても相当数のウォレット利用者は送金できるが、そのアドレスを運用する側は数少ない候補から選ばなければならない。

実践：寄付アドレスを変えるなら

今すぐ適用したい人のための現実的な手順である。

1. 受取ウォレットを先に決める。 デスクトップ中心でハードウェアウォレットを使うならSparrow、モバイル中心ならCake Walletが現時点で最も無難な組み合わせだ。プライバシーを最後まで確保したいなら、自分のノードとSPインデックスを組み合わせる構成を選ぶ。

2. フォールバックアドレスを必ず併記する。 依然として多くの取引所はspアドレスへ出金できない。「取引所から直接送る方は下のアドレスへ、対応ウォレットをお使いの方はspアドレスへ」のように二行で案内するのが現実的だ。フォールバックアドレスはどうせ再利用されるので、そちらに入った資金は最初から別のUTXOとして分類し管理する。

3. ウォレット生成高をバックアップに書き添える。 上で述べた復元の問題のためである。

4. ラベルを使うかを事前に決める。 寄付、商品販売、給与を区別する必要があるならラベルを発行する。ただし各ラベルアドレスを同じウェブページに並べて掲示すると結びつくことを忘れない。

サイレントペイメントが解決しないこと

過大評価を防ぐため、境界線を明確にしておくほうがよい。

送金者は依然として自分が送ったアウトプットを知っている。 サイレントペイメントは第三者の観察者や他の寄付者から受取人を守る。自分に送金した人がそのアウトプットを追跡し続けることは防げない。ただし送金者が見られるのは自分が送ったそのアウトプット一つだけであり、受取人の他の収入は見えない。公開アドレスがすべてを露出していたのと比べれば決定的な差である。

送金側のプライバシーは別の問題だ。 KYC取引所から出金したばかりのUTXOで決済すれば、その決済は依然として自分の身元と結びついたコインから出ている。サイレントペイメントは受取アドレスの再利用問題を解くだけで、インプットの履歴を洗浄はしない。

CoinJoinの代替ではない。 両者は異なる層の問題を扱う。CoinJoinはすでに保有しているUTXOの過去のつながりを断ち、サイレントペイメントはこれから受け取るUTXOが最初からつながらないようにする。併用でき、併用したほうがよい。

UTXOの管理を代行してくれるわけでもない。 異なる送金者から受け取ったサイレントペイメントのアウトプットを一つのトランザクションにインプットとしてまとめれば、共通インプット所有ヒューリスティックによってそれらが同一人物のものだと露見する。受け取るときに分かれていたものを使うときに合わせてしまえば元の木阿弥だ。

まとめ

サイレントペイメントは、ビットコインのプライバシーで長く空いていた枠を埋める。「一度公開して何度も受け取る」という要求はこれまでプライバシーと両立できず、寄付団体や公開販売者は再利用アドレスを甘受するか決済サーバーを運用するかの二択を迫られていた。BIP-352は第三の選択肢を作った。

代償は正直に表示されている。受け取る側がスキャンの負担を負い、復元が遅くなり、まだウォレットの選択肢が狭い。タップルートがそうであったように、この種のプロトコルは有効化された日ではなく、ウォレットが静かに対応を追加していく数年のあいだに実際の効果を発揮する。Bitcoin Coreに受取機能が入る時点が、その曲線の変曲点になる可能性が高い。

今できることは二つある。公開アドレスを運用しているならspアドレスをフォールバックと併記してみること、そして誰かに送るときspアドレスが提示されたらそれを使うことだ。送る側の対応はすでに十分に広い。

---

関連記事:

• ビットコイン取引を追跡されないために
• CoinJoin（コインジョイン）
• ビットコインが静かに実行した史上最大のアップグレード
• ビットコインアドレスが1・3・bc1で始まる理由
• UTXOモデルを理解する