Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Silent Payment
Search
shigeyuki azuchi
March 21, 2023
Technology
0
72
Silent Payment
GBECの解説動画の資料です。
https://goblockchain.network/2023/03/silent-payment/
shigeyuki azuchi
March 21, 2023
Tweet
Share
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
4
BIP-374 離散対数の等価性証明
azuchi
0
19
BIP-353 DNS Payment Instructions
azuchi
0
36
OP_CAT and Schnorr Trick
azuchi
0
30
Pay to Anchorと1P1Cリレー
azuchi
0
32
プロアクティブ秘密分散法
azuchi
0
48
v3トランザクションリレー
azuchi
0
47
ランポート署名
azuchi
0
91
BitVM
azuchi
0
87
Other Decks in Technology
See All in Technology
dipにおけるSRE変革の軌跡
dip_tech
PRO
0
110
LLMでAI-OCR、実際どうなの? / llm_ai_ocr_layerx_bet_ai_day_lt
sbrf248
0
410
Tableau API連携の罠!?脱スプシを夢見たはずが、逆に依存を深めた話
cuebic9bic
2
180
Kiroから考える AIコーディングツールの潮流
s4yuba
3
590
Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して
os1ma
9
1.4k
ecspressoの設計思想に至る道 / sekkeinight2025
fujiwara3
12
2.3k
AI コードレビューが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった
mutsumix
0
140
東京海上日動におけるセキュアな開発プロセスの取り組み
miyabit
0
220
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
150
増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 / Confronting the Rise of Vulnerabilities: Sustainable Management Through Proactive Measures and Prioritization
nttcom
1
240
相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向
fujie
0
170
LIFF CLIとngrokを使ったLIFF/LINEミニアプリのお手軽実機確認
diggymo
0
150
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Bash Introduction
62gerente
613
210k
Navigating Team Friction
lara
188
15k
The Language of Interfaces
destraynor
158
25k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Side Projects
sachag
455
43k
Faster Mobile Websites
deanohume
308
31k
GraphQLとの向き合い方2022年版
quramy
49
14k
GitHub's CSS Performance
jonrohan
1031
460k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Transcript
Silent Payment
1 Silent Payment Bitcoinのアドレスを公開する際の課題 • 公開アドレスに対して、誰もが支払いできるため、公開アドレスの総受取額が分かる • アドレスの再利用による、プライバシーのリーク(各支払いのリンク)
Silent Payment アドレスは公開するものの、そのアドレス宛の支払いを識別不能にするRuben Somsenの提案 https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8
2 Silent Payment Address 公開アドレスを作成する受信者は、32バイトの公開鍵を Silent Payment Addressとして公開
P = xG 送信者は、 1. 支払いに使用するインプット(公開鍵 Q = yG)を選択 2. P' = H(yP)G + Pを導出し、この公開鍵宛に支払いを行う 受信者は、 1. ブロックチェーン上のトランザクションをスキャンし、 2. インプットの公開鍵に対してH(xQ)G + Pを計算し、 3. 計算結果の公開鍵がアウトプットにあれば、自身への支払いを検知 ※ ECDHによりyP = yxG = xQが成立 ※ インプットが違えば、異なるアドレスが導出される
3 Silent Paymentの利点と欠点 Silent Paymentの利点 • 送信者<->受信者間の対話が不要 • オンチェーンのフットプリントが通常の支払いと変わらない
ステルスアドレスやBIP-47(再利用可能なペイメントコード)では、 OP_RETURNや通知トランザクションなど、追加のフットプリントが発生する Silent Paymentの欠点 • UTXOセットのスキャン 現在のUTXOセットに対して、H(xQ)G + Xの計算がシングルコアで約220分 • フルノードが必要で、軽量クライアントでは利用できない。