論文紹介『ビットコイン P2P電子通貨システム』

山本遼

チームラボ勉強会 2016/11/24

この発表は？

● ビットコインの論文‐ Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic

Cash System," 2009

● 和訳している人がいたのでそちらを読んだ‐ http://kogarashi.net/pitchblende/bitcoinwhitepaper

2

目次

● 準備１：ハッシュ値とは

● 準備２：暗号とデジタル署名

● ビットコインの取引データ構造

● 受金確認

● ２重取引とブロックチェーン

● 参考資料

3

準備１：ハッシュ値とは

4

ハッシュ関数

● 任意の入力文字列から、固定長の文字列（ハッシュ値）を生成

● 入力文字列が少しでも変わると、全く別の文字列になる

● 同じ出力になる別の入力は、総当たりで探すしかない

‐ 出力長が長くなると現実的には不可能になる

● アルゴリズムは世界的に共有（MD5, SHA2など）

5

ハッシュ関数による通信誤り検出

● 文書を通信する時、途中のデータが欠けていないかどうかを

確認したい

● 文書と、文書のハッシュ値をあわせて送る

● 受信者は受信文書のハッシュ値と、受信ハッシュ値を

比較して、同じになれば通信誤りはない

文書

文書のハッシュ値

6

準備２：暗号とデジタル署名

7

基本的な暗号（共通鍵暗号）

● 性質

‐ ある鍵で任意のデータを暗号化したり、復号したりする

‐ 通信に使う場合は、どうやって鍵を送るかが問題

鍵A 鍵AHello 8Xgu1d.. Hello

8

公開鍵暗号

● 性質

‐ 鍵D（Decrypter:復号鍵） と鍵E（Encrypter:暗号鍵） をペア

で生成

‐ 鍵E で任意のデータを暗号化し、鍵D で復号できる

‐ どちらの鍵も、その他の情報から推測することはできない

‐ 大きな数の素因数分解が難しい性質を利用

鍵E 鍵DHello 8Xgu1d.. Hello

9

公開鍵暗号による暗号化通信

● 暗号化通信

‐ 受け手が鍵のペアを生成

‐ 秘密鍵D は受け手のみが持つ

‐ 公開鍵E を相手に渡す

‐ 相手は 公開鍵E で暗号化したデータを受け手に送る

‐ 受け手は 秘密鍵D で復号してデータを読む

● 暗号化したデータや 公開鍵E が流出してもデータは安全

‐ どうやって鍵を送るか問題は起こらない

● SSLの通信(HTTPS, SSHなど)で日常的に使われる

公開鍵E 秘密鍵DHello 8Xgu1d.. Hello

10

デジタル署名

● データが署名者のものであること（認証）と、

改ざんされていないこと（完全性）を保証する仕組み

‐ 署名者が鍵のペアを生成

‐ 公開鍵D を一般公開する

‐ 秘密鍵E を署名者のみが持つ

‐ データのハッシュ値を、秘密鍵E で暗号化した署名を

データに添えて送る

‐ 受信者は、署名を 公開鍵D で複合した値と

データのハッシュ値が同じかどうかで正当性を確認できる

● HTTPSのサイト証明書などに使われる

11

デジタル署名

E

D 公開

文書X

Xのハッシュ値

暗号化した

Xのハッシュ値

文書X

暗号化した

Xのハッシュ値

これをデジタル署名と呼ぶ

送信デジタル署名を送信者の公開鍵Dで複合し、文書のハッシュ値と等しくなれば、確かに送信者が送った文書だと言える

12

デジタル署名まとめ

● 誰でも、秘密鍵Eを漏らさず、公開鍵Dを公開することで

任意の文書の正当性を証明できる

‐ 作成者が本人であること（認証）

‐ 改ざんされていないこと（完全性）

13

ビットコインの取引データ構造

14

前提とするネットワークインフラ

● 大量のデータが拡散されるP2Pネットワーク

● 誰が放流したデータも、そのうち全ノードにいきわたる

● 検索によって流れているデータを取得できる

● ビットコイン取引をする人は、このネットワークに接続する

15

0. 各ユーザーは公開鍵と秘密鍵を持つ

山本E山

D山

公開鍵口座番号として使う

秘密鍵署名に使う

中野E中

D中

喜多E喜

D喜

16

1. 山本が 5BTC 持っている

INPUT…

OUTPUT5BTC：山本口座

この取引データがインターネットに出回っていると、山本口座Aには 5BTC 入っているということになる

山本E山

D山

公開鍵口座番号として使う

秘密鍵署名に使う

中野E中

D中

喜多E喜

D喜

D山

17

2. 山本が中野に 5BTC 送る

INPUT

OUTPUT5BTC：中野口座

INPUT…

OUTPUT5BTC：山本口座

この取引データがインターネットに出回っていると、山本口座Aに入っていた 5BTC は中野口座Bに入っていることになる

山本E山

D山

公開鍵口座番号として使う

秘密鍵署名に使う

中野E中

D中

喜多E喜

D喜

D山

D中

署名山

18

INPUT

OUTPUT5BTC：喜多口座

3.中野が喜多に 5BTC 送る

INPUT

OUTPUT5BTC：中野口座

INPUT…

OUTPUT5BTC：山本口座

この取引データがインターネットに出回っていると、その 5BTC は喜多口座に入っていて、山本や中野の口座には入っていないことになる

山本E山

D山

公開鍵口座番号として使う

秘密鍵署名に使う

中野E中

D中

喜多E喜

D喜

D山

署名山

D中

D喜

署名中

19

実際には取引データのハッシュでINPUTを参照

取引AINPUT

…OUTPUT

5BTC：山本口座

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

取引CINPUT

取引Bのハッシュ値OUTPUT

5BTC：喜多口座

誰か → 山本 山本 → 中野 中野 → 喜多

D山

署名誰

か

D中

署名山

D喜

署名中

20

複数のINPUTをマージして送金

取引AINPUT

...OUTPUT

5BTC：山本口座

取引BINPUT

...OUTPUT

5BTC：山本口座

取引CINPUT

取引Aのハッシュ値取引Bのハッシュ値

OUTPUT8BTC：中野口座2BTC：山本口座

誰か → 山本 (5BTC) 誰か → 山本 (5BTC) 山本 → 中野 (8BTC)

D山

署名誰

か

D山

署名誰

か

D中

署名山

D山

21

取引AINPUT

...OUTPUT

5BTC：山本口座1

取引BINPUT

...OUTPUT

5BTC：山本口座2

取引CINPUT

取引Aのハッシュ値取引Bのハッシュ値

OUTPUT8BTC：中野口座12BTC：山本口座3

誰か → 山本口座1 (5BTC)

誰か → 山本口座2 (5BTC)

山本 → 中野 (8BTC)

D山1

署名誰

か

D山2

署名誰

か

D中1

署名山1

D山3

署名山2

複数の口座を使い分けるのも自由

取引ごとに別の口座を作って匿名性を上げることが可能。

むしろ取引ごとにどんどん新しい口座を作ることが推奨される。● 新しい口座を作る = 新しく鍵ペアを作り、秘密鍵を保管する● 残高０の口座（支払い済みの口座）の秘密鍵は捨てていい

ただし同じ取引の INPUTで複数口座を使うと、同一主体だとわかる。

22

山本E山1D

山1

公開鍵口座番号として使う

秘密鍵署名に使う

D山2 E

山2

D山3 E

山3

基本的なビットコイン取引

● 各人が公開鍵（口座番号）、秘密鍵（署名用）を持つ

● 送金者は、

自分の口座への入金取引データのハッシュ値と

相手の口座番号と送金額を書いた取引データを作り

自分の秘密鍵による署名を添えてネットワークに

放流することで送金が行える

取引データはP2Pネットワークで全体にゆきわたる

山本E山

D山

公開鍵口座番号として使う

秘密鍵署名に使う

23

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座 D中

署名山

基本的なビットコイン取引

● 自分の秘密鍵が漏れない限り、自分のお金が勝手に

別の人に送られることはあり得ない

‐ 秘密鍵による署名によってお金を引き出せる

‐ 逆に秘密鍵を紛失すると、お金は永遠に引き出せない

● 知らない人や、存在しない口座番号に

お金を送りつけることは可能

● 秘密鍵さえ流出しなければ、構造的に自分の口座は安全

24

受金確認

25

受金の確認

26

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

山本 → 中野

D中

署名山

● 山本から下記の取引データを受け取った中野は

どのようにして受金を確認できるか？

受金の確認

27

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

山本 → 中野

D中

署名山

● １つ前の取引データをネットワークから探す

取引AINPUT

取引Zのハッシュ値OUTPUT

5BTC：山本口座

誰か → 山本

D山

署名誰

か

受金の確認

28

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

山本 → 中野

D中

署名山

● どんどんさかのぼり一番最初の取引までたどり着けばOK！‐ Bitcoinアプリをインストールすると最初に２日くらいかけてこれま

での全取引を検証する

取引AINPUT

取引Zのハッシュ値OUTPUT

5BTC：山本口座

誰か → 山本

D山

署名誰

か

取引#0INPUT

なしOUTPUT

100BTC：Satoshi

最初の取引

DS署名Bitcoin

Official

これで受金の確認は十分と思いきや・・・

２重送金問題とブロックチェーン

29

２重送金

30

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

山本 → 中野

D中

署名山

● 最初までさかのぼれても、２重送金の可能性がある

取引AINPUT

取引Zのハッシュ値OUTPUT

5BTC：山本口座

誰か → 山本

D山

署名誰

か

取引#0INPUT

なしOUTPUT

100BTC：Satoshi

最初の取引

DS署名Bitcoin

Official

取引B’INPUT

取引Aのハッシュ値OUTPUT

5BTC：喜多口座

山本 → 喜多

D喜

署名山

２重送金問題

● 同じ取引をINPUTとした複数の取引が存在すると矛盾する

● 基本的な考え方：

先に届いた取引データを有効とし、それ以外は無効

● 近い時刻で２重送金された場合、

P2Pネットワーク上で、どちらの取引が有効か、

意見が割れることになる

→ ブロックチェーン31

ブロックチェーンと演算量証明

● P2Pの各ノードに取引データが一定量届いたら、

各ノードはそれをまとめた「ブロック」を作る

● その後、大量のCPU計算量が必要な演算により、

そのブロックに「演算量証明」を付与しブロードキャスト

‐ 演算量証明が正しいかどうかは一瞬で計算可能

● 演算中に他のノードが演算量証明を終えた場合は中止し、

その証明が済んだブロックの後の取引データについて

同様にブロックを作り演算証明を行う32

演算量証明

● ブロック内の取引データ、１つ前のブロックのハッシュ値、

それに適当なビット(Nonce)を加えて、

全体のハッシュ値の最初のnビットが全て0になるNonceを（総当たりで）探す

‐ nが大きくなると計算難易度が上がる

‐ 2016ブロックごとに、直近2016ブロックが2週間かかるようにnは更新

≒１ブロックが約１０分で証明されるように

33

ブロックチェーン　　　　　　　　　

● 演算量証明が済んだブロックのチェーン

‐ チェーン内の取引は矛盾は含まれない

● 改ざん耐性

‐ あるブロックは前のブロックのハッシュ値を含むので

途中の部分を改ざんすることは困難

● それ以降の全ての演算証明をやりなおす必要あり

‐ ブロックチェーンの古い方へいくに従い、信頼性が上がる

● 常に「最も長いチェーン」を真の取引履歴とみなす

● １つの最長チェーンに収斂

‐ ほぼ同時に演算量証明が済むと、一時的に２つの最長チェーンが存在する可

能性がある

‐ その場合、次の演算量証明が早く済んだチェーンが勝つ

‐ 何度も同時に演算量証明がなされる確率はとても低い 34

ブロックチェーンを用いた取引

1. 受金者 → 送金者：受金者の公開鍵（口座番号）を送る

2. 送金者 → 受金者：取引データを送る（送金者署名済み）

3. 受金者は取引データをブロードキャスト

4. 受金者は一定期間待ち、

流通している最長ブロックチェーンの

先頭 z ブロック以降に、

この取引が含まれることをもって、受金確認とする

5. 同じINPUTの別の取引がブロックチェーンに含まれるのを発

見した場合、取引無効とみなす

（例えば、商品発送を行わない、ということ）35

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座 D中

署名山

２重送金した場合

● ネットワーク上の個々のノードでは、先着した取引のみが有効になり、もう一方は捨てられる● 演算量証明が先に済んだブロックに含まれている取引のみが有効になる

● 単純に同時に送金しても、単にどちらかの取引のみしか行われないだけ

36

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

山本 → 中野

D中

署名山

取引B’INPUT

取引Aのハッシュ値OUTPUT

5BTC：喜多口座

山本 → 喜多

D喜

署名山

大量のマシンパワーによる２重送金

1. 山本が中野に送金すると、取引 Bを含むブロックチェーンが伸び始めるが、ここで山本と喜多がグルになって、大量の CPUパワーを投入して取引Bを含まず、取引B’のみを含む偽ブロックチェーンを秘密裏に伸ばす

2. 中野が、取引Bを含むブロックチェーンを確認し、受金確認した後で、そのブロックチェーンよりも偽ブロックチェーンを伸ばしてネットワークに流せば取引B’は無効になり、詐欺ができる

37

取引BINPUT

取引Aのハッシュ値OUTPUT

5BTC：中野口座

山本 → 中野

D中

署名山

取引B’INPUT

取引Aのハッシュ値OUTPUT

5BTC：喜多口座

山本 → 喜多

D喜

署名山

２重送金詐欺はできるか？

● ネットワークの過半の計算パワーを持てば容易にできる

● ネットワークの善良ノードの計算パワーに比べて

小さいパワーしかない場合、真のブロックチェーンの

長さを超えていられる確率は、伸びた長さに対して指数関数

的に現象

● 取引が最長ブロックチェーンの先頭 z ブロック以降に存在す

ることをもって受金確認とする場合、

zを調整することでリスクを調整することができる

38

ネットワーク参加者への報酬：マイニング

● ブロックに演算量証明を付与する際、

新たにコインが生成され、証明者のものになる

‐ そもそも、その取引データを含んでブロックを作る

‐ ネットワークを維持するインセンティブ

● ビットコイン総量はどんどん増える

‐ 発散しないように、

ブロックあたりの生成コインは年々減っていく設計

39

40

ネットワーク参加者への報酬：手数料

● 取引時は、任意の手数料を設定できる

‐ 支払額 = 受取額 + 手数料

● 手数料はブロックチェーンの証明者が受け取る

● 将来、生成されるビットコインがほとんどなくなった後

手数料がネットワーク維持のモチベーションになる

● 手数料が少ない取引はなかなかブロックチェーンに取り込ま

れず、取引に時間がかかるようになる

41

報酬による不正防止

● 善良ノード群を超えるCPUパワーを集めると、

攻撃者はブロックチェーンを捏造して

自分が支払ったコインを取り戻すことができる

‐ 言い換えると、たかだか、それだけしかできない

‐ さらに、それをするとビットコインの信用も落ちて自分の資産価値も

下がる

● 同じCPUパワーをネットワーク維持に使うと、

ネットワーク上の生成コインや手数料の半分を手に入れられる

‐ 悪い人も、こちらのほうが儲かる、と判断するはず

42

まとめ動画

43

まとめ動画

YouTubeで一番分かりやすかった解説動画。20分くらい

https://youtu.be/Lx9zgZCMqXE

残念ながら日本語が自動翻訳なので、字幕は参考程度に。

44

45

まとめ

46

まとめ

● 送金データがとびかうP2Pネットワーク

● 送金データへの送金者のデジタル署名により

出金を認証

● 演算量証明とブロックチェーンにより

ネットワーク共通の取引履歴を維持

47