Bitcoinの仕組みを原論文に沿って説明します．

1. Bitcoinについて
2014年2月3日
九州大学大学院数理学府
修士2年 鷲見 拓哉

2. この発表の目的
1
*
Bitcoinを原論文に沿って理解する
* http://www.bitcoin.co.jpより引用

3. 2
Bitcoin
1. Bitcoin: A Peer-to-Peer Electronic Cash System (原論文)
 Satoshi Nakamoto, 2008年
 2009年にオープンソースのソフトウェア実装が公開
2. P2P電子通貨
3. 政府や銀行などの中央機関が存在しない
4. 二重使用問題の解決方法が独特

4. 電子通貨
3
B
B
B
ディジタルデータ
※以降，Bitcoinの電子通貨を「コイン」と表記

5. 二重使用問題
4
(1) 送金
B
B
B
B
(2) ディジタルデータのコピー
B
二重使用問題

6. Bitcoinにおける二重使用問題の解決方法
全ての取引の順序が一意に定まるよう
ネットワーク上で合意形成，監視
5

7. 取引の流れ
6
B
B
(1) 署名
秘密鍵
公開鍵
(2) 検証
秘密鍵
秘密鍵
公開鍵
公開鍵
※実際は，公開鍵を見てもそれが誰のものかは分からない

8. 取引
7
公開鍵
B
ハッシュ関数
(1) 署名
秘密鍵
公開鍵
(2) 検証
ハッシュ値
秘密鍵
ディジタル署名

9. 取引
8
B
1
取引情報
自分宛の支払い
別の取引
5
3
3
10
支払い
釣り（自分から自分への支払い）

10. 取引の連鎖
取引1
公開鍵
9
取引2
公開鍵
取引3
公開鍵
ハッシュ関数
ハッシュ関数
ハッシュ関数
ハッシュ値
ハッシュ値
ハッシュ値
署名
署名
署名
秘密鍵
秘密鍵
秘密鍵

11. リアルマネーはなぜ使えるか
10
(1) 何かを買う
1万円 に価値が
あると信じている
(2) 対価として 1万円 を支払う

12. リアルマネーの価値
1. 信用の裏付け：中央機関
2. 中央機関が通貨の価値を維持
11

13. コインの価値
12
1. 信用の裏付け：計算量的な信頼
2. 取引情報
を計算量の大きな処理を経て記録
3. 取引情報
の改ざんを困難にすることで価値を維持

14. タイムスタンプ・サーバ
13
1. ある時点で，そのデータが存在することを証明
2. ハッシュ関数を使う
時刻T1
ハッシュ関数
データ
このハッシュ値となる
データが時刻T1に存在した
時刻T2
ハッシュ関数
データ

15. 14
Proof-of-work
P2Pネットワーク上でタイムスタンプ・サーバを実現
ブロック
ブロック
ハッシュ値
取引0
取引1
Nonce
取引2
ハッシュ関数
ハッシュ値
取引3
取引4
Nonce
取引5
ブロックのハッシュ値が特定の値となるように Nonce を調整

16. 15
Proof-of-work
採掘
ブロック
ハッシュ関数
(SHA-256)
00000...000001010001001...11001010111010100
ハッシュ値の先頭Xビットが0になるような Nonce を求める
Bitcoinネットワークのパラメータ
採掘が10分間で完了できるよう随時調整される

17. 16
Proof-of-work
Bitcoinクライアントの実装
無限ループ
Nonceをインクリメントしてハッシュ値を総当り計算
https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp

18. 17
Proof-of-work
1. 現時点で未処理の取引情報を新しいブロックへ記録
2. ハッシュ値が条件を満たすようなNonceを求める
3. 見つけた値をブロックのNonceに設定
採掘処理
を実行
4. ブロックをブロードキャスト（ここまでに約10分）
5. 1.へ戻る（この10分間に新しい取引が発生）
採掘ノード
ノードは取引情報を共有
取引6
取引9
取引8
取引7
ノード
取引6
取引7
ノード
取引8
ノード

19. 18
Proof-of-work
(1) 各ノードは常に新しい取引情報をブロードキャスト
(2) 採掘ノードは常に採掘処理を実行
採掘ノード
(3) ブロックをブロードキャスト
取引9
採掘ノード
取引6
ハッシュ値
取引8
取引7
ノード
Nonce
取引6
ノード
取引7
取引5
ネットワーク全体で取引の正しさを監視
取引8
ノード
ノード
(4) 各ノードはブロックを検証
取引3
取引4

20. 採掘
19
1. 採掘ノードの役割：採掘＋ブロックのブロードキャスト
2. ある採掘ノードが採掘に成功 ＝
当該ブロックを初めてブロードキャスト
3. 採掘処理には高性能計算機と電力が必要
採掘ノードのモチベーションとは

21. 採掘のインセンティブ（参加動機，報奨金）
1. 採掘処理に成功した採掘ノードには報奨金
 2009年当初は1採掘あたり50コイン
 現在は1採掘あたり25コイン（4年毎に半減）
 2014年2月現在では1コイン≒8万円
2. 採掘は競争的プロセス
 使用する計算機の性能がどんどん上がる
 今までの流れ：一般的なパソコン → 並列GPU → FPGA
 最近は採掘処理のみを行う専用ハードウェア(ASIC)が登場
20

22. 21
Bitcoinネットワークへの攻撃
1. ブロックに含まれる取引は正しいとみなす
 正しい
＝
そのコインの使用が初めて
2. ブロックが続くほど取引の改ざんが困難
ブロック0
ブロック1
ブロック2
ブロック3
後方のブロックにハッシュ値が含まれるため改ざんが困難
ブロック1に含まれる取引を改ざんするには，2と3の改ざんも必要

23. Bitcoinネットワークへの攻撃
22
1. 善良な採掘ノード達は次々とブロックをブロードキャスト
2. 攻撃者が↑のブロック生成速度に勝てば取引を改ざんできる
3. 善良な採掘ノード達よりも高性能な計算機が必要
4. 高性能な計算機を準備できたとしても，改ざんが明るみに出ると
Bitcoinネットワークが崩壊
 改ざんして得たコインが無価値に
5. その計算機を使って，普通に採掘して報奨金を得る方が得策
6. 誰も改ざんしようとは思わない

24. ハッシュ木（マークル木）
各要素がハッシュ値の二分木
23
ルートハッシュ
ハッシュ01
ハッシュ23
ハッシュ0
ハッシュ1
ハッシュ2
ハッシュ3
取引0
取引1
取引2
取引3

25. ブロックの構造
24
ブロック
ブロックヘッダ
ハッシュ値
ハッシュ計算の
対象はブロック
ヘッダのみ
ルートハッシュ
Nonce
ハッシュ01
ハッシュ23
ハッシュ0
ハッシュ1
ハッシュ2
ハッシュ3
取引0
取引1
取引2
取引3

26. ディスク容量の節約
25
ブロック
ブロックヘッダ
ハッシュ値
Nonce
ハッシュ01
不必要な情報を
削除できる
ルートハッシュ
ハッシュ23
ハッシュ2
ハッシュ3
取引3

27. 取引の検証
26
最長のproof-of-workチェイン
ブロックヘッダ
ハッシュ値
ブロックヘッダ
ハッシュ値
Nonce
ルートハッシュ
ハッシュ2
ハッシュ値
Nonce
ルートハッシュ
ハッシュ01
ハッシュ01
ブロックヘッダ
取引3
ルートハッシュ
ハッシュ23
ハッシュ2
ハッシュ3
を用いて構成したハッシュ木の
ルートハッシュがブロックヘッダに含まれる
は正しい
（ネットワークに承認されている）
取引3
Nonce
取引3

28. プライバシ
27
従来のプライバシ・モデル
取引
信用できる仲介者
（銀行等）
取引
Bitcoinのプライバシ・モデル
取引
取引
取引
取引
取引
オープン
1. 取引情報から個人を特定できない
2. 取引ごとに鍵ペアを使い分けることで更なる匿名性を確保

29. まとめ
28
1. Bitcoinは中央機関に依存しない電子通貨
2. 二重使用問題の解決方法が独特
 Proof-of-workを用いてP2Pネットワーク上で取引履歴を記録
 取引履歴は計算量的に改ざんが困難
3. ノードはいつでも離脱／参加できる
 最長のproof-of-workチェインを信頼することで，離脱期間中の
取引を承認

30. 参考文献
1.
Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”, 2008,
https://bitcoin.org/bitcoin.pdf
2.
Bitcoinクライアント実装, https://github.com/bitcoin
3.
斉藤 賢爾, “ビットコイン－人間不在のデジタル巨石貨幣”, WIDE Technical-Report, 2013,
http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin2013-00.pdf
4.
山崎重一郎, “bitcoin勉強会1”, 2013, http://www.slideshare.net/11ro_yamasaki/bitcoin27954024
5.
山崎重一郎, “bitcoin勉強会2”, 2013, http://www.slideshare.net/11ro_yamasaki/bitcoin2
6.
須賀祐治, “BitcoinのECDSA署名生成時にポカしたら現金搾取される”, 2014年暗号と情報
セキュリティシンポジウム, SCIS 2014, 4A1-3, 2014
29