メインコンテンツへスキップ

Bitcoin Silent Payments 実践ガイド 2026 — 自分で実装して確かめた仕組みと使いどころ

·523 文字·3 分
Cora Aegis
著者
Cora Aegis
プライバシーは権利であり、目的そのもの。道具はそれを行使する手段にすぎません。
目次
短い銀髪と静かな赤い瞳の女性が、一つの光るアドレスが、互いにつながらない多数の取引出力へと扇状に広がっていくさまを見つめている

資金について: CypherpunkGuide には監視型の広告は載せていません。広告ネットワークも、追跡ピクセルも、記事広告もありません。資金は透明な流れで成り立っています——現在は読者の寄付、今後は subscription と編集方針に沿った affiliate です。私たちが向き合うのは広告主ではなく、読者です。

Bitcoin を受け取ろうとすると、小さく静かな矛盾に突き当たります。どのガイドも、アドレスを再利用してはいけないと説きます——再利用は、チェーン分析者にとって最もはっきりした手がかりの一つだからです。ところが、いざ支払いを受けたいとなると話は変わります。プロフィール欄の投げ銭アドレス、README に載せた寄付の一行、一度送って忘れてしまう請求書——こうした場面では、動かない、据え置きのアドレスが要ります。アドレスを回していくことと、変わらない受け取り先を持つことは、たがいに逆を向いているのです。

Silent Payments(BIP-352)は、この矛盾を解くプロトコルです。あなたが公開するアドレスは一つ。けれど、あなたに支払う人はそれぞれ、そこから別々のオンチェーンアドレスを導き出します。ですからチェーンを眺める第三者の目には、共通の宛先を持たない、互いに無関係な出力が並ぶだけです。これは、ここ数年で受信のプライバシーに起きた最も大きな変化の一つです。同時に、広く誤解され、ウォレットごとに中途半端にしか実装されておらず、そして——熱のこもった紹介記事がつい省いてしまう——現実の代償を抱えてもいます。

私は仮名で書き、手元のコインはどれも、すでに見られているものとして扱います。ですから、このプロトコルを鵜呑みにする気にはなれませんでした。このガイドを一文字も書き始める前に、私は BIP-352 を Python で一から実装しました——coincurve ライブラリ越しに libsecp256k1 を使っています——そして仕様書の公式テストベクターに通しました。結果は、送信 28サブケース中 28、受信 29サブケース中 29 が、1ビットの狂いもなく、200ミリ秒未満で一致しました(バンドルのログ)。以下は、その動く実装から見えたものです——何を守り、2026年にどのウォレットがそれを届け、そして頼りにする前に理解しておくべきスキャンの代償を、順に見ていきます。

謳い文句実際のところ落とし穴
「アドレス一つで、完全なプライバシー」アドレスは一つ、ただし守られるのは受信だけ金額も、あなたに送る相手も、手つかずのまま
「ミキシングの代わりになる」CoinJoin とは別の問題を解いている混ぜてはいない。再利用の結びつきを断つだけ
「公開したら、あとは忘れていい」公開はタダ。けれど受信はタダではない誰かが、あなたのコインを求めてチェーンをスキャンする必要がある
「いまはどのウォレットも対応済み」送信は当たり前。受信のほうが新しいウォレットごと・バージョンごとに、送信と受信を別々に確かめる

Silent Payment とは実際に何なのか(そして何を守らないのか)
#

**Silent Payment とは、BIP-352 が定める再利用可能な Bitcoin アドレスです。あなたが一度だけ公開する一つの文字列から、支払う側は、あなた宛ての一意で結びつけようのないオンチェーンアドレスを導き出せます。これが守るのは受信の結びつき——同じ相手に宛てた別々の支払いが、互いにひもづいてしまうこと——だけであって、ほかは何も守りません。**金額を隠すわけではなく、あなたに送る相手を守るわけでもなく、コインをあなたの名前に結びつけるオフチェーンの記録にも、手を出しません。

このアドレスは、二つの公開鍵——scan key(スキャン鍵)と spend key(支出鍵)——を一つにまとめて符号化したものです。メインネットでは sp1 で、テストネットでは tsp1 で始まります(人間が読める接頭辞は sp / tsp で、1 は bech32m の区切り文字にすぎません)。誰かがあなたに支払うとき、その人のウォレットは、自分の入力鍵とあなたの scan key を組み合わせて共有秘密を計算し、そこから、あなただけが見つけて使える新しい Taproot 出力を導き出します。二人の支払人が同じ出力を生むことはなく、結びつきを告げる「通知トランザクション」も存在しません——ここが、古い BIP-47 の payment-code 方式に対する決定的な改良点です。

何が守られずに残るのかは、はっきり言葉にしておく価値があります。この分野では、「プライベート」という一語が、実力以上の働きをさせられがちだからです。Silent Payments は受信のための道具です。受け取る金額は、いまもオンチェーンに見えています。支払う側のプライバシーは、あなたではなく、その人自身の課題です。そして、名前を持つ仮名に対する最も強い攻撃は、たいていチェーンそのものではありません——それは文章であり、メタデータであり、コインがパスポートと出会う KYC 取引所です。この足し算のモデルは、オンチェーン追跡が実際どう動くかと、チェーンの外側については AI による匿名性剥がしで描いたとおりです。Silent Payments が塞ぐのは、特定の、しかし価値ある一つの穴です。必要ではあっても、それだけで十分ではありません。

2026年、どのウォレットが Silent Payments に対応しているか
#

**対応は本物ですが、ばらつきがあります。そして最も役に立つ習慣は、送信受信を別々に確かめることです——両者は、別の時期に、別のウォレットで、ときに何年も離れて実装されてきたからです。**Silent Payment アドレスへ送ることは、いまや当たり前になりました。一方、そのアドレスで受け取れるようにするには、ウォレットがチェーンをスキャンしなければならず、こちらはより新しく、まだ数も少ないのが実情です。以下の表は 2026年7月9日時点の一次情報を反映しています。実際にお金を動かす前に、各プロジェクトのリリースノートで確かめてください。この一覧は、今後も更新されていきますから。

ウォレット送信受信備考(2026年7月9日時点)
Sparrow✅ v2.3.0(2025年10月)✅ v2.5.0(2026年5月)デスクトップで最も完成度が高い。ハードウェアウォレット署名は BIP-375 経由で v2.4.0(2026年2月)から。最新は v2.5.2
Cake Wallet一通りの機能を備えた初のモバイルウォレット(v4.18.0、2024年5月下旬)。スキャンは端末上で行う——その分、電池と同期時間の負担は重い
Bitcoin Core⏳ 未マージ⏳ 未マージ暗号処理の libsecp256k1 モジュールはマージ済み(PR #1765)。ウォレット層の対応は今も未決着(PR #35301 / #35302)

表が圧縮してしまった注意点が二つあります。一つ目。本当に大事なのは「受信」の行で、しかもそこが最も遅れて追いついてくる部分です——ウォレットは、あなた自身のアドレスを保有できるようになるよりずっと前から、友人の sp1 アドレスへ支払うことはできてしまいます。二つ目。ウォレットがどうスキャンするかは、単なる性能の話ではなく、プライバシーの選択です——これは続く二つの節の主題です。そもそも、こうして受け取るためのコインを、取引所で身元の結びつきを蒔かずに手に入れる方法については、KYC なしで Bitcoin を買うを参照してください。

送信——二つのうち、簡単に片づく方
#

**Silent Payment アドレスへの送信は、このプロトコルで手のかからない方です。送る側は作業をすべて手元で済ませ、何一つスキャンする必要がないからです。**対応したウォレット——デスクトップの手本は Sparrow です——では、受取人の sp1… アドレスを、ほかのアドレスとまったく同じように送金欄に貼り付けるだけ。あとはウォレットが、導出を目に見えないところで済ませます。

内部では、ウォレットは、いま使おうとしている入力の秘密鍵を取り、それを受取人の scan key と組み合わせて共有秘密を計算し、その秘密を使って、この支払い専用の使い捨て Taproot 出力アドレスを導き出します。導出があなたの入力を織り込むため、同じ受取人アドレスでも、別の人が——あるいはあなたの別のコインの組み合わせが——支払うたびに、オンチェーンには違う出力が生まれます。送る側が受取人から必要とするものは、公開されたアドレスのほかには何もありません。往復のやり取りも、通知も、対話もいりません。だからこそ送信側の対応が先に整い、いまでは当たり前になっているのです。この非対称こそが、次の節のすべてを語ります——送信が避けられる代償は、まさに受信には避けられない代償なのです。

受信——誰も警告してくれないスキャンの代償
#

**Silent Payments を受け取るには、ウォレットはブロックチェーン全体の候補となる出力を一つずつ調べ、それぞれをあなたの鍵と突き合わせて、あなた宛ての支払いを探し出さなければなりません——チェーン上には、ただ「引くだけ」で見つかるアドレスなど存在しないのです。**このスキャンの代償こそ、BIP-352 の中心にありながら、あまり語られてこなかった引き換えです。そして、ウォレットがそれをどう解決するかが、あなたの利便性とプライバシーの両方を決めます。アドレスの公開はタダです。そこへ何が送られたかを見つけるのは、タダではありません。

自分でフルノードを動かしているなら、スキャンはブロックデータに対する手元での計算です——重い処理ですが、プライベートです。何一つ自分のマシンの外へ出ないからです。厄介になるのは、ノードを持たずに、スマートフォンやノートパソコンで受け取りたいときです。そこで登場するのがインデックスサーバーです。Sparrow の場合、そのサーバーが Frigate(Silent Payments 用の Electrum サーバー、最新は v1.5.3)で、frigate.2140.dev に公開インスタンスがあります。ブラウザで「訪れる」ものではありません——HTTP ではなく Electrum プロトコルを話すからです。Sparrow では Preferences → Server → Public Server から選び、接続をテストします。

ここからが、調子のいいチュートリアルが飛ばす部分です。しかもこれは脚注ではなく、プライバシーの核心です。サーバーにあなたの代わりにスキャンさせるには、ウォレットはそのサーバーに、あなたの scan private key(スキャン秘密鍵)spend public key(支出公開鍵) を手渡します。Frigate がそう設計されているように、サーバーがそれらをメモリ上にしか保持しなかったとしても、悪意ある——あるいは侵害された——インデックスサーバーは、その鍵を使って、Silent Payments が第三者から隠すはずだったものを、そっくりそのまま復元できてしまいます。つまり、あなたが受け取った支払いの一覧すべてを、です。bennet.org の実践ガイドは、これをはっきりこう述べています——悪いサーバーは「Silent Payments が防ぐはずの、あなたの受信履歴の全体像を、そっくり組み上げられてしまう」。ですから、誠実に捉えるなら、これは白か黒かではなく、幅のある選択です。自分のノードは完全にプライベートで、その分だけ手間がかかる。公開インデックスサーバーは手軽で、その代わり、あなたの受信履歴について運営者を信用してくれと求めてくる。意識して選んでください。そして、見知らぬ他人のサーバーがあなたのスキャンを肩代わりしているときに、「自分は Silent Payments を使っているから」が、根拠のない安心に変わってしまわないように。

BIP-352 を、自分の手で再現してみた
#

**プライバシープロトコルを信頼する最も早い道は、それを実際に動かし、仕様書そのものが載せている数値と突き合わせることです。私は主張を鵜呑みにする代わりに、それをやりました。**私の一から書いた実装は、公式のテストベクター 57サブケースをすべて正確に再現します——送信 28/28、受信 29/29 です——完全なログとスクリプトはこの記事に同梱してあり(bip352-verification.txt)、あなた自身の手で再現できます。もっとも、通過した件数よりも役に立つのは、一件の支払いが一歩ずつ導き出されていくさまを、実際に眺めてみることです。

公開されたアドレスを一つ取り、送る側が何を計算するのかを追ってみましょう。以下の値は本物で、仕様書自身のテストベクターから取っています。

ステップ何を表すか値(短縮表記)
a送る側の入力秘密鍵の総和7ed265a6…56345f86
A対応する公開鍵の総和032562c1…dedc4bee
input_hash使う特定のコインを束ねるハッシュ5bfe5321…b7ad0668
ecdh双方が独立に導く共有秘密(input_hash · a · B_scan)028158af…3e14d80d
t₀tweak、hash(ecdh‖0)f438b401…c2e7eef6
outputB_spend + t₀·G(オンチェーンのアドレス)3e9fce73…de46e3c1

さて、ここからが、この仕組み全体を報われたものにする性質です。私はもう一人、独立した送り手を自分で組み立てました——鍵の材料は別、想定するコインも別のものにして——そして同じ公開アドレスへ支払わせました(ここではトランザクションは何も送信しません。先ほどのトレースと同じく、これは純粋な導出です)。その出力は 3f1dd702…879b98ad でした。二つの支払い、一つのアドレス、けれどオンチェーンでは、二つの出力は何も共有しません。共通のアドレスもなく、目に見える結びつきもありません。逆向きの計算を回して、両方を自分のものだと見分けられるのは、scan key を持つ者だけです。これが受信プライバシーの保証であり、しかもあなたは、それを言明として信じるのではなく、トレースの上で実際に成り立つさまを見て取れます。これは、Bitcoin のオンチェーンプライバシーで解剖した再利用の問題の、オンチェーン側の裏返しです——再利用が分析者にタダで手渡してしまうのと同じクラスタリングを、この導出は、まさに渡さずに握っておくのです。

つまずきどころ——multisig、ラベル、そして K_max の上限
#

**スキャンの代償のほかにも、Silent Payments があなたの環境に合うかどうかを分ける実装上の細部が三つあります——multisig との相性、ラベルの扱い、そして受け取れる出力数の上限です。そのどれもが、頼りにしたあとではなく、頼りにする前に知っておきたい類いのものです。**これらは、仕組みを解説する記事がめったに踏み込まない一角です。

  • **multisig と協調型トランザクションは、相性が難しい。**送る側が、使う入力の秘密鍵から支払いを導き出す以上、multisig(複数署名)ウォレットや CoinJoin——署名鍵が複数の当事者に分かれて持たれ、それらを単純に一つへまとめてはならない場——からの送信は、BIP-352 とはきれいに噛み合いません。Silent Payments が解くのは再利用の結びつきであって、混ぜる問題ではありません。金額とグラフのプライバシーが欲しいなら、それはいまも協調型トランザクションの領分で、オンチェーンプライバシーで扱っています。両者は、入れ替えられるものではなく、補い合うものとして捉えてください。
  • **ラベルは、非対称を抱えた便利機能です。**BIP-352 では、受け取る側が、一つのアドレスからラベル付きの派生形を導けます——どの出力がどこから来たのかを見分けるのに役立ちます。ラベルの情報が意味を持つのは、保有者であるあなたにとってだけで、オンチェーンには出ません。ただ、それはあなたが手元で付ける帳簿であり、ということは、侵害されたウォレットやバックアップが漏らしうる帳簿でもあります。便利さを、正直に見積もっておきましょう。
  • **受取人には上限があり、K_max = 2323 です。**仕様書(v1.1.0、2026年3月。現行は v1.1.1、2026年4月)は、一つのグループが導ける出力の数に上限を設けています——受け手のスキャン作業を膨れ上がらせようと細工されたトランザクションへの、防御としてです。個人として使うぶんには、まず届かない数字です——けれどこれが、素朴に「一つのアドレスへ 3,000 出力を支払う」が設計上はねられる理由であり、プロトコルの作者たちがスキャンの代償という攻撃を真剣に受け止めていたことを物語っています。

ライトクライアントについても、関連する現実確認を一つ。スキャンの問題は、まさにここでこそもう解決済みだと期待されがちだからです。2026年半ばの時点で、ただインストールすれば済むような、実運用に耐える、信頼を最小化したライトクライアントのツールは一つも存在しません。ウォレットデーモンの blindbitd は 2025年8月にアーカイブされました。今も活発に保守されているのは、対になるインデクサーの blindbit-oracle だけで、ライトクライアントの仕様もまだ策定の途中です。bdk-sp のような実験的なライブラリはありますが、作者自身がメインネットでの利用を戒めています。もしどこかのガイドが、スマートフォンでの Silent Payments 受信を、もう解決済みで引き換えのない体験であるかのように匂わせているなら、それはソフトウェアの実態を先取りしすぎています。

結論——Silent Payments は、もう使うべきか
#

**Silent Payments は、特定の価値ある仕事——再利用の結びつきを漏らさない、再利用可能な公開受取アドレス——には、もう十分こなせます。けれど、あなたの唯一のプライバシー道具になるにも、手間のかからないモバイルの既定になるにも、まだ早い。道具を仕事に合わせてください。そして、受信履歴が身の安全に関わるなら、自分のノードを動かしてください。**ここでの誠実な目標は、匿名性ではなく、よりよい受信プライバシーです。

あなたの状況判定どうするか
公開の投げ銭・寄付アドレス(発信者、プロジェクト、仮名)よく合うsp1… アドレスを一つ公開する。できるなら自分のノードでスキャンする
日常の受け取り、ノードは動かしている合うSparrow と自分のノード。完全にプライベートなスキャン
日常の受け取り、ノードなし、スマートフォン中心部分的公開インデックスサーバー経由なら使える——信頼の引き換えを受け入れるか、ライトクライアントを待つ
金額や送り手グラフのプライバシーが欲しい道具が違うSilent Payments はこれをしない。協調型トランザクションと Lightning を見てほしい
multisig / CoinJoin からの送信よく確かめて噛み合わせが難しい。まず自分のウォレットの対応を確かめる

どんな場合でも、順序はいつもと同じです。まず敵を名指しする。安上がりで、しかも取り返しのつかない結びつきから先に潰す——合法な範囲での KYC なしの入手、コインの扱いの基本、素のアドレスを二度と再利用しないこと。そのうえで、結びつけられたくない公開アドレスという特定の穴を、Silent Payments が塞ぐところに足していく。これは本物の前進です。同時に、スキャンの請求書がついて回る受信の道具でもあります。そしてその請求書を誰が払うのか——あなたか、それとも、あなたが信用するサーバーか——それこそが、プライバシーそのものと、プライバシーがある気がするだけの状態とを分ける差なのです。

よくある質問
#

Silent Payment のアドレスとは何ですか?
#

Silent Payment のアドレスとは、BIP-352 が定める再利用可能な Bitcoin アドレスで、一度だけ公開して使えます——メインネットでは sp1 で始まります。ふつうのアドレスと違い、支払う人はそれぞれ、そこから別々の使い捨てオンチェーンアドレスを導き出します。ですから、あなた宛ての支払いは、共有された結びつけ可能な宛先を持ちません。単一のスクリプトではなく、二つの公開鍵(scan key と spend key)を符号化したものです。

Silent Payments は、受け取る金額を隠しますか?
#

いいえ。Silent Payments が守るのは受信の結びつき——同じ相手への別々の支払いが、互いにひもづいてしまうこと——であって、それ以外は守りません。個々の支払いの金額は、いまも公開ブロックチェーンに記録されます。あなたに送る相手のプライバシーは変わりませんし、オフチェーンの記録(KYC 取引所など)も手つかずです。金額のプライバシーには、Lightning や協調型トランザクションが、その役目を担う道具になります。

2026年、どのウォレットが Silent Payments に対応していますか?
#

2026年7月9日時点で、Sparrow は送信(v2.3.0、2025年10月以降)と受信(v2.5.0、2026年5月以降)の両方に対応しています。Cake Wallet は、端末上でのスキャンにより両方に対応します(v4.18.0、2024年5月下旬以降)。Bitcoin Core のウォレット層の対応は、土台となる暗号モジュールこそ入ったものの、まだマージされていません。送信と受信の対応は、つねに別々に確認し、最新のリリースノートで裏を取ってください。

Silent Payment の受信は、なぜ遅いのですか?
#

チェーン上に、引くだけで見つかるアドレスがないからです。あなた宛ての支払いを見つけるため、ウォレットはブロックをまたいで候補の出力をスキャンし、それぞれをあなたの鍵と突き合わせなければなりません。自分のノードなら、これは手元での、プライベートな計算です。ノードがなければ、インデックスサーバーに頼ることになり、そのほうが速い代わりに、信頼の引き換えが生まれます。代償と信頼の両方を取り除くライトクライアントのツールは、まだ策定と開発の途中です。

公開サーバーを使っても、Silent Payments はプライベートなままですか?
#

部分的にしか、そうではありません。あなたの代わりにスキャンするため、公開インデックスサーバーは、あなたの scan private key と spend public key を受け取ります。メモリ上にしか保持しなかったとしても、その鍵があれば、悪意ある——あるいは侵害された——サーバーは、あなたが受け取った支払いの履歴すべてを再構成できます。それは、チェーンを見張る第三者に対して Silent Payments が防ごうとしている、まさにそのものです。自分のノードを動かせばこれを避けられますが、公開サーバーは、そのプライバシーを手軽さと引き換えにします。

#出典URLアーカイブ
1BIP-352 — Silent Payments(仕様書、v1.1.1)https://github.com/bitcoin/bips/blob/master/bip-0352.mediawikihttps://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
2Bitcoin Optech — Silent Payments のトピックhttps://bitcoinops.org/en/topics/silent-payments/https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
3Sparrow Wallet — リリース一覧https://github.com/sparrowwallet/sparrow/releaseshttps://web.archive.org/web/*/https://github.com/sparrowwallet/sparrow/releases
4Frigate — Silent Payments 用 Electrum サーバーhttps://github.com/sparrowwallet/frigatehttps://web.archive.org/web/*/https://github.com/sparrowwallet/frigate
5bennet.org — Silent Payments 実践ガイド(サーバーのプライバシー引き換え)https://bennet.org/learn/silent-payments-bitcoin-privacy/https://web.archive.org/web/*/https://bennet.org/learn/silent-payments-bitcoin-privacy/
6libsecp256k1 — Silent Payments モジュール(PR #1765、マージ済み)https://github.com/bitcoin-core/secp256k1/pull/1765https://web.archive.org/web/*/https://github.com/bitcoin-core/secp256k1/pull/1765

このサイトの三つの筋が、ここで交わります。Silent Payments は、Bitcoin オンチェーンプライバシー——追跡はどう動くかで解剖した再利用問題の、受信側の半分に答えるものです——クラスタリングに何が見えて、何が見えないのかは、そちらを読んでください。そして、アドレスのプライバシーは、そこへ受け取るコインのプライバシー止まりでしかありません。ですからこの記事は、身元の起点を上流で正す KYC なしで Bitcoin を買うと対にしてください。さらに、脅威はチェーンの上だけにとどまりません——AI による匿名性剥がしが、それらすべてと並行して走るオフチェーンの推論を扱っています。

関連記事