One time verifiably encrypted signatures a.k.a. adaptor signatures

One-Time Verifiably Encrypted Signatures
A.K.A.
Adaptor Signatures
1
2020年9月30日
桑原一郎
https://github.com/cryptogarageinc/@CryptoGarageInc

2
桑原　一郎　Twitter:@1_LOW_0219
株式会社 Crypto Garage /Lead Researcher
ビットコインの技術リサーチおよび商品開発に従事。
趣味はダンス。
自己紹介

このセッションで話すこと
・2017年Scriptless scripts発表以降のスクリプトを使用しない
　支払い条件の構築プロトコル全般
・各プロトコルを代数の理論をなるべく触れずに解説
　(代数の部分は説明を割愛し「定理」として紹介)
3

このセッションで話さないこと
・楕円曲線暗号のベースとなる代数の話
　∈G、mod q、≡などの数式は記載しません、故に記載されている
計算式は厳密性に欠ける部分が存在します。
・各プロトコルの安全性証明
・各プロトコルの悲観ケース
　両者が協力的である楽観ケースのみ記載しています。
　実際はどちらかが協力しなかった場合のRefundのケースや
　片方が不正をした場合のPunishmentのケースが存在します。
・署名検証
署名交換の際に行う検証については一部記載を割愛しています。 4

・Claus Schnorr氏が考案
・2008年までパテントカバーされていた
・ECDSA（現状のビットコインで採用されている署名方式）は
　パテント回避するよう考案されていた
・Schnorr signaturesは以下の特性を兼ね備えている
ランダムオラクルモデルでの証明可能安全性
非展性
線形性
・現状Schnorr signaturesをビットコインの署名方式として採用する
　提案がここ数年活発化している
Schnorr signature
6

Motivation:スクリプトを使用した支払い条件の難点
・非効率（トランザクションのスペース、検証に時間がかかる）
・第三者が識別可能
→スクリプトを使用せずに支払い条件を設定できないか？
7

提案の歴史（今回話す提案内容）
schnorrECDSA
Layer1
Layer2
1. Scriptless Scripts(May. 2017,Andrew Poelstra)
Adaptor signatureを使用した支払い条件の設定の提案。Schnorrが前提。
2. Simple Schnorr Multi-Signatures with Applications to Bitcoin (2018,Gregory Maxwell, Andrew Poelstra, Yannick Seurin2,Pieter Wuille)
1.における安全なキーアグリゲーション(Mu-sig)の提案。
3. Scriptless Scripts with ECDSA(Apr. 2018,Pedro Moreno-Sanchez, Aniket Kate)
※Fast Secure Two-Party ECDSA Signing(2017,Yehuda Lindell)がベース
ECDSAベースでのScriptless scriptsの提案。
4.Anonymous Multi-Hop Locks(Apr. 2018,Pedro Moreno-Sanchez, Aniket Kate)
ペイメントチャンネル上でのAdaptor signature使用の提案。
5.Payment points without 2p-ECDSA or Schnorr(Oct. 2019,uSEkaCIO)
ECDSAベースでの3.よりシンプルなAdaptor signature使用の提案。
6.One-Time Verifiably Encrypted Signatures A.K.A. Adaptor Signatures (Oct. 2019 Lloyd Fournier)
1.~5.の総括およびセキュリティ検証。
1,23
4
5
8

Scriptless Scripts on Schnorr -マルチシグ編
99
schnorrECDSA
Layer1
Layer2
1,23
4
5

楕円曲線暗号
G :base point m:message(署名対象) H:Hash function
p :secret key P :public key(=pG)
r :random number R :random pointx_coordinate
(=rGx_coordinate
)
s :signature
※赤字は秘密情報
r,pを知っていればmに対する署名(s)が可能
R、Pを知っていればmに対する署名(s)の検証が可能
お題：共通のmに対して複数人がそれぞれのr,pを明かすことなく協力しあって共通のs
が作成できないか？(マルチシグ)
10

定義
G :base point m:message H:Hash function
r :random number R :random point (=rG) s :signature
Schnorr　signature計算式
s=r+H(R|P|m)p
rとpが線形方程式で使用されている。
2人がRとPが共通のものを作成できれば
別々のr,pで作成した署名を加算することで
共通の署名が作成可能
s1
=r1
+H(R|P|m)p1
←Alice署
名
s2
=r2
+H(R|P|m)p2
←Bob署名
s1
+s1
=r1
+r2
+H(R|P|m)(p1
+p2
) ←A&B署名
ちなみに・・・
ECDSA signature計算式
s=(H(m)+R⋅p)・r-1
r-1
が存在。2人がRとPが共通
のものを作成しても別々のr,p
で作成した署名は合算しても
署名として成立しない
11

Scriptless Scripts on Schnorr -マルチシグ編：RとPの作成方法
R=(r1
+r2
)G　P= (p1
+p2
)G
(r1
+r2
)G =R1
+R2
(p1
+p2
)G=P1
+P2
R1
,R2
,P1
,P2
を2者間で交換すれば実現(?)
Rogue key attack
Alice、Bobはお互いのpubkey(P1
,P2
)を交換し、共通のpubkey:Pを作成しようとしている。
Aliceは何かしらの手段でBobのP2
を把握。
Aliceは (P1
- P2
) を自分のpubkeyだとBobに偽申告（本当はP1
）
AliceとBobの共通pubkeyは (P1
- P2
) + P2
=P1
となる
AliceはP1
に対応するp1
を知っているので、A&Bの共通pubkeyだとBが思っているPは
実はAliceのPubkeyに他ならない
Aliceのsecretkeyp1
だけで署名ができてしまう(問題あり！)
→R1
,R2
,P1
,P2
の2者間交換では問題あり。Musigを使う
12

Scriptless Scripts on Schnorr -マルチシグ編：RとPの作成方法
R=(r1
+r2
)G　P= (p1
+p2
)G
(r1
+r2
)G =R1
+R2
(p1
+p2
)G=P1
+P2
R1
,R2
,P1
,P2
を2者間で交換すれば実現(?)
Rogue key attack
13
Party1が (P1
- P2
) を自分のPubkeyだと偽申告する問題が存在
→R1
,R2
,P1
,P2
の2者間交換では問題あり。Musigを使う
P1
-P2
Party1 Party2
P1
-P2
+P2
=P1
p1
知っている p2
知っている

Alice Bob
P作成 p1
, P1
(=p1
・G) p2
, P2
(=p2
・G)
P1
,P2
L=H(P1 ,
P2
)
pA
=H(L ,
P1
)p1
pA
G=PA
pB
=H(L ,
P2
)p2
pB
G=PB
PA
、PB
PA
+PB
=H(L ,
P1
)P1
+H(L ,
P2
)P2
= PAB
R作成 r1
, R1
(=r1
・G) r2
, R2
(=r2
・G)
R1,
R2
R =R1
+ R2
S作成 s1
=r1
+H(R,PAB
,m)・pA
s2
=r2
+H(R,PAB
,m)・pB
S = S1
+ S2
=r1
+r2
+H(R12
,PAB
,m)・(pA
+pB
)
Scriptless Scripts on Schnorr -マルチシグ編：Musig G :base point m:message H:Hash function
r :random number R :random point (=rG)
s :signature
共通のP作成時にハッシュ関数を入
れるのがポイント
H(L ,
P1
-P2
)(P1
-P2
)+H(L ,
P2
)P2
≠
H(L,P1
)P1
Rはシンプルな加算
Schnorr計算式
s=r+H(R,P,m)pと一致
作成順
14

Scriptless Scripts on Schnorr -マルチシグ編まとめ
Schnorr signature計算式
s=r+H(R|P|m)p
1.A、Bが共通のR、P、mについて合意
(Rogue Key Attack防止のためMusig利用)
2.Aサイン　sA
=rA
+H(R|P|m)pA
3.Bサイン　sB
=rB
+H(R|P|m)pB
3.サイン合算sAB
=sA
+sB
　　　　 =rA
+rB
+H(R|P|m)(pA
+pB
)
定義
t :tweak T :tweak point (=tG)
Schnorr signatureの計算式が成立
15

Scriptless Scripts on Schnorr -アトミックスワップ編
1616
schnorrECDSA
Layer1
Layer2
1,23
4
5

A B
Hash(secret)で1BTC ロック
(Bobはsecretが分かれば取得可能)
Hash(secret)で10LTC ロック
(Aliceはsecretが分かれば取得可能)
Aliceはsecretの値
を知っている
A B
Aliceはsecretをブロックチェーン上に公開し10LTCを取得
Aliceはsecretの値
を知っている
A B
BobはAliceがブロードキャストした情報
からsecretの値を取得
BobはAliceがブロードキャストした情報からsecretを取得。BTC
ブロックチェーン上にsecret公開し1BTCを取得
アトミックスワップ概要　※（注）Refundのケースは未記載
17

Alice Bob
Hash(secret)で自身のBTCをロック
ロック解除条件
・secret & Bobの署名(Bobへ)
Hash(secret)で自身のLTCをロック
・secret & Aliceの署名(Aliceへ)
secretとAlice署名をブロックチェーン上に公開して、 LTCを取
得(secretが公開される)
LTC上に記録された secretとBob署名をブロックチェーン上
に公開して、LTCを取得
通常のスクリプトを使用したアトミックスワップ　※（注）Refundのケースは未記載
ポイント：Aliceがトランザクションをブロードキャストするとsecretが明らかになり、Bobもトランザ
クションをブロードキャスト可能になる
問題点：アトミックスワップがされたことを第三者が調べることが可能(secretは同じ値なので紐付
けが可能)
secretはアリスのみ知っている値
18

お題：以下をみたす署名は可能か？
・Aliceがトランザクションをブロードキャストすると、
　Bobもトランザクションをブロードキャスト可能になる
・上記Alice,Bob間の紐付けが第三者は不可能
→Adaptor Signaturesを使用する。
19

Schnorr multi-signature
sAB
=sA
+sB
=rA
+rB
+H(R|P|m)(pA
+pB
)
Adaptor schnorr multi-signature
sAB
’=t+rA
+rB
+H(R|P|m)(pA
+pB
)
sAB
=sAB
’-t
=rA
+rB
+H(R|P|m)(pA
+pB
)
Adaptor signaturesは署名の際に一時的に有効な秘密情報tを混
ぜ込む(tweakさせる)手法。定義
このtがマルチシグのアトミックスワップで使用していたsecretの代わりとなる。
Adaptor Signatureがアトミックスワップで使用していたハッシュファンクションの代わりとなる。
rをtでtweakさせたうえで両者の署名を合算する。
当然このままでは署名として成り立たない。最終的
にtを除算する必要がある。
tを知っているパーティが tを除算し、署名sAB
完成。このトラン
ザクションがブロードキャストされると
tを知らないパーティも sAB
’ - sAB
= tを計算可能になる。
20

Adaptor Schnorr signatures作成手順
1.A、Bが共通のR、P、mについて合意(Musig利用)
※PはBTC用とLTC用それぞれ作成
2.AのBTCおよびBのLTCをそれぞれの共通Pで作成したマルチシグアドレスにロック
3.秘密の値tを知っているAliceが自分の署名にtでtweakしたAdaptor signature sA
’、T作成、連携
sA
’=t+sA
=t+rA
+H(R|P|m)pA
4.BobはsA
’、T検証後、Aliceから連携されたsA
’に自身の署名sB
を加算してsAB
’を作成、Aliceへ連携
sAB
’=sA
’+sB
(=t+sA
+sB
)
5.AliceはBobから連携された sAB
’からtを除算してLTC用の署名を完成させブロードキャスト
sAB
=sAB
’- t =rA
+rB
+H(R|P|m)(pA
+pB
)
6.Bobはブロードキャストされた情報からをt算出。LTC用の署名を完成させブロードキャスト
sAB
’ - sAB
=t
定義
Schnorr signatureの計算
式s=r+H(R|P|m)pが成立
21

Alice Bob
P、R
(Musig参照)
共通のPBTC
、PLTC、
Rを作成・共有
※PはBTC用、LTC用それぞれ作成
ロック BTCをPBTC
で作成したマルチシグアドレスにロック
・署名SBTC
（Bobへ）
LTCをPLTC
で作成したマルチシグアドレスにロック
・署名SLTC
（Aliceへ）
Adaptor signature作成・
共有・検証
s1
作成（Musig参照）
t、T(=t・G)作成
S’(Adaptor signature)=s1
+t
※実際はs1
、S’はBTC用、LTC用の２つ作成
T、S’BTC
、S’LTC
共有
S’BTC　、　
S’LTC
で同じTが使用されていることを検証
S’’LTC
共有 s2
作成（Musig参照）
S’’LTC
=S’LTC
+s2
S’’BTC
=S’BTC
+s2
※実際はs2
はBTC用、LTC用の２つ作成
S’’LTC
共有(=s1
+s2
+t) ※LTC用のみ
LTC取得 S’’LTC
- t =s1
+s2
= SLTC
署名SLTC
でLTCを取得
BTC取得 S’’LTC
- SLTC
= t
S’’ BTC
- t = SBTC
署名SBTC
でBTCを取得
Scriptless Scripts on Schnorr -アトミックスワップ編　※（注）Refundのケースは未記載
作成順
Sはまだ作らない
Aliceは自分の署名に、tを加算したAdaptor signatureを作成して
Bobヘ連携　　　※tはAliceのみ知る値
BobはAdaptor signatureに自分の署名を加算し
てAliceへ連携
Bobから連携された署名からtを減算。
署名完成＆ブロードキャスト
Aliceがブロードキャストした値からtを算出、署名完成＆ブロードキャスト
22

Scriptless Scripts on Schnorr -アトミックスワップ編まとめ
1. A、BはBTC、LTCをそれぞれマルチシグアドレスに送信するために共通のP、R作成
（Musig活用）
2. マルチシグアドレスにそれぞれのコインを送金しロックし、どちらか片方のみが
知っているtでtweakしたAdaptor signatureをBTC用、LTC用それぞれ作成
3. tを知るパーティーがコインを取得すると、ブロックチェーン情報から相手方も
Tを知ることができ、相手方もコインを取得できる仕組み
4. 秘密の値tは署名の中に含まれる（シングル署名にしか見えない）ので
第三者がアトミックスワップを識別することは不可能。
23

Scriptless Scripts on Schnorr -Lightning Network編
(Anonymous Multi-Hop Locks for Blockchain
Scalability and Interoperability)
2424
schnorrECDSA
Layer1
Layer2
1,23
4
5

Lightning Networkの仕組み　※（注）RefundおよびPunishmentのケースは未記載
問題点：第三者がブロックチェーン上のデータから A→B→C→DのLN支払いがあったことを判別可能。
(同じpreimageを使用しているので紐付け可能 )
AはHash(preimage)使用してロック BはHash(preimage)使用してロック CはHash(preimage)使用してロック
Preimage
知っている
Cはpreimageでロック解除
（Dがロック解除するとpreimage
が分かる）
Bはpreimageでロック解除
（Cがロック解除するとpreimage
が分かる）
Dはpreimageでロック解除
A B C D
25

A B C D AはEに0.9BTC支払おうとしている。
中間ホップのBとDが同一人物と仮定
A B C D
1.2 1.1 1.EがDにpreimageを明かして、
　Dから0.9BTC取得
A B C D
1.2
2. Dはあえて何もしない。
　一定時間経過後に C~D間はFail
A B C D
1.2 3. 2.からさらに一定時間経過後に
　B~C間もFail
preimage
知っている
問題点：Cの手数料がB(D)に渡ることになる(同じpreimageを使用しているのでB、Dの共謀可能)
Lightning Network(Worm Hole Attack)
1.1
1.0
1.0
1.0
AはHash(preimage)使用してロック
BはHash(preimage)使用してロック
CはHash(preimage)使用してロック
1.2 1.1 1.0
1.1
E
preimage
知っている
E
preimage
知っている
E
preimage
知っている
E
0.9
0.9
0.9
0.9
preimage
知っている
preimage
知っている
preimage
知っている
A B C D
1.2 4. Bはpreimageを知っているので、
　Aから1.2BTC取得
1.01.1
preimage
知っている
E
0.9
preimage
知っている
26
DはHash(preimage)使用してロック

・Danielがトランザクションをブロードキャストすると、
　Carolもトランザクションをブロードキャスト可能になる
・Carol、Bob間も同様
・Bob、Aliceも同様
・上記Alice,Bob,Carol,Daniel間の紐付けが第三者は不可能
　→この要件って・・・
27

・Aliceがトランザクションをブロードキャストすると、
　Bobもトランザクションをブロードキャスト可能になる
・上記Alice,Bob間の紐付けが第三者は不可能
→アトミックスワップとほぼ同じ。
　Adaptor Signaturesを使用する。
再掲
28

定義
RをT(=tG)でtweak
tを知らなくてもtweakができるのがポイント
tを加算することで署名が完成する
Schnorr multi-signature
sAB
=sA
+sB
=rA
+rB
+H(R|P|m)(pA
+pB
)
Adaptor schnorr multi-signature
sAB
’=rA
+rB
+H(R+T|P|m)(pA
+pB
)
sAB
=sAB
’+t =t+rA
+rB
+H(R+T|P|m)(pA
+pB
)
このtがpreimageの代わりとなる。
Adaptor Signatureがハッシュファンクションの代わりとなる。
29

Lightning Network(HTLCとPTLC) ※（注）RefundおよびPunishmentのケースは未記載
A~D間のそれぞれのロック条件に異なる値を使用するので、第三者による支払いの紐付けが不可能。
Worm Hole Attackも不可能。
AはHash(preimage)使用してロック BはHash(preimage)使用してロック CはHash(preimage)使用してロック
Preimage
知っている
Cはpreimageでロック解除
（Dがロック解除するとpreimage
が分かる）
Bはpreimageでロック解除
（Cがロック解除するとpreimage
が分かる）
Dはpreimageでロック解除
A B C D
A B C D
AはAdaptor sig(A+Z)
使用してロック
BはAdaptor sig(A+B+Z)
CはAdaptor
sig(A+B+C+Z)
※A=aG, B=bG, C=cG, Z=zG
b知っているa,b,c知っている c知っている z知っている
a+b+c知っている
Dはa+b+c+zでロッ
ク解除
Cはa+b+zでロック解除
（Cがロック解除するとa+b+zが分
かる）
Bはa+zでロック解除（Cがロック解除
するとa+zが分かる）
30
HTLC
PTLC

A B C
z生成
Z生成(=zG)
Z(invoice)
a,b,c,d生成
A,B,C,D生成(=aG,bG,cG,dG)
A+Z
b
ACK
a+b+c+d
Setup
Settle
ment
a+b+c+d+z
unlock(a+b+c+d+z)
z (Proof of Payment)
D
A+B+Z
c A+B+C+Z
d
Lightning Network(PTLC)シーケンス
ACK後にa+b+c+dを渡す
ことにより、AはUpdateが
スタックした場合にリトラ
イ可能(リトライによる二
重支払いを防止 )
E
A+B+C+D
lock(A+Z)
lock(A+B+Z)
lock(A+B+C+Z)
lock(A+B+C+D+Z)
a+b+c+d+z+-d
unlock(a+b+c+z)
a+b+c+z-c
unlock(a+b+z)A+b+z-b
unlock(a+z)
Update

Alice Bob
Update セットアップ a、b、c、d、Z(Emilyからもらう)
A、B、C、D(自身で生成)
b
P作成
（Musig参照）
PAB
pA
pB
各々のR作成 r1、
R1
(=r1
・G)作成 r2、
R2
(=r2
・G)作成
Tweak作成 A+Z (=a・G+Z)作成
共通Rを作成
A+Zでtweak
A+Z、R1
、R2
共有
RAB
=R1
+R2
+A+Z
ロック BTCをPAB
で作成したアドレスにロック
・署名SA+Z
（Bobへ）
Settle Adaptor
signature作成
s1
:r1
+H(RAB
,PAB
,m)pA
s2
:r2
+H(RAB
,PAB
,m)pB
s12
=s1
+s2
=r1
+r2
+H(RAB
,PAB
,m)・(pA
+pB
)
Signature完成
ブロードキャスト
Carolがブロードキャストした情報よりa+zを算出
s12
+a+z
=r1
+r2
+a+z+H(RAB
,PAB
,m)・(pA
+pB
)
=r1
+r2
+a+z+H(R1
+R2
+A+Z,PAB
,m)・(pA
+pB
)=SA+Z
SA+Z
を使用してロック解除
Bobがブロードキャストした情報よりzを算出
(Proof of payment)
SA+Z
- S12
- a =z
Scriptless Scripts on Schnorr -Lightning Network編(PTLC)
作成順
※（注）RefundおよびPunishmentの
ケースは未記載
32
G :base point m:message
H:Hash function p :secret key
P :public key(=pG) r :random number
R :random point (=rG)
s :signature

Scriptless Scripts on Schnorr -Lightning Network編(PTLC)まとめ
1. Musigを活用したマルチシグアドレスにコインをロックする手法はアトミックスワップ
とほぼ同じ
2. Adaptor signatureに必要となるtparty
は支払いをホップするユーザごとに異なる値になる
3. Payeeがをコインを取得するためにtA
を公開すると、取引に関連するホップユーザが
順々にtparty
取得（計算）可能になり、コインイン取得可能になる
4. 第三者による取引識別不可、中間ホップの共謀による手数料の略奪不可
5. rをtでtweakするのではなくRをT(=tG)でtweakさせることでtを知らないパーティによる
tweakが可能（クロスチェーンアトミックとは異なるTweak方法を用いる）
33

Scriptless Scripts on Schnorr まとめ
Schnorrがビットコインに導入された後には、複数者間の署名
の加算による合同署名が可能になる。
署名の加算を行う際には鍵のアグリゲーションが必須。安全
に行う施策としてMusigを使用する。
署名にTweakを混ぜ込んだAdaptor signatureをさらに利用
することでアトミックスワップやLightning Networkにも使用で
きる。
ただし、ビットコインへのSchnorrアダプションが前提。 34

Scriptless Scripts with ECDSA
Two-Party ECDSA
3535
schnorrECDSA
Layer1
Layer2
1,23
4
5

楕円曲線暗号
r,pを知っていればmに対する署名(s)が可能
Scriptless Scripts with ECDSA（Two-Party ECDSA）
お題：共通のmに対して複数人がそれぞれのr,pを明かすことなく協力しあって共通のs
が作成できないか？(マルチシグ)
36

定義
s=(H(m)+R⋅p)・r-1
r-1
が存在。2人がRとPが共通のものを作成しても別々のr,pで作成した署名は合算しても署名
として成立しない(署名の合算が不可能)
s1
=(H(m)+R⋅p1
)・r1
-1
←Alice署名
s2
=(H(m)+R⋅p2
)・r2
-1
←Bob署名
→加法準同型暗号（暗号化した状態で平文の加算が可能な暗号方式）Paillier暗号使用。
pを暗号化した状態で相手に渡し、暗号化した状態での署名を相手が作成し、
　その暗号化された署名を受け取って復号することで署名が完成する。
　 37

Alice Bob
P作成 p1
, P1
(=p1
・G)
r1
, R1
(=r1
・G)
p2
, P2
(=p2
・G)
r2
, R2
(=r2
・G)
P1
,P2
,R1
,R2
Alice ZKP（p1
, r1
,p2
,r2
をそれぞれが保持していることを証明、割愛）
共通のR作成
(DH鍵交換)
R = r1
・R2
=r1
・r2
・G R = r2
・R1
(=r1
・r2
・G)
p1
暗号化
共有
ckey = EncpkA
(p1
)
ckey
暗号化された
p1
を元に暗号
化された署名を
作成、共有
c1
=EncpkA
((r2
)-1
H(m)+ρq)
c2
=(ckey)⊙(p2
R(r2
)-1
)
c3
=c1
⊕c2
c3
=Encpk
((r2
)-1
H(m)+ρq+p1
p2
R(r2
)-1
)
暗号化された署
名を復号化して
署名完成
DEC(c3　
)・r1
-1
(mod q)
=(r1
r2
)-1
(H(m)+p1
p2
R)+ρq　(mod q)
=(H(m)+R・p1
p2
)・(r1
r2
)-1
(mod q)
作成順
ECDSA signature計算式と一致
s=(H(m)+R⋅p)・r-1
mod q 38
s :signature

Scriptless Scripts with ECDSA（Two-Party ECDSA）まとめ
ECDSAでは署名の単純合算が不可能なので、加法準同型
暗号（Paillier暗号）を使用し、pを暗号化した状態で相手に渡
して暗号化済の署名を完成作成。復号すると署名が完成。プ
ロトコルが複雑なのが難点。
39

Payment points without 2p-ECDSA or Schnorr
40
schnorrECDSA
Layer1
Layer2
3
4
5
1,2

ECDSAベースのscriptless scriptを2p-ECDSAよりシンプルなプロト
コルで実現する提案。
OP_CHECKMULTISIGを使用し、署名の合算は行わない。
各々の作成する署名を秘密の値tでtweakしたadaptor
signatureを作成する。
完全なscriptless scriptとは言えないが、秘密の値tはブロックチェー
ン上に記載されないので、取引の内容を完全に第三者が把握するこ
とは防ぐことができる。
41

定義
s=(H(m)+R⋅p)・r-1
Adaptor signature
s’= (H(m)+R⋅t⋅p)・r-1
= (H(m)+r⋅T⋅p)・r-1
s = s’・t-1
=(H(m)+R⋅t⋅p)・r-1
t-1
=(H(m)+R⋅t⋅p)・r-1
t-1
=(H(m)+R’⋅p)・r’-1
秘密の値tでRをtweak
乗算でtweakするのがポイント
r’=rt
R’=Rt
に変換、署名成立。
実際はr⋅Tでtweak。Tを知っていれば(tを知らなくとも)tweakできるの
がポイント
42

Alice Bob
マルチシグアドレス作成 p1
, P1
(=p1
・G) p2
, P2
(=p2
・G)
P1
、P2
のマルチシグアドレス作成（OP_CHECKMULTISIG使用）
Tweak作成 t, T (=t・G)
T
R1
をTweak　
r1
, R1
(=r1
・G)
R1
’ = r1
・T ( =R1
・t)
Adaptor signature
作成
マルチシグアドレスをインプットにBobのアドレスへ送金するトランザクションと
Adaptor signature作成。
sa
=(H(m)+R1
’ ⋅p1
)・r1
-1
離散対数等価性証明
(DLEQ)
Adaptor signature
連携
Aliceがr1
を知っていること、R1
とR1
’は同じ値r1
を元に作成されていることを証
明。(R1
=r1
G、R1
’ = r1
T)
証明：π
π、sa
離散対数等価性検証
(DLEQ)
署名S完成
πとsa
を検証して問題なければ、Adaptor
signatureにt-1
乗算して署名完成させ、ブロード
キャスト
S=sa
・t-1
=(H(m)+R⋅p1
)・r1
-1
・t-1
=(H(m)+r1
・t・G・p1
)・r1
-1
・t-1
=(H(m)+r1
・G・p1
)・r1
-1
=(H(m)+R1
・p1
)・r1
-1
t取得ブロードキャストされた情報からSを把握。sa
/Sでt取得
sa
/S=sa
/(sa
・t-1
)=t
R1
をtでtweakさせたR1
’を作成(tを知らなくと
も)tweakできるのがポイント
R1
であれば署名として完成なのだ
が、tweakさせたR1
’を使用している
のでこのままでは署名として成り立
たない。
DLEQについては次頁(PoDLE)参
照
ECDSA aignature計算式と一致
s=(H(m)+R⋅p)・r-1 43
SchnorrであればBobはP1
、R1
’、sa
を連携されれば署名
の検証が可能だったが、ECDSAでは検証不可能。
DLEQが必要。
s :signature

Alice Bob
マルチシグアドレス作成 p1
, P1
(=p1
・G)
r1
, R1
(=r1
・G)
R1
’ = r1
・T (=r1
・t・G)
p2
, P2
(=p2
・G)
π(DLEQ)作成 Aliceがr1
とRは同じ値r1
を元に作成
されていることを証明。
(R1
=r1
G、R1
’ = r1
T)
r2
R2
(=r2
・G)
R2
’ = r2
・Y (=r2
・y・G)
e=H(R2
,R2
’ ,R1
,R1
’ )
s=r2
+r1
e
π：(R1
,R1
’,R2
,R2
’,e,s)
π：(R1
,R1
’,R2
,R2
’,e,s)
π(DLEQ)検証 R2
=? sG−eR1
R2
’=? sY −eR1
’
e =? H(R2
||R2
’||R1
||R1
’ )
r2
、R2
、R2
’を新たに生成
Zero knowledge proof of discrete logarithm equality（PoDLE）
s :signature
Aliceはr1 ,r2を知っているのでsを計
算できる
(証明)
r2
G+(e・r1
・G) - (e・R1
)=R2
(証明)
r2
Y+(e・r1
・Y) - (e・R1
’ )=R2
’
44

Payment points without 2p-ECDSA or Schnorrまとめ
ECDSAベースのscriptless scriptを2p-ECDSAよりシンプルなプロト
コルで実現する提案。
OP_CHECKMULTISIGを使用し、署名の合算は行わない。
各々の作成する署名を秘密の値tでtweakしたadaptor
完全なscriptless scriptとは言えないが、秘密の値tはブロックチェー
ン上に記載されないので、取引の内容を完全に第三者が把握するこ
とは防ぐことができる。
Adaptor signature検証のために離散対数等価性証明（DLEQ）が必
要。
45

DLC ECDSA Adaptor signature
DLCはOP_CHECKMULTISIGを使用したAdaptor signatureを開発中。
AliceとBobはOP_CHECKMULTISIGを使用したマルチシグアドレスを作成。
マルチシグアドレスをインプットにした分配用のトランザクション（CET）に各自署名を行う。
Oracleの事前公開情報を元にTを作成し、各自作成したCETの署名をTでtweakさせ、Adaptor
signatureを作成し、交換。
署名に問題ないことを確認したのちにマルチシグアドレスに資金をロックする。
オラクルが契約満期にtを発表すると各々の作成したAdaptor signatureにt-1
を乗算することで
CETの署名が完成する。ブロードキャスト可能になる。
46

DLC ECDSA Adaptor signatureのメリット
・現状必要だった3トランザクション(FundTx,CET,ClosingTx)が
　2トランザクション(FundTx,CET)になる
・CETがAliceとBobが保持する内容が同じになる（従来の半分になる）
・識別がより難しくなる。
・Punishmentモデルの解消（常にブロックチェーンを監視する必要がなくなる）
47

Alice Bob
契約マルチシグアドレス作成（FundTx作
成）
p1
, P1
(=p1
・G) p2
, P2
(=p2
・G)
P1
、P2
のマルチシグアドレス作成（OP_CHECKMULTISIG使用）
Tweak作成 T (Oracleの情報より計算、次頁)
R1
をTweak　
r1
, R1
(=r1
・G)
R1
’ =R1
・t= r1
・T
Adaptor signature
作成
マルチシグアドレスをインプットにAlice、Bobそれぞれののアドレス
へ送金するトランザクションとAdaptor signature作成。
sa
=(H(m)+R1
’ ⋅p1
)・r1
-1
離散対数等価性証明(DLEQ)
Adaptor signature
連携
Aliceがr1
とR1
’は同じ値r1
を元に作成されてい
ることを証明。(R1
=r1
G、R1
’ = r1
T)
証明：πa
πa
、sa
検証 πとsa
を検証
Adaptor signature
作成、DLEQ
Aliceと同様、Adaptor signature、
DLEQ作成
検証 Bobと同様、πb
とsb
を検証
FundTxへお互い署名、ブロードキャ
スト
割愛
契約満期 t(Oracleが発表)
Settle 署名完成。ブロードキャスト（どちらが実施しても良い）
sa
/t =(H(m)+R1
’ ⋅p1
)・(r1
t)-1
= (H(m)+R1
’ ⋅p1
)・r1
’-1
sb
/t =(H(m)+R2
’ ⋅p2
)・(r2
t)-1
= (H(m)+R1
’ ⋅p1
)・r1
’-1
R1
をtでtweakさせたR1
’を作成
DLC ECDSA Adaptor signature
s :signature
Alice、BobそれぞれがOracleの情
報を元にTweakを行いAdaptor
ECDSA signature計算式と一致
s=(H(m)+R⋅p)・r-1
DLEQについては前頁(PoDLE)参
照
DLEQについては前頁(PoDLE)参
照
※（注）Refundのケース
は未記載
48

DLC ECDSA Adaptor signature T 、tの計算方法
Oracle secret key ：pO
Oracle Public key ：PO
(=pO
・G)
Oracle random number ：rO
Oracle random point ：RO
(=ro
・G)
イベント結果　　：m
T = Ro
+ H(Ro
,P,m) PO
#Alice と BobはOracle公開情報から計算可能
t = ro
+ H(Ro
,P,m) pO
#Oracleだけが計算可能
T=t・Gが成り立っている
49
s :signature

まとめ（提案の歴史）
schnorrECDSA
Layer1
Layer2
1. Scriptless Scripts(May. 2017,Andrew Poelstra)
Adaptor signatureを使用した支払い条件の設定の提案。Schnorrが前提。
2. Simple Schnorr Multi-Signatures with Applications to Bitcoin (2018,Gregory Maxwell, Andrew Poelstra, Yannick Seurin2,Pieter Wuille)
1.における安全なキーアグリゲーション(Mu-sig)の提案。
3. Scriptless Scripts with ECDSA(Apr. 2018,Pedro Moreno-Sanchez, Aniket Kate)
※Fast Secure Two-Party ECDSA Signing(2017,Yehuda Lindell)がベース
ECDSAベースでのScriptless scriptsの提案。
4.Anonymous Multi-Hop Locks(Apr. 2018,Pedro Moreno-Sanchez, Aniket Kate)
ペイメントチャンネル上でのAdaptor signature使用の提案。
5.Payment points without 2p-ECDSA or Schnorr(Oct. 2019,uSEkaCIO)
ECDSAベースでの3.よりシンプルなAdaptor signature使用の提案。
6.One-Time Verifiably Encrypted Signatures A.K.A. Adaptor Signatures (Oct. 2019 Lloyd Fournier)
1.~5.の総括およびセキュリティ検証。
1,23
4
5
50

本資料で触れていないその他の提案
1. SuccinctAtomicSwap(Apr. 2020,RubenSomsen)
Adaptor signatureを使用したよりシンプルなアトミックスワップの提案。
　Refundの条件のためのタイムロックが片方のチェーンのみで実現可能になる。
2. Generalized Bitcoin(Aug. 2020,Lukas Aumayr, Oguzhan Ersoy, Andreas Erwig, Sebastian Faust , Kristina Hostakova´ , Matteo Maffei , Pedro Moreno-Sanchez, Siavash Riahi, et al)
Adaptor signatureを使用したペイメントチャンネルの提案。
　古い状態の決済用トランザクション(Commitment Tx)がブロードキャストされた場合の
RevocationをAdaptor signatureを用いて実現。
3. Mu-sig DN(Sep. 2020,Jonas Nick, Tim Ruffing , Yannick Seurin, and Pieter Wuille)
Mu-sigの提案の改良版。署名ラウンドの際に双方が新しいrandom numberを生成しているか
　（古いrandom numnerを使いまわしていないか）確認する提案。
51

Reference
https://github.com/ElementsProject/scriptless-scripts
https://eprint.iacr.org/2018/068.pdf
http://diyhpl.us/~bryan/papers2/bitcoin/Scriptless%20scripts%20with%20ECDSA%20-%202018-04-26.pdf
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
http://diyhpl.us/~bryan/papers2/bitcoin/One-time%20verifiably%20encrypted%20signatures%20AKA%20a
daptor%20signatures%20-%202020.pdf
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
52

One time verifiably encrypted signatures a.k.a. adaptor signatures

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a One time verifiably encrypted signatures a.k.a. adaptor signatures

Semelhante a One time verifiably encrypted signatures a.k.a. adaptor signatures (11)

Último

Último (9)

One time verifiably encrypted signatures a.k.a. adaptor signatures