1.
Discreet Log Contracts(DLC)
を読む
Takaya Imai
Co-founder and CTO@United Bitcoiners Inc.
CEO@Frontier Partners LLC
暗号通貨読書会／勉強会@富士ソフト株式会社
Aug/21/2017

2.
自己紹介
• United Bitcoiners Inc. 共同創業者＆取締役CTO
• フロンティアパートナーズ合同会社 代表CEO
• マスタリングビットコイン、翻訳者代表
• 2016/7/14出版、現在第８刷
• 電子書籍版(kindle)も
• オープンエディション版
• https://www.bitcoinbook.info

3.
自己紹介
• バックグラウンド
• 新潟大学大学院 素粒子理論物理 博士(理)
• カカクコム
• 検索エンジン開発 検索サーバクラスタ構築運用 大規模データ処理 機械学
習 画像認識
• データタワー株式会社 代表取締役
• 株式会社ブロックチェーンハブ 技術アドバイザー

4.
https://adiabat.github.io/dlc.pdf

5.
今までの主な予測市場実装
• Ethereumベース
• Augur
• Gnosis
• Sidechainベース
• Hivemind (Truth coin)

6.
Augur Gnosis Hivemind DLC
Oracleをどう
するか
分散型
Gnosisが
選んだ専門家
分散型＆マイ
ナー
匿名の
ボランティア
(discreet)
プラットフォ
ーム
Ethereum Ethereum Sidechain
Bitcoinおよび
類似物
取引参加者数 多数 多数 多数 二者間

7.
先に注意点
• 暗号技術では枯れた技術、枯れたツールのみを使う
べきです。
• DLCではSchnorr署名を元の形とは違った形で使用
しています。
• この方法はまだ研究レベルであり、欠陥が存在する
可能性がある点に注意してください。

8.
モデル

9.
多者間取引
Oracle
Augur等

10.
Alice Bob
Olivia
二者間取引
Oracle
DLC
Lightning Network
双方向チャネルのような

11.
Oracle
DLC

12.
署名Rの公開

13.
署名Rの公開
• Schnorr署名(オリジナル)
• 参考: 日向さんの説明
• https://blog.visvirial.com/articles/721

14.
署名Rの公開
• Schnorr署名(楕円曲線上の離散対数問題)
• 記述法
• G: 採用する楕円曲線のベースポイント
• n: Gの位数
• m: 署名対象メッセージ
• a: 秘密鍵(整数)
• H(x;y): ハッシュ関数(x, yを連結してハッシュ値を計算する)
• 署名作成
• 乱数kを選ぶ([1,n-1])
• R = kG mod n
• s = k - H(m ; R)a mod n
• 署名検証
• e = e’ ?
• e = H(m ; R) mod n
• e’ = H(m ; sG + eaG) mod n

15.
署名Rの公開
• 通常、(R, s)をメッセージmに対する署名とする。
• DLCでは、R, sGをOliviaの公開鍵、sを秘密鍵のよ
うに扱う。
• これは、予測を始める前に決めたOracleだけが予測
結果を開示できるようにするため。

16.
乱数kは毎回使い捨てること
• kを使いまわすと、Oliviaの秘密鍵aがわかってしまします。
• 記述法
• m: 1度目の署名対象メッセージ
• m’: 2度目の署名対象メッセージ
• aの導出
• s’ = k - h(m ; kG)a
• s = k - h(m’ ; kG)a
• s - s’ = - h(m ; kG)a + h(m’ ; kG)a = (- h(m ; kG) + h(m’ ; kG))a
• a = (s - s’) / (- h(m ; kG) + h(m’ ; kG))

17.
コントラクトの作成
• まずAliceは取引条件の合うBobを見つけ、互いに条件に合
意する
• 例えば、水曜日に予測をし、次の金曜日(delivery day)に取
引を実行する。
• コントラクトを作成し始めるために、まずfunding txが必
要
• funding txのアウトプットに紐付けて、Contract Execution
Transaction(CET)を作成する

18.
funding tx
コントラクトの作成
input
Alice
5btc output
Alice & Bob
10btc
Alice BobBlockchain
input
Bob
5btc
signed
send

19.
funding tx
コントラクトの作成
input
Alice
5btc output
Alice & Bob
10btc
Alice BobBlockchain
input
Bob
5btc
funding tx
input
Alice
5btc output
Alice & Bob
10btc
input
Bob
5btc
signed
send

20.
コントラクトの作成
Alice BobBlockchain
CET for Bob
output
Bob or Alice
6btc
input
Alice & Bob
10btc
output
Alice
4btc
CET for Alice
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
signed signed
send
send
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob

21.
コントラクトの作成
Alice BobBlockchain
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob
CET for Bob
output
Bob or Alice
6btc
input
Alice & Bob
10btc
output
Alice
4btc
CET for Alice
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc

22.
コントラクトの作成
Alice BobBlockchain
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob
CET for Bob
output
Bob or Alice
6btc
input
Alice & Bob
10btc
output
Alice
4btc
CET for Alice
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
broadcast

23.
コントラクトの作成
Alice BobBlockchain
funding tx
input
Alice output
Alice & Bob
10btcinput
Bob
CET for Bob
output
Bob or Alice
6btc
input
Alice & Bob
10btc
output
Alice
4btc
CET for Alice
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc

24.
CETの中身
CET for Alice
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
Pub_Ai or (Pub_Bob and TimeDelay(absolute))
Pub_Ai = Pub_Alice + s_i G
s_i G = R - h(i, R)V

25.
CETの中身
• TimeDelayを設けているのは、delivery dayが来る
前に一方的にCETをブロードキャストをできないよ
うにするペナルティーのため(いたずらに相手の資
金をロックしてしまうことがないように)。
• これをすると、funding txに入れた資金を全て相手
に取られてしまう。

26.
多様な予測
• 水曜日の終値が1円=1000satoshiでした。
• 次の金曜日の終値はいくらになるでしょうか？
• 例として、２択
• 1円=1050satoshi
• 1円=950satoshi

27.
多様な予測
Alice BobBlockchain
funding tx
CET for Bob(1050)
input
Alice & Bob
10btc
output
Alice
4btc
CET for Alice(1050)
output
Alice(1050satoshi) or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
output
Bob(1050satoshi) or Alice
6btc
CET for Bob(950)
input
Alice & Bob
10btc
CET for Alice(950)
output
Alice(950satoshi) or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
output
Bob(950satoshi) or Alice
6btc
output
Alice
4btc
… …

28.
Alice
Bob
上がる
下がる
CET for Alice
(1050)
output
Alice(1050satoshi) or
Bob
input
output
Bob
CET for Bob
(1050) output
Bob(1050satoshi) or
Alice
input
output
Alice
CET for Alice
(950)
output
Alice(950satoshi) or
Bob
input
output
Bob
CET for Bob
(950) output
Bob(950satoshi) or
Alice
input
output
Alice
日本円が
4btc
6btc
6btc
4btc
下がる
上がる
6btc
4btc
4btc
6btc

29.
多様な予測
CET for Alice
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
Pub_Ai or (Pub_Bob and TimeDelay(absolute))
Pub_Ai = Pub_Alice + s_i G
s_i G = R - h(i, R)V
1050
1049
1048
…
951
950

30.
ところで、
BitcoinのオンチェーンTXだけでは
DLCのようなことはできないのだろう
か？

31.
• HTLCのようにpreimageとpreimage hashを使っても可能。
• ただし、Yes or Noなど２択のシンプルなものでないとTXデー
タサイズが大きくなりすぎて実用上無理。
• Schnorr署名を本来とは違った形で使うことで、Oracleは予測
分の数のpreimage hashを全て公開する必要はなくRのみを公
開すれば良い。
• オフチェーンとして構成することで、外部からは個々の二者間
でどんな取引をしているかを隠すことができる(discreet)。

32.
Oracleによる署名とその公開
• Oliviaは金曜日の終値を調べて、以下の計算式で得られた署名を
公開する。
• s_1050 = k - h(1050, R)v
• s_1050が公開されると、以下に従って公開鍵Pub_A1050と
PubB1050にそれぞれ対応する秘密鍵Priv_A1050, Priv_B1050が
わかり、CETを適切にブロードキャストできるようになる。
• Priv_A1050 = Priv_Alice + s_1050
• Priv_B1050 = Priv_Bob + s_1050

33.
Oracleによる署名とその公開
• Oracleの仕事は以下だけ
• 署名Rを予測をする前に公開すること
• 事実をメッセージとする署名sを計算して公開す
ること

34.
CETの実行
• Priv_A1050, Priv_B1050がわかったので、勝者は
CETのうち1050satoshiについてのTXを一方的にブ
ロードキャストしてプラスの資金を得ることができ
る
• このとき、Pub_*1050が入っている側のアウトプ
ットをすぐに使用すること。TimeDelay後にはそ
こにロックされている資金を相手に奪われてしま
うので。

35.
CETの実行
• しかし、これは非協力的なCETの実行。
• 協力的なCETの実行の方がより安価で効率的。
output
Alice or Bob
6btc
input
Alice & Bob
10btc
output
Bob
4btc
output
Alice
6btc
input
Alice & Bob
10btc
output
Bob
4btc
非協力的 協力的

36.
Oracleに対するリスク
• Oliviaが嘘に基づいた署名sを公開したらどうするの
か？
• 意図的かどうかに関わらず、嘘かどうかの検知は
可能。DLCユーザはOliviaをOracleとして使わな
くなる。
• ただ、Oliviaが匿名ボランティアだとすると、こ
れによって失うことはなんだろうか？

37.
Oracleに対するリスク
• Oliviaが複数の署名sを公開したらどうするのか？
• 複数の署名sが公開されると、そこからOliviaの秘
密鍵aおよび乱数kがわかってしまう。これによっ
て、乱数kに基づく任意のCETが実行可能になって
しまい公平でなくなるため、誰もOliviaをOracleと
して使わなくなる。
• ただ、Oliviaが匿名ボランティアだとすると、これ
によって失うことはなんだろうか？

38.
Oracleに対するリスク
• Oliviaが実はAliceまたはBobだったら？
• この場合、AliceまたはBobは署名sを公開すること
なく事実に関わらずCETを実行できる。つまり、
不正な取引を使って相手から資金をだまし取るこ
とができる。この場合、OliviaをOracleとして使わ
なくなる。
• ただ、Oliviaが匿名ボランティアだとすると、これ
によって失うことはなんだろうか？

39.
Oracleに対するリスク
• Oliviaが事実を公開する前にいなくなったら？
• delivery dayより十分あとに双方に元の資金を払
い戻せるようなrefund txを、funding txをブロー
ドキャストする前に作って共有しておく。

40.
Oracleに対するリスク
Multi-Oracle
• 複数のOracleを事前に採用し、Oracleへのリスク(Oliviaが実はAliceだった
)を部分的に減らすことはできる。
• このようにPub_Aiを作る。
• Pub_Ai = Pub_Alice + s_i1 G + s_i2 G + …
• ただし、以下が問題となる。
• Oracle1が1円=1050satoshi、Oracle2が1円=1049satoshiと報告したら
、取引は成立しない。
• 払い戻しされるようにあらかじめ作っておけば問題ないが、これが起き
ないようにあらかじめルールを決めておかないといけない。

41.
今後の課題

42.
コントラクトの更新
• AliceとBobの間取引を始めた。しかし、今の価格の流れがBobに悪い方向に流れ
ている。
• このため、Bobはこの取引から降りたいと思っている。
• しかし、Carolは流れが変わり、Bobに良い流れになると考えた。
• CarolはBobと交渉をし、この取引を引き受けることを提案しBobは了承した。
• 途中から取引の当事者をBobからCarolに変えるにはどうしたらよいだろうか？
• 単に、別途Bob <-> Carol間の取引を開始し、Bobが損害を受けたらCarolは
Bobに指定金額を支払う、Bobが儲かったらBobはCarolに指定金額を支払うと
いうことにしては？

43.
非中央集権的マッチング
• 予測の取引を始めるにあたって、事前にAliceとBob
をマッチングしないといけない。
• この部分をフェアな非中央集権的なものにするには
どうしたらよいだろうか？

44.
長期的な取引
• delivery dayが1年に１回あるような比較的長期的な
場合、匿名ボランティアが忘れたりしないだろうか
？
• 機械的に公開するようにしておくことは可能だが
、もしうまく稼働しなかった場合に匿名ボランテ
ィアに責任は問えない。

45.
Multi-Oracleと
Pedersen Commitment
• Multi-Oracleにする際に、Pedersen Commitmentで
以下のようなことを実現できないか？
• 10人のOracleのうち、7人が1050satoshi、3人が
1049satoshiの署名を公開した。
• 70%以上のOracleが提示した価格をMulti-Oracle
が提示した価格として、CETを実行する。

46.
Questions?

47.
References
• https://adiabat.github.io/dlc.pdf
• http://techmedia-think.hatenablog.com/entry/2017/07/08/181338
• Prediction Market Implementations
• https://augur.net
• https://gnosis.pm
• http://bitcoinhivemind.com
• https://joemphilips.github.io/Truthcoin_test/Truthcoin_memo.html
• Schnorr Signature
• https://blog.visvirial.com/articles/721
• Pedersen Commitment
• https://blockstream.com/bitcoin17-final41.pdf