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
63
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
ランポート署名
azuchi
0
19
BitVM
azuchi
0
32
Replacement Cycling Attack
azuchi
0
37
Bitcoinのタイムロックの仕組み
azuchi
0
25
Inner Product Argument
azuchi
0
48
Codex32
azuchi
0
21
PSBT
azuchi
0
55
Trampoline Payment
azuchi
0
16
KZG Commitment
azuchi
0
160
Other Decks in Technology
See All in Technology
実務における脅威モデリングを考えよう
nikinusu
0
460
テスト”ケース”駆動開発 で手戻りをなくそう
ryohma0510
0
290
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
220
Creative UIs with Compose: DroidKaigi 2024
chrishorner
1
480
2024年のナビゲーション・フォーカス対応:Composeでキーボード・ナビゲーションをサポートしよう
tahia910
0
110
Oracle Autonomous Database:サービス概要のご紹介
oracle4engineer
PRO
1
7k
DevRelの始め方
moongift
PRO
1
380
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
130
eBPFのこれまでとこれから
yutarohayakawa
9
3.1k
Swift Testingのconfirmationを コードリーディング/Dive into Swift Testing confirmation
laprasdrum
2
250
やってやろうじゃないかメカアジャイル! / Let's do it, mechanical agile!
psj59129
1
600
社内の学びの場・コミュニティ形成とエンジニア同士のリレーションシップ構築/devreljapan2024
nishiuma
3
280
Featured
See All Featured
Happy Clients
brianwarren
96
6.6k
The Art of Programming - Codeland 2020
erikaheidi
48
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
322
23k
Unsuck your backbone
ammeep
667
57k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.6k
Pencils Down: Stop Designing & Start Developing
hursman
119
11k
How to Ace a Technical Interview
jacobian
274
23k
What's new in Ruby 2.0
geeforr
340
31k
Code Review Best Practice
trishagee
62
16k
Writing Fast Ruby
sferik
623
60k
Statistics for Hackers
jakevdp
794
220k
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分 • フルノードが必要で、軽量クライアントでは利用できない。