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

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

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

8. Byzantine将軍問題（Byzantine generals
problem）
• 中央機関に頼らないで貨幣を発行するには、利害関係人が全員で発行
すれば良い。
• しかし、P2Pネットワークにおいて匿名の、相互に信頼できない利害関係人の間でど
のようにして貨幣を発行するという合意を形成すれば良いのか（どのようにして規
則に従わない利害関係人を検知し、除斥すれば良いのか）？
• Byzantine将軍問題
• Byzantine将軍問題に対する解決策、即ち、 Byzantine耐故障性（Byzantine fault
tolerance）を具備した手続きはこれまでに幾つも提案されているものの、何れも、匿
名の、相互に信頼できないノードから成るP2Pネットワークに適用できるものではな
かった。
• Bitcoinの仕組みは匿名の、相互に信頼できないノードから成るP2Pネットワークにお
けるByzantine将軍問題に対する解決策である。
• そのため、Bitcoinの仕組みには暗号貨幣以上の応用がある。

10. 貨幣単位
• 1.0：bitcoin（BTC）
• 0.01：bitcent（cBTC）
• 0.001：milibit（mBTC）
• 0.000001：microbit（μBTC）
• 0.00000001：satoshi

12. P2Pネットワーク
• ネットワーク理論（network theory）
• 有向グラフ（directed graph）：G=(V, E)
• V：ノードの集合
• E：ノード間の接続の集合
• 遅延（delay）
• e in E, de
• eの一方のノードから送信された情報が他方のノードに受信されるまでの時
間。

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

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

15. 口座番号
• 次の3つは全て口座番号だが、通常は3の意味で使われる。
• 1.楕円曲線DSAの公開鍵
• 2.1の公開鍵のSHA256ハッシュ値のRIPEMD160ハッシュ値
• 3.2のハッシュ値にバージョン情報と確認和（checksum）を結合して
Base58Check符号化したもの

16. 財布取り込み形式（wallet import format：
WIF）
• Bitcoinの秘密鍵の表記方法。
• 0x80(or 0xef) || PrivKey|| checksumをBase58Check符号化したもの。
• checksum
• SHA256(SHA256(PrivKey))の先頭4バイト。

17. 小型秘密鍵形式（mini private key format）
• 30文字でBitcoinの秘密鍵を表現する形式。
• 先頭の文字は常にS
• 文字列の末尾に疑問符を結合したもののSHA256ハッシュ値の先頭
のバイトが0であるもののみが適格である。
• 秘密鍵は文字列のSHA256ハッシュ値である。

18. 階層的決定論的鍵生成（hierarchical
deterministic key creation）
• BIP32
• 任意の整数iに対して、ECDSAの公開鍵生成関数は次のような性質を有する。
• point(private_key) == public_key
• point( (parent_private_key + i) % G ) == parent_public_key + point(i)
• point( (child_private_key + i) % G ) == child_public_key + point(i)
• そこで、連鎖コード（chain code）と指数（index number）からHMAC-SHA512ハッシュ値を計算し、
次のようにして（親の鍵対に対する）子の鍵対を生成する（指数を変えれば異なる子の鍵対を生
成することができる。又、子の鍵対に対して同様の計算を実行すれば（親の鍵対に対する）孫の
鍵対を生成することができる）。
• point( (parent_private_key + lefthand_hash_output) % G ) == child_public_key
• point(child_private_key) == parent_public_key + point(lefthand_hash_output)
• HMAC-SHA512ハッシュ値の右側256ビットが次の連鎖コードとなる。但し、最初の連鎖コード（と
秘密鍵）は根本種子（root seed）から生成される。根本種子は128ビット、256ビット、又は、512
ビットの無作為な値である。
• 根本種子のHMAC-SHA512ハッシュ値の右側256ビットが最初の連鎖コードであり、左側256ビッ
トが最初の秘密鍵である。

19. 階層的決定論的鍵生成（続き）
• 根本種子から生成される最初の連鎖コードを最上連鎖コード（master chain code）と言い、最初の秘密鍵を
最上秘密鍵（master private key）と言う。最上秘密鍵から生成される公開鍵を最上公開鍵（master public
key）と言う。
• （親の鍵対に対する）子孫の鍵対を生成するには親の鍵対の他に連鎖コードが必要であるので、これらを
併せて拡張鍵（extended key）と言う（親の秘密鍵と連鎖コードを併せて拡張秘密鍵（extended private key）
と言い、親の公開鍵と連鎖コードを併せて拡張公開鍵（extended public key）と言う）。最上秘密鍵と最上公
開鍵と最上連鎖コードを併せて最上拡張鍵（master extended key）と言う（最上秘密鍵と最上連鎖コードを
併せて最上拡張秘密鍵（master extended private key）と言う。最上公開鍵と最上連鎖コードを併せて最上
拡張公開鍵（master extended public key）と言う）。
• 堅牢化鍵（hardened key）の場合は連鎖コードと指数と秘密鍵からHMAC-SHA512ハッシュ値を計算する。
• 通常の鍵生成に対しては0x00から0x80000000 までの指数が使用され、堅牢化鍵の生成に対しては0x80000001から
0x100000000 までの指数が使用される。
• 鍵の表記法
• mは秘密鍵であることを表し、Mは公開鍵であることを表す。
• 数字は指数を表す。プライム付きの数字は堅牢化鍵であることを表す。0’=0x80000001である。
• m、M、数字は斜線で区切る。
• 例：m/0’/1’/0
• 根本種子の生成法はBIP39

20. Bitcoin: URI体系（URI scheme）
• BIP21
• 例：
• bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN?amount=100
• bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN?amount=.001
• bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN?amount=0.001
• bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN
• ?amount=0.10
• &label=Example+Merchant
• &message=Order+of+flowers+%26+chocolates

21. 決済手続き（payment protocol）
• BIP70、BIP71
• 拡張Bitcoin: URI体系（extended Bitcoin: URI scheme）
• bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN
• ?amount=0.10
• &label=Example+Merchant
• &message=Order+of+flowers+%26+chocolates
• &r=http://example.com/pay.php/invoice%3Dda39a3ee
• r以外は必要ないが通常は後方互換性の確保のために与えられる。
• 決済手続きに対応している財布はr以外を無視し、rに指定されているURLか
ら決済要求（payment request）を取得する。
• MIME（のContent-Type）はapplication/bitcoin-paymentrequest

23. 取引（transaction）
• 口座間におけるBitcoinの移動を表現する。
• 採掘によるBitcoinの鋳造も特殊な形式の取引として表現される。
• より具体的には、
• 1つ以上の出金口座（source account）から1つ以上の入金口座（destination account）へのBitcoinの移動を表
現する。
• 取引によって、1つ以上の入力（input）と1つ以上の出力（output）が生成される。
• 出力・・・ある口座に関連付けられているBitcoinの額面を表す。
• 出力は1回だけ使用することができる。
• 取引によって古い出力が使用され、新しい未使用の出力（unspent transaction input: UXTO）が生成される。
• 入力・・・どの（未使用の）出力を支払いに使用するかを指定する。
• 指定された出力が使用済みである場合には、取引は無効である。
• 1つの取引の中にある1つ以上の入力が指し示す古い出力の額面の合計は、新しい出力の額面の合計以
上でなければならない。
• 小さい場合には、取引は無効である。
• 古い出力と新しい出力の額面の合計の差が取引手数料（transaction fee）である。
• 高順位取引（high-priority transaction）は取引手数料を支払う必要がないが、それ以外の取引は最小手数料（minimum fee）
を支払わなければ取引が伝播されない。
• 支払人が実際に受取人に支払いたい額（に取引手数料を加えたもの）と取引入力の総額とに差がある場合
には、差額を支払人自身の口座に出力する。これを釣り銭出力（change output）と言う。

24. 取引（続き）
• 口座に出力が関連付けられる。
• 口座に関連付けられている未使用の出力の額面を合計すれば、口座残高
が求められる。
• 取引識別子（transaction identifier：TXID）
• 取引のハッシュ値。取引を識別するために使用する。

25. 取引の内容
• version・・・取引のバージョン。4バイト。
• inputs
• txid・・・入力される取引の識別子。
• output index・・・入力された取引の何番目の取引出力を使用するのか。
• sequence・・・全ての入力のsequenceが最大値である場合はlocktimeが無効となる。
• script sig
• signature・・・入力された取引出力を使用するためにはscriptの条件を充足するデータを格納しなければならない（充足するデータが格納されており、かつ、他の
要件も充足する場合にのみ、この取引は有効となる）。
• hashtype・・・取引のどの入力及び出力に署名するかを示す。
• outputs
• amount・・・入力からどれだけの数量のBitcoinを移動するか。
• script・・・未使用の取引出力を使用するための条件。次の取引入力（この取引出力を使用しようとする取引入力）にこの条件を充足するscript
sigが格納されている場合には、この取引出力が有効に使用されたことになる。
• locktime・・・特定の時間が経過するまで取引がブロック鎖に格納されないようにする。5億未満の値の場合はブロックの深さを表
す。指定された深さ以降のブロックには取引を含めることができる。5億以上の値の場合は時間を表す。指定された時刻より先
の時刻印を有するブロックには取引を含めることができる。
• scriptはForthに類似したスタック指向プログラミング言語のプログラムとして解釈される。
• 状態を有せず、Turing完全（Turing-complete）ではない（反復や無条件分岐がない）。

26. 取引の種類（標準取引（standard
transaction））
• 公開鍵ハッシュ値への支払い（pay-to-pubkey-hash：P2PH）
• ある口座から別の口座へのBitcoinの移動
• script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
• scriptSig: <sig> <pubkey>
• スクリプトハッシュ値への支払い（pay-to-script-hash：P2SH）
• script: OP_HASH160 <redeemscripthash> OP_EQUAL
• scriptSig: <sig> [sig] [sig...] <redeemscript>
• 複数署名（multisignatire）
• m-of-n
• 必要最低署名数（minimum number of signature：m）
• 公開鍵数（number of public key：n）
• script: <m> <pubkey> [pubkey] [pubkey...] <n> OP_CHECKMULTISIG
• scriptSig: OP_0 <sig> [sig] [sig...]
• 本来は不必要なのだが、バグの所為でOP_0をscriptSigの先頭に置く必要がある。
• 公開鍵
• script: <pubkey> OP_CHECKSIG
• scriptSig: <sig>
• 空データ（null data）
• 40バイトまでの任意のデータを含めることができる。
• script: OP_RETURN <data>

27. 標準取引
• 標準取引が有効となるためには次の要件を充足しなければならない。
• locktimeが過去の時刻であるか、或いは、現在のブロックの深さに等しいか、
小さくなければならない。若しくは、全てのsequenceが0xffffffffでなければな
らない。
• 100Kバイトより小さくなければならない。
• 全ての取引入力が500バイトより小さくなければならない。
• scriptSigにはデータのみしか含めることができない。即ち、単にデータをス
タックに追加する以外の演算コード（operation code）を含めることはできない。
• 最小値（minimal value）未満の数量の取引出力を含める場合には必ず最小
取引手数料（minimum transaction fee）以上を支払わなければならない。

28. 取引の種類（非標準取引（non-standard
transaction））
• 通常設定のノードは非標準取引を受信しても、受理することはなく、
他のノードに転送したり、ブロックの中に含めたりはしない。
• redeemScriptのハッシュ値からredeemScript自体の内容を知ること
はできないので、 非標準取引たるredeemScriptのハッシュ値が含ま
れる取引出力は受理される。しかしながら、取引入力に非標準取引
たるredeemScriptが含まれていても却下されるため、使用することが
できない。

29. 署名ハッシュ値の種類
• SIGHASH_ALL
• 全ての取引入力及び取引出力に署名する。
• SIGHASH_NONE
• 全ての取引入力には署名するが、取引出力には署名しない。
• SIGHASH_SINGLE
• 当該scriptSigを含む取引入力とそれに対応する取引出力（取引入力の番号と同一の番号を
有する取引出力）のみに署名する。
• SIGHASH_ALL|SIGHASH_ANYONECANPAY
• 当該scriptSigを含む取引入力と全ての取引出力に署名する。
• SIGHASH_NONE|SIGHASH_ANYONECANPAY
• 当該scriptSigを含む取引入力のみに署名する。
• SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
• 当該scriptSigを含む取引入力とそれに対応する取引出力（取引入力の番号と同一の番号を
有する取引出力）のみに署名する。

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

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

32. ブロック作成
• 暫定的に収容された取引の内、どの取引をブロックに格納するかはノードの自由裁量に任されている。ただし、現在ブロックの
大きさは1MBまでに制限されている。
• 最大ブロック量：b
• 通常、ブロックの内50KBは高順位取引のために予約されている。それ以外の部分には1バイト当たりの手数料が高い取引から順次格納され
ていく。
• ブロックを作成するには仕事証明（proof-of-work）に対する解（nonce）を発見しなければならない。
• 解は平均的には一定時間毎に、それぞれのノードの仕事に関して平等な確率で発見できるようになっている。
• hash × prob = λ = 1/600
• Poisson過程（Poisson process）
• pv >= 0, sum v in V pv = 1
• ネットワーク全体で見れば平均はλ、それぞれのノードだけで見れば平均はpv × λ
• ブロックの頭部と解を結合したもののハッシュ値の先頭何ビットかが0となるようにしなければならない（ある値以下のハッシュ値
を生成する解を発見しなければならない）。
• 解を求めるのは困難であるが、解が正当であるかを検証するのは容易である。虱潰し（brute force）に解を探索するしかない。
• ハッシュ値はブロックを識別するためにも使用される。
• ブロック作成を試みるノードを採掘者（miner）と言う。ブロック作成を採掘（mining）と言う。
• ブロックを発見した採掘者は近接ノードにブロックを送信する。ブロックを発見した採掘者を、ネットワークの観点から見て、原点（origin）と言う。
• ブロックを発見した採掘者は報酬として新たに鋳造されたBitcoinを受け取る（ただし、ブロック鎖の頭部に接続できなければならない）。
• これが、採掘者が仕事を行う動機となる。

33. 仕事証明

34. ブロック作成（続き）
• 採掘によるBitcoinの鋳造も特殊な形式の取引として表現される。
• 貨幣の素となる取引（coinbase transaction）
• 採掘者はブロックを生成する際に必ず貨幣の素となる取引を1つ含めなければなら
ない。
• この取引にはブロックに格納されている全ての取引の取引手数料も含められる。
• 貨幣の素となる取引の未使用の出力はそれが格納されているブロックから100ブ
ロック以上離れたブロックでしか使用できない。
• ブロック鎖分岐が発生している状態で使用されるのを防ぐため。
• 取引はMerkle木（Merkle tree）の葉の1つとしてブロックに格納される。
• 実際には取引そのものではなく、取引識別子。
• 2つの取引識別子の組を作り、ハッシュ値を取る。2つのハッシュ値の組を作り、ハッ
シュ値を取る。結果として生じるハッシュ値が1つだけになるまで繰り返す。
• 相手がいない取引識別子或いはハッシュ値は自己の複製と組を作り、ハッシュ値を取る。

35. 目標（target）、難易度（difficulty）
• 目標
• 有効なブロックを生成するために、どのような値となるブロックのハッシュ値を発見
しなければならないかを表す。
• あるブロックのハッシュ値が目標より大きい場合、そのブロックは無効である。
• 逆に、あるブロックのハッシュ値が目標以下である場合、そのブロックは有効になり
得る。
• 他の要件も全て充足していれば、そのブロックは有効である。
• 目標はネットワーク全体で約10分に1個のブロックが生成されるように、ノード間で
合意される
• ただし、2016ブロック毎にしか調整は行われない。
• 難易度
• 有効なブロックを作成するのがどれくらい難しいかを表す。
• 目標は2016ブロック毎に調整されるので、難易度も2016ブロック毎に変化する。
• 目標が小さい程難易度は大きい。目標が大きい程難易度は小さい。

36. 目標（難易度）の調整
• 直近2016ブロックの頭部に格納されている時刻印（timestamp）に基づき、2016ブロックの生成に要した時
間を計算する。
• 理想値は120万9600秒（2週間）である。
• 2週間より早く2016ブロック生成した場合には、ネットワークの計算能力が2016ブロック生成した期間のもの
と変わらないと仮定した場合において次の2016ブロックの生成が丁度2週間掛かるように調整する。
• ただし、3倍以上難易度が増加する場合は3倍。
• 2週間より遅く2016ブロック生成した場合には、逆に調整する。
• ただし、3/4以上難易度が減少する場合は、3/4。
• 実際には、ソフトウェアの瑕疵のため2016ブロックの生成に要した時間を計算しなければならないのが、
2015ブロックの生成に要した時間を計算してしまっていて、僅かながら仕様とはずれが生じている。
• 時間歪曲攻撃（time warp attack）の原因。
• 他の暗号貨幣では、Bitcoinのものとは異なる難易度調整の方式が採用されていることが多い。
• Kimotoの重力井戸（Kimoto gravity well：KGW）
• DigiShield
• ブロック鎖に新しいブロックが追加される度に調整する。

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

38. ブロック鎖2
• 時刻tにおけるブロック木：tree(t)
• 時刻tにおけるブロック鎖の頭部：longest(t)
• ブロックBの
• 深さ：depth(B)
• 作成時刻：time(B)
• 作成ノード：owner(B)
• 親ブロック：parent(B)
• ブロックBを根とした場合の部分木：subtree(B)
• 時刻tにおけるノードuが知っているブロック木：treeu(t)
• 起源ブロックを根とするtree(t)の部分木となる。
• 時刻tにおけるノードuが知っているブロック木の中におけるブロック鎖の頭部：longestu(t)
• ブロック鎖の長さがn-1からnへと成長するのに掛かる時間（確率変数（random variable））：τn
• ブロック鎖の長さが1成長するのに掛かる平均時間：τ = lim n --> inf 1/n sum i=1 to n τn
• ブロック鎖に新しいブロックが追加される平均速度：β = 1/E[τ]
• ブロック木に新しいブロックが追加される平均速度はλ = 1/600
• ネットワークの効率性はλとβとbによって決まる。
• 1秒当たりの取引数（transactions per second：TPS）=β(λ, b) × b × K
• 1KiB当たりの取引数：K

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

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

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

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

43. 時刻印
• ブロックの頭部にブロックを生成した時刻が時刻印として格納される。
• 2時間までならネットワーク調整時刻（network-adjusted time）より先の時
刻を格納することができる。
• ネットワーク調整時刻とは、あるノードが接続している全てのノードが返した現在時
刻の中央値。
• ノードが他のノードに接続したときには、そのノードから時刻印を取得する。この時刻印の時
刻とノード自身の時刻の差を保持しておく。
• ネットワーク調整時刻は全てのノードに関する差の中央値をノード自身の時刻に加えたもの
である。
• 但し、ノード自身の時刻より70分以上前後することはない。
• あるブロックの時刻印よりその次のブロックの時刻印が前の時刻であって
も有効なブロックとして認められる。
• ただし、直近11ブロックの中央値より前の時刻にすることはできない。

44. 時間歪曲攻撃
• ブロックの時刻印に関する要件
• 直近11ブロックの中央値より大きくなければならない。
• 実際の時刻の2時間後よりは前でなければならない。
• 目標調整間隔が4ブロックであり、新しいブロックが生成される速度が（現実ではあり得ないが）
丁度10s/blockであるとすると、
• 通常、ブロック鎖のブロックの時刻印は次のようになる。
• blk# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
• time 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150
• ソフトウェアの瑕疵のためにブロック3-4、7-8、11-12の間の時間が考慮されず、目標調整間隔も3ブロックと
見做される。
• 通常の場合には、(30-0)/3=10s/block etc.となり、特に問題はないが・・・。
• 攻撃者は次のような時刻印を有する一連のブロックによるブロック鎖を作成することができる。
• blk# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
• time 0 1 2 30 4 5 6 70 8 9 10 110 12 13 14 150
• 如上の要件を充足しているが、
• 0-3のブロック生成速度は(30-0)/3=10s/blockと計算されるが、4-7のブロック生成速度は(70-4)/3=22s/blockと計算され、8-11
のブロック生成速度は(110-8)/3=34s/blockと計算される。
• これによって、攻撃者のブロック鎖の難易度を不当に低下させることができる。

46. 取引ネットワーク（transaction network）
• 節は取引
• 有向枝は貨幣の流れ
• connected component
• giant connected component
• 99.9%の取引が属する。
• 枝の方向を無視すると殆どの取引から別の殆どの取引に到達することができる。
• diameter
• effective diameter
• 14次の隔たり。
• 任意の2つの取引の90%は距離が14以下である。
• 時間の経過と共に上昇する。
• preferential attachmentがないから。
• 苫前町地域通貨流通実験

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

49. bitcoin-qt/d/-cli
• Nakamotoによって作られた概念実証を目的とする参照実装（reference
implementation）であるが、現在でも尚最も広く使用されているクライアントである。
• bitcoin-qt
• Bitcoinネットワークの完全ノード（full node）としての役割と、財布（wallet）としての役割の両方を
担っている。
• 2つの機能を分離しようという計画がある。
• bitcoind
• 開発用途に適している。 Bitcoinネットワークの完全ノードとしての役割を果たす。
• bitcoin-cli
• コマンドラインからbitcoindにRPC命令を送信することができる。
• bitcoin.conf
• 設定ファイル

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

51. Bitcoinネットワーク
• 複数のネットワークがある。
• 主ネットワーク（mainnet）
• 価値のあるBitcoinが取引されているネットワーク。
• 試験ネットワーク（testnet）
• 価値のないBitcoinが取引されているネットワーク。開発者用。
• mainnetの制約の幾つかがない。
• bitcoind/biutcoin-qt/bitcoin-cliでは-testnetを指定して起動すれば、testnetに接続され
る。或いは、bitcoin.confにtestnet=1を追加する。
• regression test mode
• ローカルな環境に独立したtestnetを作る。

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

54. Bitcoinの応用
• 第三者預託取引（escrow transaction）
• 支払い人、受け取り人、調停者の内2人以上が取引入力に署名した場合のみ有効な取引となる。支払い人と受け取り人が合意すれば、調停者を変更することができる。
• 小額決済手段（micropayment channel）
• 保証金取引（bond transaction）と返金取引（refund transaction）の組み合わせ。
• CoinJoin
• 複数の参加者の入力から等しい割合を出力する取引。
• 購入者で行うCoinJoin（purchaser CoinJoin）
• 複数の（典型的には物品を購入しようとしている）参加者の入力を別々の商人の口座に出力する取引。
• 即ち、CoinJoinと物品の購入1つの取引で実行する。そのため、取引手数料の節約となる。
• 電子財産（smart property）
• 電子契約（smart contract）
• 賭博
• 共同預金口座
• 金融市場
• 信託基金
• 自律型代行プログラム（autonomous agent）
• 分散型自治体（decentralized/distributed autonomous organization：DAO）
• BitcoinそのものもDAOであるという考え方がある。
• decentralized Dropbox

55. Bitcoinの応用2
• 双方向の固定（two-way pegging）
• 副ブロック鎖（side chain）を作る。
• 主ブロック鎖（main chain）と副ブロック鎖の間で貨幣を移動できるようにする。
• 電子契約
• 私的ブロック鎖（private chain）
• 安全性の防壁（security firewall）
• 副ブロック鎖での安全性の瑕疵が主ブロック鎖に影響しないこと。

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

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

59. 拡張性の問題を改善する
• 簡易決済検証（simplified payment verification：SPV）
• SPVノードはブロックの頭部のみ取得し、ブロックが鎖状に接続されているか
確認し、ブロックの難易度が十分に高いかどうか確認する。
• 確認したい取引が格納されているブロックのMerkle木の一部（根から取引識
別子に至るまでの中間ハッシュ値）のみを取得して取引がブロックに含まれ
ているかどうか確認する。
• 十分に古いブロックの頭部は取得せず、十分に古くなったブロックの頭部は
破棄する。
• つまり、ブロック鎖全体を取得しなくても取引がブロックに含まれているかを
確認することができる！！

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

61. 拡張性の問題を改善する
• 安全性の水準
• 水準4：クライアントは未使用の取引出力木を保持せず、サーバが保持しているも
のを信用する。
• 水準3：簡易決済検証
• 水準2：強化された簡易決済検証（enhanced simplified payment verification：SPV+）
• ブロック鎖には未使用の取引出力木の根のハッシュ値が含まれる。
• クライアントは自身に関連する未使用の取引出力を問い合わせ、包含証明付きの未使用の
取引出力の一覧を取得する（或いは、関連する未使用の取引出力が存在しないという証明
を取得する）。
• 水準1：最初に古い未使用の取引出力木やブロック鎖を他のノードからダウンロード
し、矛盾がないことを検証し、それ以降の未使用の取引出力木やブロック鎖は自ら
構築する。
• 水準0：ブロック鎖の起源ブロックから最新のブロックまで全てを自ら構築する。

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

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

64. 匿名性を向上させるには？
• Torを利用する。
• CoinJoin
• 購入者で行うCoinJoin
• 結合回避（merge avoidance）
• 秘密の口座番号（stealth address）
• 受け取り人のみが認識することのできる暗号化された口座番号。
• ブロック鎖だけでは支払い人と受け取り人を結び付けることができない。

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

67. 類似貨幣（altcoin）
• ブロック鎖に基づいた初期貨幣頒布（blockchain-based initial coin
distribution）
• ある貨幣の保有率と同一の初期保有率となるように別の貨幣を初期入手で
きる貨幣の頒布方式。
• 最初から多くの使用者を獲得することができる。
• 基にした貨幣の投資家を巻き込むことができる。
• 貨幣の時価総額は使用者数の2乗に比例する。
• Metcalfeの法則（Metcalfe‘s law）の一種と考えられる。

69. proof of
• 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 existence
• proof of excellence
• proof of storage
• proof of bandwidth
• proof of identity
• proof of identification
• proof of publication
• proof of solvency
• proof of security
• Decentralized Anonymous Credentials：
https://eprint.iacr.org/2013/622.pdf

70. Bitcoin関連論文1
• [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

71. Bitcoin関連論文2
BITCOIN 14 workshop
• “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.

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

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

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

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

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

77. Information Propagation in the Bitcoin
Network 6
• 伝播遅延には悪影響が多い。
• 何とかして伝播遅延をできる限り小さくしよう！

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

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

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

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

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

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

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

86. 分散ハッシュテーブル（distributed hash
table：DHT）

87. Kademlia1
• 分散ハッシュテーブル
• 鍵空間は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)（三角不等式）

88. Kademlia2
• ノードは他のノードの情報を保持する。
• ノード情報：（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つ識別子を
生成し、ノード探索を実行する。

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

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

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