1. の個人的勉強ノート
第版（年月日）
@pizyumi

2. はじめに
• 本文書は@pizyumiがBitcoinについて勉強するために作成している
ノートです。決して完成されたものではなく、@pizyumiが勉強していく
に連れて新たな事項が追加されていきます。
• 勉強中のため、本文書の記述には誤りが含まれているかもしれませ
ん。
• 一応、勉強がある程度進捗し、暗号貨幣に対する十分な知識が得ら
れた場合には、本ノートを基に暗号貨幣に関する文書（「暗号貨幣技
術入門（仮題）」）を執筆する予定があります。

3. 貨幣
• 集中型の貨幣システムの問題
• 口座が凍結される可能性がある。
• 貨幣が没収される可能性がある。
• 手数料が高い。

4. 電子貨幣
• 発行者に依存するもの：集中型
• David Chaum. Blind signatures for untraceable payments. In Crypto, volume
82, page 199203, 1982.
• Ronald L Rivest. Electronic lottery tickets as micropayments. In Financial
Cryptography, pages 307–314. Springer, 1997.
• Beverly Yang and Hector Garcia-Molina. Ppay: micropayments for peer-to-
peer systems. In Proc. of Computer and communications security.
• 使用者間の貸借関係によるもの
• Ryan Fugger. Money as ious in social trust networks & a proposal for a
decentralized currency network protocol. 2004.

5. とは
• 電子貨幣（digital currency）システムである。
• 最初の完全な分散型（P2P型）の電子貨幣システムである。
• 従来の電子貨幣システムは集中型（クライアントサーバ型）であった。
• 全てのノードが完全な元帳を保持する。
• ノードが取引を検証する。
• 現金に近い。
• 取引はほぼ即時に処理される。
• 払い戻し不可能（non-refundable）である。
• 現金でできることが世界規模で行える！
• 2008年に始動。オープンソース。
• 価格は急激に上昇。取引数も急激に上昇。
• 価格は一時1BTC1000ドル超え。取引数は1日6万件程度（1秒間に0.7件）。
• クレジットカード取引などと比較するとまだまだ小規模。

6. の目的（個人的考え）
• ①汎用的な決済手段を提供する。
• 決済とは、「代金や証券・商品、または売買差金の 受け渡しによって、売買取引を終了すること」。
• 決済手段を提供するためには、何らかの貨幣（又はそれに類するもの）が必要となる。
• その貨幣を使って決済できるようにする。
• 必ずしも独自の貨幣を作らなければならないという訳ではない。他人が作った貨幣を流用しても構わない。
• ②中央機関を不要にする。
• 法貨を発行することのできる政府、中央銀行などの機関を不要にする。
• 決済を仲介する中央清算機関を不要にする。
• ただし、Bitcoinの内部には中央清算機関は存在しないものの、Bitcoinの周縁には中央清算機関が存在する。
• 清算とは、複数の買い手と売り手の間で決済条件の照合を行い、決済を成立させたり、差額決済を行うこと
である。
• 中央機関に頼らないでどのように貨幣を発行すれば良いのか？
• 利害関係人が全員で発行すれば良い。
• 利害関係人が全員自由に参加できるP2Pネットワークを構築して、その中で（コンピュータコードという形で表
現された）定められた規則に従って貨幣を発行する。

7. • P2Pネットワーク上で、中央機関に頼らないで、汎用的な決済手段を
提供する（①の目標に②の目標を加味したもの）
• には・・・、どうすれば良いのか？
• まずは、現実世界の決済を考える。
• これを、（コンピュータコードという形で表現しなければならないので
まずは）構造化する。
• （執筆途中）

8. 口座（）
• 256bitの楕円曲線DSA（Elliptic Curve Digital Signature Algorithm：ECDSA）
の公開鍵と秘密鍵の対。
• 秘密鍵はBitcoinを別の口座に送る際に署名をするために使用する。
• 口座の所有者（秘密鍵の所有者）のみが口座にあるBitcoinを別の口座に送ること
ができる。秘密鍵を知らない第三者は別の口座に送ることができない。
• 秘密鍵は厳重に保管されなければならない。
• 秘密鍵を知った第三者は口座にあるBitcoinを別の口座に送ることができる。
• 公開鍵は公開され、署名を検証するために使用する。
• 秘密鍵を知らない第三者は署名検証を通過することができない。つまり、秘密鍵を
知らない第三者が口座にあるBitcoinを別の口座に送ろうとしても、署名検証の過程
で署名が正当でないことが判明するので、送金は拒否される。
• 公開鍵のハッシュ値が口座番号（address）。
• 口座を識別するために使用する。

9. 取引（）
• 口座間におけるBitcoinの移動を表現する。
• 採掘によるBitcoinの鋳造も特殊な形式の取引として表現される。
• より具体的には、
• 1つ以上の出金口座（source account）から1つ以上の入金口座（destination account）へのBitcoinの移動を表現する。
• 取引によって、1つ以上の入力（input）と1つ以上の出力（output）が生成される。
• 出力・・・ある口座に関連付けられているBitcoinの額面を表す。
• 出力は1回だけ使用することができる。
• 取引によって古い出力が使用され、新しい未使用の出力が生成される。
• 入力・・・どの（未使用の）出力を支払いに使用するかを指定する。
• 指定された出力が使用済みである場合には、取引は無効である。
• 1つの取引の中にある1つ以上の入力が指し示す古い出力の額面の合計は、新しい出力の額面の合計以上でなければならない。
• 小さい場合には、取引は無効である。
• 古い出力と新しい出力の額面の合計の差が取引手数料である。
• 口座に出力が関連付けられる。
• 口座に関連付けられている未使用の出力の額面を合計すれば、口座残高が求められる。
• 取引のハッシュ値。
• 取引を識別するために使用する。

10. 元帳（）
• 口座（account）間の全ての有効な取引が記録される。
• 検証に通らなかった無効な取引は記録されない。
• 全ての口座の残高を求めることができる。
• 全てのノードが元帳を保持する。
• 新しい取引が発生した場合には、その情報が全てのノードに伝えられる。
• 新しい取引を受け取ったノードは、その取引を検証してから、その取引が有効である場合には、元帳に記録する。
• P2Pなので、全てのノードに情報が伝わるのには時間が掛かる。
• ある瞬間に全てのノードが保持する元帳が完全に一致するとは限らない。
• 問題1：古い取引が伝わる前に新しい取引が伝わる可能性がある。
• 古い取引が伝わるまで、新しい取引が有効かどうか分からない。
• 問題2：二重消費攻撃（double spending attack）
• ノード間の元帳が矛盾する。
• どれが有効な取引か分からない。

11. ブロック（）
• ノード間で元帳の状態をほぼ一定間隔で同期するための構成単位。
• 二重消費攻撃に対処するための仕組み。
• 取引に優先順位を付ける
• 矛盾する2つの取引があるとき、優先する取引が有効な取引となり、逆に、
劣後する取引が無効な取引として除斥される。
• P2Pなので、優先順位について（多数の）ノードの合意がなければならない。
• 全てのノードは暫定的に取引を収容し、それらの取引を含むブロックの作成
を試みる。あるノードがブロックの作成に成功した場合、そのノードはそのブ
ロックを他のノードに送信する。

12. ブロック作成
• 暫定的に収容された取引の内、どの取引をブロックに格納するかはノードの自由裁量に任されている。た
だし、現在ブロックの大きさは1MBまでに制限されている。
• ブロックを作成するには仕事証明（proof-of-work）に対する解（nonce）を発見しなければならない。
• 解は一定の（それぞれのノードの仕事に関して平等な）確率で発見できるようになっている。
• ブロックの頭部と解を結合したもののハッシュ値の先頭何ビットかが0となるようにしなければならない（ある
値以下のハッシュ値となる解を発見しなければならない）。
• この値を目標（target）と言う。
• 目標はネットワーク全体で約10分に1個のブロックが生成されるように、ノード間で合意される（ただし、2016ブロック毎にし
か調整は行われない）。
• 解を求めるのは困難であるが、解が正当であるかを検証するのは容易である。虱潰し（brute force）に解を
探索するしかない。
• ハッシュ値はブロックを識別するためにも使用される。
• ブロック作成を試みるノードを採掘者（miner）と言う。ブロック作成を採掘（mining）と言う。
• ブロックを発見した採掘者は近接ノードにブロックを送信する。ブロックを発見した採掘者を、ネットワークの観点から見て、
原点（origin）と言う。
• ブロックを発見した採掘者は報酬として新たに鋳造されたBitcoinを受け取る（ただし、ブロック鎖の頭部に接続できなけれ
ばならない）。
• これが、採掘者が仕事を行う動機となる。

13. ブロック鎖（）
• ブロックを作っただけでは、取引について矛盾がないことを保証できない。
• 複数のブロックの中に含まれている幾つかの取引が矛盾している可能性がある。
• ブロック間の優先順位が必要
• ブロック間での優先順位が決まれば、ブロックの中に含まれている取引の優先順位も決まる。
• 全てのブロックは有向木（directed tree）として編製される。
• 根（root）に当たるブロックを起源ブロック（genesis block）と言う。あるブロックから起源ブロックまでの道の長
さをそのブロックの深さ（block height）と言う。
• 任意のブロックから起源ブロックまでの道の内、最長のものをブロック鎖と言う。ブロック鎖の中で葉に当た
るブロックをブロック鎖の頭部（blockchain head）と言う。
• ブロックの頭部（block header）とは異なるので注意！
• これでブロック鎖の中でのブロックの優先順位を決めることができる。
• ブロック鎖の中において、より小さい深さにあるブロックはより大きい深さにあるブロックに優先する。
• 従って、ブロック鎖の中において、より小さい深さにあるブロックの中に含まれる取引はより大きい深さにあるブロックの中に
含まれる取引より優先する。
• 採掘者はブロック鎖の頭部に接続することのできる新しいブロックを発見した場合にのみ報酬を得られる。
• それ以外のブロックに接続することのできる新しいブロックを発見しても意味がない。

14. ブロック鎖の役割
• 1.取引の順番を決定する。
• 2.ハッシュ計算能力による安全性を提供する。
• 3.口座残高を管理する。
• これらの3つの役割を全て担っているのがブロック鎖。

15. 採掘の要件
• 生成するのが困難
• 検証するのが容易
• 採掘装置の最適化が困難（ASIC耐性、GPU耐性）

16. ブロック鎖分岐（）
• ブロック鎖が2つ以上存在する状況が起こり得る。
• 起源ブロックからあるブロックまでは共通しているが、そのブロックから分岐し、別々の頭部を有する。
• このような状況をブロック鎖分岐と言う。
• 何れかが優先されなければ、取引について矛盾がないことを保証できない。
• 通常は、時間が経てば、何れかが長くなり、それ以外は最早ブロック鎖ではなくなるので、問題はない。
• 何らかの原因で、ネットワークが完全に幾つかに分裂すると、分裂したネットワークはそれぞれ独自のブロッ
ク鎖を有するようになる。
• 更にまた、何らかの原因で、分裂したネットワークが統合すると、どれか1つのブロック鎖が生き残り、それ以外のブロック鎖
は消滅する。
• そのため、ネットワーク分裂の検出は非常に重要である。
• ネットワーク分裂の検出は、ネットワークの総計算能力の観測によって行う（ブロックの発見頻度が大きく減少した場合、ネット
ワークの分裂が疑われる）。
• ブロック鎖の一部ではなくなったブロックを破棄ブロック（orphan block）と言う。
• 長くなったものが常に正しいと考える。
• ブロック鎖分岐が発生している状況では、何れのブロック鎖が長くなるか不確定なので、ブロック鎖分岐が発生したブロック
以降のブロックに含まれている取引は、後になって取り消される可能性がある。
• ブロック鎖分岐が発生するかどうかも不確定なので、ある取引が有効であるか否かは確率的である。
• 尤も、取引が実行されてから十分な時間が経過すれば取引が取り消される確率は実用上全く問題がない程極めて低くなる。

17. 攻撃（）
• あるノードがネットワークの計算能力の多くの部分を支配している場
合には、そのノードは残りの全てのノードが全体として新しいブロック
を発見するより早く別の新しいブロックを発見することができるので、
任意の取引を取り消すことができる。
• 取り消したい取引が含まれるブロックbdからその取引を除いた別の新しいブ
ロックbd’を発見し、その新しいブロックに接続する新しいブロックを現在のブ
ロック鎖の長さを越えるまで発見していけば、 bd’を通る道が新しいブロック
鎖となる。
• ギャンブラーの破産問題（gambler's ruin problem）

18. 難易度
• 有効なブロックを作成するのがどれくらい難しいかを表す。
• 有効なブロックを作成するためにはノード間で合意されている目標以下の
ハッシュ値を生成する解を求めなければならない。
• 目標は2016ブロック毎に調整されるので、難易度も2016ブロック毎に変化す
る。
• 目標が小さい程難易度は大きい。目標が大きい程難易度は小さい。

19. 時刻印（）

21. 分散型電子貨幣システムを作ろうとすると顕
在化する問題
• どのようにして貨幣の元帳を保持するのか？
• データが失われる可能性にどう対処するか？
• Bitcoinでは全てのノードが完全な元帳を保持する。
• 厳密には、新しい取引の情報が全てのノードに伝播するにはある程度時間が掛かり、
取引を検証するにも時間が掛かるので、全てのノードが保持する元帳が完全に一致す
る訳ではない。しかし、最終的には、全てのノードが完全な元帳を保持する筈である。
• どのようにして取引の検証を行うか？
• 不正な取引は拒否しなければならない。

22. • Nakamotoによって作られた概念実証を目的とする参照実装
（reference implementation）であるが、現在でも尚最も広く使用され
ているクライアントである。

23. ネットワーク
• Bitcoindの場合。
• 接続数は8（MAX_OUTBOUND_CONNECTIONS）
• 接続数より小さくならないように常に接続を維持する。
• Bitcoinネットワークに存在するノードが8以下の場合には、当然ながら、接続
数より少ない接続しかできない。
• ポートが開放されていないノードは、最大で8個のノードまでしか接続しない。
• ポートが開放されているノードは、8個より多くのノードと接続する可能性が
ある。
• 平均で32個のノードと接続しているらしい[1]。

24. 通信文（）
• 元帳の更新及び同期
• inv
• あるノードが新しい取引やブロックの検証を終えると、新しい取引やブロックがあることを通知するために近接ノードにinv通信
文を送信する。
• 取引のハッシュ値の集合とブロックのハッシュ値の集合
• getdata
• 取得したい取引やブロックを通知する。
• 取引のハッシュ値の集合とブロックのハッシュ値の集合
• tx
• 取引の送信
• block
• ブロックの送信
• 伝播遅延（propagation delay）
• 取引やブロックがあるノードから別のノードに伝わり、検証されるまでに要する時間。
• 伝送時間＋検証時間
• inv + getdata + (tx or block) + 検証時間
• 遅延損失（delay cost）
• 通信文の大きさが増えるとどれだけ遅延が大きくなるか。

25. の応用
• 電子財産（smart property）
• 電子契約
• 第三者預託取引（escrow transaction）

26. の問題点
• 拡張性（scalability）
• ノード数が増えた場合
• 取引が増えた場合
• 現在ブロックの大きさは1MBまでに制限されている。また、ブロックは平均して10分に1個ず
つ生成されるように調整されている。従って、処理可能な取引数には上限がある（上限があ
るというよりは、ネットワークの処理能力を超過しないように制限を設定していると言った方
が正しい）。
• 平均的な取引の大きさを考慮すると、現在の取引数の上限は約3.3取引/秒である。
• データ転送量
• 伝播遅延
• 検証時間
• ブロックの大きさの最大値
• ブロックの大きさが大きくなれば伝播遅延も大きくなる。
• データ量（ブロック鎖の肥大化（blockchain bloat））

27. の問題点
• 取引や取引の有効性の確認に時間が掛かる
• ブロック生成間隔は10分なので、取引がブロックに取り込まれて有効性が確認され
るまでに時間が掛かる。
• ブロック鎖分岐が発生している可能性があるので、更に何ブロックか生成されるま
で待たないと、取引の有効性が覆される可能性がある。
• かと言って、安易にブロック生成間隔を短縮すると、伝播遅延のために頻繁にブ
ロック鎖分岐が発生する状況となり、どれが本当に有効な取引か分からない混乱
状態に陥る可能性がある。
• 匿名性が低い
• 採掘者が手数料のある取引をその取引を含んだブロックを作成するまで
他のノードに伝えない可能性がある。
• 最小手数料が固定されている。
• 手数料の自動調整（smart fee）が実現すれば解決するが・・・。

28. 拡張性の問題を改善する
• 簡易決済検証（simplified payment verification）
• クライアントはブロックの頭部のみダウンロードし、ブロックが鎖状に接続さ
れているか確認し、ブロックの難易度が十分に高いかどうか確認する。
• 取引が格納されているMerkle木の一部のみをダウンロードして取引がブロッ
クに含まれているかどうか確認する。
• 十分に古いブロックの頭部はダウンロードせず、十分に古くなったブロックの
頭部は破棄する。

29. ブロック鎖の肥大化の問題を改善する
• ブロック鎖の剪定（blockchain pruning）
• 更新取引（refresh transaction）
• 未使用の取引出力を有する古い取引を口座番号毎に1つに纏めた取引を作成する。
• 誰が作成するのか（誰が作成するべきか）？
• 秘密鍵は不必要なので作成すること自体は誰でも可能。
• 作成者に手数料を与えるべきか？
• 究極のブロック鎖圧縮（ultimate blockchain compression）
• 全ての未使用の取引出力を口座番号毎に纏めた木を使用する。
• 未使用の取引出力を口座番号毎にダウンロードすることができ、口座番号毎に未使用の取引の検証
を行うことができる。
• 通常1つの口座に含まれる未使用の取引出力のデータは非常に小さいので素早くダウンロードするこ
とができる。
• 口座の残高を知るために最小限のデータしか必要ない。
• この木は別のブロック鎖の頭部に含まれる。
• 統一採掘（merged mining）によって安全性が維持される。

30. ブロック鎖の肥大化の問題を改善する
• 制限的なブロック鎖
• 口座木（account tree）
• 全ての空でない口座の残高を保持する。
• 口座番号、口座残高、参照ブロック（reference block）
• 参照ブロックは、口座における取引出力を使用する最後の取引が含まれているブロックの
番号。
• できる限りデータの大きさが小さくなるようにすべき。
• 小型ブロック鎖（mini-blockchain）
• 十分に古いブロックが削除されることによってブロックの数が制限的である以外は普通のブ
ロック鎖と同様である。
• それぞれのブロックはそれらが生成された時点における口座木のハッシュ値を含む。
• 口座木が正しいことを検証することができる。
• 証明鎖（proof chain）
• 起源ブロックから最新ブロックまでの一連の仕事証明の解からなる鎖。

31. そもそもブロック鎖の肥大化は問題なの
か？
• 全ての使用者が完全なブロック鎖を保持する必要はないのではないか？
• 分散の度合いが下がり、集中の度合いが上がる。
• いつの間にか既存の銀行システムと同様なものとなり、今までやってきたことは何
だったんだということになるかもしれない。
• 使用済みの取引出力しか有しない取引はブロック鎖から除去できる。
• 塵芥のような非常に小額の取引出力であっても、未使用の取引出力を有する取引
は残存する。
• ブロック鎖外の取引（off-chain transaction）はブロック鎖には何の影響も
及ぼさない。
• 取引手数料がブロック鎖の保持費用を相殺する。
• Mooreの法則は健在であり、近い将来においてこの法則が崩れることは
ない（継続的な技術革新によって拡張性の問題は吸収され、顕在化する
ことはない）。

32. 匿名性を向上させるには？
• Darkcoin
• Zerocoin, Anoncoin, Zerocash, Nxtcash, etc
• NxtCashの場合
• 匿名性
• 貨幣の送信者と受信者を結び付けることができない（誰が誰に送金したのかが当事者以外には分からない）。
• 無信用性
• 信用できる第三者機関を必要としない。
• 分散性
• 単一機関ではない。単一障害点（single point of failure）がない。
• 暗号学的な安全性
• 悪意のある攻撃からの保護。
• 効率性
• 多くの取引を処理することができる。
• ゼロ知識証明（zero-knowledge proof）
• zk-SNARK

34. • proof of effort
• proof of work
• Bitcoin, Litecoin, etc
• 特定の値以下のハッシュ値を有する解を計算させることで、取引を有効にする。
• proof of validity
• proof of inclusion
• proof of stake
• Peercoin, Nxt, etc
• proof of burn
• Counterparty
• Proof of transaction
• Fluttercoin
• proof of excellence
• proof of bandwidth
• proof of identification
• proof of publication

35. 関連論文
• [1] Information Propagation in the Bitcoin Network, Christian Decker @ ETH Zurich, Switzerland, Roger
Wattenhofer @ Microsoft Research
• An Analysis of Anonymity in the Bitcoin System
• Quantitative Analysis of the Full Bitcoin
• Transaction Graph
• Beware the Middleman:
• Empirical Analysis of Bitcoin-Exchange Risk
• Evaluating User Privacy in Bitcoin
• Bitter to Better—How to Make Bitcoin a Better Currency

36. 関連論文
• “Bitcoin: A First Legal Analysis – with reference to German and US-American law” By Franziska Boehm, Paulina Pesch, Institute for Information-,
Telecommunication-, and Media Law, Muenster, Germany
• “The Bitcoin P2P network” By Joan Antoni Donet Donet, Cristina Pérez-Solà, and Jordi Herrera-Joancomartí, Dept. d’Enginyeria de la Informació i les
Comunicacions Universitat Autònoma de Barcelona 08193 Bellaterra, Catalonia, Spain.
• “Empirical Analysis of Denial-of-Service Attacks in the Bitcoin Ecosystem” By Marie Vasek, Micah Thornton, and Tyler Moore, Computer Science and
Engineering Department Southern Methodist University, TX, USA.
• “How Did Dread Pirate Roberts Acquire and Protect His Bitcoin Wealth?” By Dorit Ron and Adi Shamir, Department of Computer Science and Applied
Mathematics, The Weizmann Institute of Science, Israel.
• “Fair Two-Party Computations via Bitcoin Deposits” By Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek, University
of Warsaw, Poland.
• “Increasing Anonymity in Bitcoin” By Amitabh Saxena and Janardan Misra, Accenture Technology Labs, Bangalore 560066, India and Aritra Dhar,
Indraprastha Institute of Information Technology, New Delhi, India.
• “Game-Theoretic Analysis of DDoS Attacks Against Bitcoin Mining Pools” By Benjamin Johnson, University of California, Berkeley, CA, USA; Aron Laszka,
Budapest University of Technology and Economics, Hungary; Jens Grossklags, The Pennsylvania State University, State College, PA, USA; Marie Vasek
and Tyler Moore, Southern Methodist University, Dallas, TX, USA.
• “Towards Risk Scoring of Bitcoin Transactions” By Malte Möser, Rainer Böhme, and Dominic Breuker, Department of Information Systems, University
of Münster, Germany.
• “Rational Zero: Economic Security for Zerocoin with Everlasting Anonymity” By Christina Garman, Matthew Green, Ian Miers, and Aviel D. Rubin, The
Johns Hopkins University Department of Computer Science, MD, USA.
• “Challenges and Opportunities Associated with a Bitcoin-based Transaction Rating System” By David Vandervort, Xerox.

37. 梗概
• 本論文では、
• 全てのノードによって共有されている元帳を最新の状態に更新させるため、
新しい取引やブロックを全てのノードに伝播させる際に、Bitcoinがどのように
して多段中継の一斉同報通信（multi-hop broadcast）を使用するのか（どの
ように情報が伝播するのか）を分析する。
• ネットワークの伝播遅延がブロック鎖分岐の主要な原因であるか検証する。
• クライアントの挙動に一方的な変更を加えるだけで、現在のプロトコルに変
更を加えず限界まで利用して、何を達成することができるか示す。

38. • ブロックの伝播について、その大きさを考慮しない場合
• 中央値は6.5秒。
• 平均値は12.6秒。
• ロングテール。
• ブロックの伝播が始まってから40秒経過しても5%のノードには未だ伝播して
いない。
• 取引とブロックの伝播について、その大きさを考慮した場合
• 小さい取引やブロックは遅延の、大きさに対する比率が大きい。
• 20kByteを超えるブロックでは遅延の、大きさに対する比率がほぼ一定。
• 20KByteを超えた場合は、ブロックが大きくなっても一定の比率でしか伝播遅延は増加
しない。
• inv通信文とgetdata通信文の往復に非常に時間が掛かっている

39. • 矛盾する2つの取引やブロックを検出した場合にそれを他のノードに
転送しないとどうなるか？
• 一方の取引やブロックが有効であると見做しているネットワークと他方の取
引やブロックが有効であると見做しているネットワークに分裂している状態で
あるから、その2つの分裂したネットワークの正に境界にあるノードのみが矛
盾する2つの取引やブロックが存在することを認識しているだけである。
• 取引の場合は、スパム取引によるネットワークの不安定化を防止す
るため、矛盾する取引を転送しないのは妥当な選択だろう。
• しかし、ブロックの場合は、矛盾するブロックを転送しないと、ブロッ
ク鎖分岐が発生したことを認識できるノードが極少数に限られてしま
う。

40. • ブロック鎖分岐割合（到達できるノードのみに関して調べた値）
• 1.69%
• 伝播遅延が大きくなればなるほどブロック鎖分岐が発生しやすい。
• ブロック鎖分岐割合（理論値）
• 1.78%
• 微妙に実測値より大きいのは、ハッシュ計算能力が全てのノードに
一様に分布しているという仮定がおかしいからだろう。
• とは言え、実測値と十分良く一致している。

41. • 新しいブロックが見付かる毎に11.37秒分のネットワーク全体のハッ
シュ計算能力が無駄になっている。
• 伝播遅延が大きくなればなるほどハッシュ計算能力が無駄になる。
• つまり、元帳の安全のために実際に役に立っているハッシュ計算能
力は投入されているハッシュ計算能力の98.20%
• 全体のハッシュ計算能力の過半数のハッシュ計算能力を支配していれば
51%攻撃を実行できるとされているが、実際には49.1%を超えれば51%攻撃
を実行できる。
• 伝播遅延が大きくなればなるほど51%攻撃に必要なハッシュ計算能力の割
合が低下する。

42. • 伝播遅延には悪影響が多い。
• 何とかして伝播遅延をできる限り小さくしよう！

43. • 検証の最小化
• ブロックの検証には難易度の検証と取引の検証の2つがあるが、難易度の検証を
して直ぐにinv通信文を発行するようにする。
• たとえ無意味なデータを含んでいるブロックであっても、難易度の検証に通るように作るの
は、有効なブロックを作るのと同程度のハッシュ計算能力が必要になるので、DDoS攻撃に
悪用される心配はない。
• ブロック伝播の並列化
• inv通信文を受信したら、直ぐに近接ノードにそのinv通信文を転送する。
• 幾らでも虚偽のinv通信文を発行することができる。しかしながら、inv通信文は61バイトしか
ないし、tx通信文を発行することでも同様のことはできるので、影響は少ない。
• 接続数の増加
• 接続数を4000以上にすると全ての到達可能なノードに接続できる。
• 100MB/s程度のデータ転送量が必要

44. • 全ての改良を施したクライアントでブロック鎖分岐割合を調べてみる
と、
• 1.69% → 0.78%
• 53.41%の向上！

45. 梗概
• 殆ど全ての分散型暗号貨幣はブロック鎖という仕組みを使って二重消費
攻撃を阻止している。
• しかしながら、ブロック鎖には肥大化の問題がある。
• 本論文では、制限的なブロック鎖を使用する分散型暗号貨幣を提案する。
• 制限的なブロック鎖では、ブロック鎖の中にあるブロックの数が上限に達
している場合には、新しいブロックが発見され、ブロック鎖に追加されると、
ブロック鎖の中で終端に存在する最古のブロックが削除される。
• ブロックの削除が引き起こす安全性低下の問題は証明鎖（proof chain）によって解
決される。
• ブロックを削除するとブロックに含まれている未使用の取引出力も削除されてしま
い口座残高の全部又は一部が消失するという結果を齎すが、それは空でない口座
の残高を保持する口座木（account tree）を構築することによって回避される。

46. • 制限的なブロック鎖
• 口座木
• 全ての空でない口座の残高を管理する。
• 口座番号、口座残高、参照ブロック（reference block）
• 参照ブロックは、口座の取引出力を使用する最後の取引が含まれているブロックの番号。
• できる限りデータの大きさが小さくなるようにすべき。
• 小型ブロック鎖（mini-blockchain）
• 十分に古いブロックが削除されることによってブロックの数が制限的である以外は普通のブ
ロック鎖と同様である。
• それぞれのブロックはそれらが生成された時点における口座木のハッシュ値を含む。
• 口座木が正しいことを検証することができる。
• 証明鎖
• 起源ブロックから最新ブロックまでの一連の仕事証明の解からなる鎖。

47. • 制限的なブロック鎖
• ネットワークの同期
• 1.最大の累積難易度（cumulative difficulty）を有する証明鎖を取得する。
• 2.証明鎖に結び付けられている小型ブロック鎖を取得する。
• 3.最近ブロックの主ハッシュ値（master hash）に結び付けられている部分ハッシュ値
（sector hashes）を取得する。
• 4.口座木を構築し、それぞれの部分（sector）のハッシュ値が部分ハッシュ値に一致する
か検証する。

48. • 動的な最大ブロック長の決定
• 採掘者がブロックに希望する最大ブロック長を格納する。
• 小型ブロック鎖に含まれる全てのブロックの希望最大ブロック長を平均したものが次の
ブロックの最大ブロック長になる。
• ある程度上限や下限を設定すべき。
• 最大ブロック長と実際のブロック長がどれくらい近いか。
• 失われた貨幣の再採掘
• 一定期間使用されなかった貨幣は特別の取引を使って採掘者が取得するこ
とができるようにする。

49. 梗概
• Bitcoinの仕組みは非常に高い頻度の取引の発生にも耐えられるのか？
• ノード間のデータ転送量の多寡や伝播遅延の長短は、取引の処理効率を左右し、延いては、
一定時間に処理可能な取引数を左右する要因である。
• データ転送量の多寡より伝播遅延の長短の方が遥かに影響が大きい。
• Nakamotoの論文では、ブロック生成間隔に比べると、伝播遅延は無視できる程に短いと仮
定している。
• しかしながら、この仮定は必ずしも妥当ではない。
• ブロック生成間隔をもっと短縮したいという需要も存在する。
• そこで、本論文では、
• Bitcoinのプロトコルが1秒間に安全に処理可能な取引数の上限を与える。
• 完全な取引データの代わりに取引のハッシュ値を使用するという現在計画されているプロト
コルへの改善がこの上限を著しく緩和する効果があることを示す。
• 攻撃者からの保護性能を向上させるブロック鎖の構成方法を提案する。
• 上述の上限を更に緩和する効果がある。
• 取引の確認時間も著しく低減することができる。
• ブロック生成間隔を安全に1秒まで短縮することができる。

51. アドレス
• 1.楕円曲線暗号の公開鍵
• 2.1の公開鍵のRIPEMD160ハッシュ値
• 3.2のハッシュ値にバージョン情報と確認コードを含めてbase58エン
コードしたもの

52. • Bitcoinアドレスを符号化するために使用される独自の方式。
• バイナリデータをテキストデータとして表現するための方式の一種。これと同種の方式とし
ては電子メールで使用されているBase64が代表的。他にも様々なものがある。
• FlickrではBase58という方式が使われているが、それとBase58Checkは異なる方式である。
• なぜBitcoinアドレスの表記ではBase64を使用せず、独自のBase58Checkを使用
しているのか？
• Satoshi曰く、
• 0（数字の0）とO（大文字のO）及び1（数字の1）とl（小文字のl）の間の混同を避けるためである。
• これらが混同されると、
• アドレスを間違える可能性がある。
• 同じ口座に見える異なる口座が作られ（詐欺などに使用され）る可能性がある。
• 数字と英文字以外の記号が入っているアドレスは口座番号としては受け入れにくい。
• 電子メールでは通常改行するべき記号が現れるまでは改行されない。
• ブラウザなどのUIではダブルクリックするだけで簡単にアドレス全体を選択することができる。

54. 分散ハッシュテーブル（：）

55. • 分散ハッシュテーブル
• 鍵空間は160ビット。
• 鍵は鍵空間上の1点に対応する160ビットの識別子である。
• ノードは鍵空間上の1点に対応する160ビットの識別子を有する。
• ノードが送信する全ての通信文には識別子が添付される。
• 識別子の距離はビット排他的論理和（bitwise exclusive or：XOR）：d(x, y) =
x ^ y
• d(x, x) = 0
• d(x, y) > 0 if x != y
• d(x, y) = d(y, x)（交換律）
• d(x, y) + d(y, z) >= d(x, z)（三角不等式）

56. • ノードは他のノードの情報を保持する。
• ノード情報：（IPアドレス、UDPポート番号、識別子）
• k-バケツ（k-buket）：ノードからの距離が2i～2i+1であるノードの情報を保持する160個のリスト。
それぞれのリストに格納されたノード情報は最後に通信を行った時間に基づいて整列され
る（最古のノード情報が先頭に、最新のノード情報が末尾に配置される）。
• iが小さい場合は、k-バケツは空であることが多い。
• iが大きい場合は、k-バケツはk個のノード情報を含むことが多い。
• ノードが他のノードから任意の通信文を受信した場合には、k-バケツを更新する
• k-バケツに対応するノード情報が存在する場合は末尾に移動する。
• K-バケツに対応するノード情報が存在しない場合は、
• k-バケツに格納されているノード情報がk個未満の場合には末尾に追加する。
• k-バケツに格納されているノード情報がk個以上の場合には最古のノード情報に対応するノードにping通信文を
送信し、応答を要求する。
• 応答があった場合には最古のノード情報を最新のノード情報として末尾に移動する（新しいノード情報は
破棄する）。
• 応答がなかった場合には最古のノード情報を削除し、新しいノード情報を末尾に追加する。
• k-バケツが一定時間更新されなかった場合にはk-バケツの範囲から無作為に1つ識別子を
生成し、ノード探索を実行する。

57. 通信手続き
• 4つの遠隔手続き呼び出し
• PING
• ノードが生きているか調べる。
• STORE
• ノードに鍵と値の結合を格納する。
• FIND_NODE
• 引数として識別子を取る。
• ノードが知っている識別子に近いk個のノードの情報を返す（ノードがk個以下のノード情報し
か知らない場合には知っている全てのノード情報を返す）。
• FIND_VALUE
• 引数として識別子を取る。
• ノードが知っている識別子に近いk個のノードの情報を返す（ノードがk個以下のノード情報し
か知らない場合には知っている全てのノード情報を返す）。
• ただし、鍵としての識別子に対応する値を有する場合には値を返す。

58. ノード探索（）、値探索
• 識別子に近いk個のノードを探索する。
• FIND_NODE
• 探索ノードは識別子に近いα個のノード情報をk-バケツから選出し、それらのノード情報に対
応するノードに対してFIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。
• 新しく得たノード情報から識別子に近いα個のノード情報を選出し、それらのノード情報に対
応するノードに対してFIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。
• 識別子に近いk個のノード情報に対応するノードで未だFIND_NODE遠隔手続き呼び出しを
実行していないノードに対してFIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行
する。
• 識別子に近いk個のノード情報に対応するノードからの応答を得られたら終わり。
• 識別子に近いk個のノードを探索しながら、鍵に対応する値を探索する。
• FIND_VALUE
• 上の場合とほぼ同様だが、値が取得できたら終わり。
• 最後まで値が取得できなかったら、値は存在しない（可能性が高い。仮に存在していても取
得する術がない）。

59. • 鍵と値の結合は鍵と識別子の距離が近いノードに格納される。
• FIND_NODE + STORE
• 一定時間毎に鍵と値の結合を距離が近いノードに再格納する。
• FIND_NODE + STORE
• 新しいノードを発見したら新しいノードの識別子と距離が近い鍵と値の結合を新しいノードに格
納する。
• STORE
• 鍵に対応する値を取得する。
• 鍵と近いノードで鍵に対応する値を保持していないノードがあったら、値を取得した後にノードに値を格納す
る。
• 取得した値はキャッシュする。値との間に多くのノードがあるノード程早くキャッシュが削除される。
• FIND_VALUE + STORE
• ネットワークに参加したいノードは何らかの方法で1個以上の既にネットワークに参加している
ノードの情報を入手し、ノード情報をk-バケツに挿入し、自身の識別子と距離が近いノードを探索
する。
• FIND_NODE