Bitcoinの個人的勉強ノート第3版（2015年1月4日）

Bitcoinの個人的勉強ノート
第3版（2015年1月4日）
@pizyumi

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

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

電子貨幣
2014/11/30更新
• 発行者に依存するもの：集中型
• David Chaum. Blind signatures for untraceable payments. In Crypto, volume 82, page
199203, 1982.
• 不視署名（blind signature）
• 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.
• 集中型の電子貨幣系の単一障害点を分散化するには閾値署名
（threshold signature）の導入などが考えられる。
• 使用者間の貸借関係によるもの
• Ryan Fugger. Money as ious in social trust networks & a proposal for a decentralized
currency network protocol. 2004.

Bitcoinとは
2014/11/30更新
• 電子貨幣（digital currency）システムである。
• 最初の完全な分散型（純粋P2P型）の電子貨幣システムである。
• 従来の電子貨幣システムは集中型（クライアントサーバ型）であった。
• 中央機関の署名を分散型の合意形成系で置き換えた。
• 信頼が存在しない（trustless）
• 暗号貨幣（cryptocurrency）システムである。
• 暗号学的な仕組みによって電子貨幣システムを実現する。
• 全てのノードが完全な元帳を保持する。
• ノードが取引を検証する。
• 現金に近い。
• 取引はほぼ即時に処理される。
• 払い戻し不可能（non-refundable）である。
• 現金でできることが世界規模で行える！
• 2008年に始動。オープンソース。
• 価格は急激に上昇。取引数も急激に上昇。
• 価格は一時1BTC1000ドル超え。取引数は1日6万件程度（1秒間に0.7件）。
• クレジットカード取引などと比較するとまだまだ小規模。

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

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

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

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

信頼の不存在（trustlessness）
2014/11/01作成
• 信頼の不存在とは情報の正否を判断する上で他者の何らかの振る舞い（判断）に依拠しないと
いうこと。
• 全ての情報の正否の判断を自己のみで行う状態。
• 純粋P2Pでは基本的に他のノードの振る舞い（判断）を信頼することはできない。
• 然し、一切の信頼がなければ2つの競合する取引の何れを有効なものとして採用するかネット
ワーク上で意見を一致させることができない。
• 2つの競合する取引A, Bが現れた時点で、ネットワークの中でAを採用するノードとBを採用するノードに分か
れてしまったら、そのままネットワークが分裂するということになってしまう。
• 他のノードの振る舞いは信頼できないが、多量の計算を行ったという事実は信頼できるよね（信
頼に値するよね）？というのがBitcoin
• （確率的に）多量の計算を行わないと生成できない筈のものが存在する＝（確率的に）多量の計算を行った
者がいるというのは事実
• この信頼に値するであろう事実に基づいて合意形成しようじゃないか！
• 勿論、それぞれのノードは信頼しないという選択もできる。
• 然し、信頼しなければ合意形成できない。通常、合意形成していない状態と合意形成している状態では合意形成している状
態の方が利益が大きい（効用が大きい）。
• 信頼に値するであろう事実に基づくなら合意形成した方が得
• という誘因が働く。

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

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

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

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

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

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

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

階層的決定論的鍵生成（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ビッ
トが最初の秘密鍵である。

階層的決定論的鍵生成（承前）
• 根本種子から生成される最初の連鎖コードを最上連鎖コード（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

階層的決定論的複数鍵（hierarchical
deterministic multisignature：HDM）
2014/06/05作成
• 複数鍵を作るのに階層的決定論的鍵生成を用いる。
• 複数の（複数鍵の鍵の個数と同数の）根本種子を用いる。

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

決済手続き（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

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

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

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

取引の検証
2014/12/03作成
• 取引の検証で最も重要なのはスクリプトの検証。
• スクリプトの検証によって貨幣の正当な所有者が取引を実行していることを確認す
る。
• スクリプトの検証
• 被参照取引出力の公開鍵スクリプト（pubkey script）と取引入力の署名スクリプト
（signature script）を使ってスクリプトの検証を行う。
• 取引入力の署名スクリプトの後に被参照取引出力の公開鍵スクリプトを繋げる。
• これがスクリプト。
• つまり、署名スクリプトや公開鍵スクリプトはスクリプトの一部でしかない。
• スクリプトを評価した結果が1（真）ならばスクリプトは有効。
• 評価方法は取引の種類によって異なる。
• 取引の検証にはスクリプトの検証以外にも幾つかある。

取引の種類（標準取引（standard transaction）） 1
2014/12/03更新
• 公開鍵要約値への支払い（pay-to-pubkey-hash：P2PKH）
• ある口座から別の口座へのBitcoinの移動
• 公開鍵スクリプト
• OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
• <PubKeyHash>は被参照取引出力が所属する口座の公開鍵の要約値＝口座番号
• 署名スクリプト
• <Sig> <PubKey>
• <Sig>は被参照取引出力が所属する口座の秘密鍵による署名
• <PubKey>は被参照取引出力が所属する口座の公開鍵

取引の種類（標準取引） 2
2014/12/03作成
• 公開鍵要約値への支払いのスクリプトの検証
• スクリプト（取引入力の署名スクリプトの後に被参照取引出力の公開鍵スクリプトを繋げたもの）
• <Sig> <PubKey> OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
• これを評価する。公開鍵要約値への支払いのスクリプトの場合はスクリプトをそのままスタック機械（stack
machine）で評価するだけ。
• 1.<Sig>がスタックに積まれる。この時点でのスタックの内容は（上から）<Sig>
• 2.<PubKey>がスタックに積まれる。この時点でのスタックの内容は（上から）<PubKey> <Sig>
• 3.OP_DUP命令が実行される。即ち、スタックの一番上にある<PubKey>が複製されてスタックに積まれる。この時点でのスタッ
クの内容は（上から）<PubKey> <PubKey> <Sig>
• 4.OP_HASH160命令が実行される。即ち、スタックの一番上にある<PubKey>がSha256Ripemd160要約値に変換される。この
時点でのスタックの内容は（上から）<PubKeyHash> <PubKey> <Sig>
• 5.<PubKeyHash>がスタックに積まれる。この時点でのスタックの内容は（上から）<PubKeyHash> <PubKeyHash> <PubKey>
<Sig>
• 6.OP_EQUALVERIFY命令が実行される。OP_EQUALVERIFY命令はOP_EQUAL命令とOP_VERIFY命令に分解される。
• OP_EQUAL命令によって、スタックの一番上とその下にある<PubKeyHash> <PubKeyHash>が取り出され、同等かどうか比較され、
同等な場合は1（真）がスタックに積まれ、同等でない場合は0（偽）がスタックに積まれる。
• OP_VERIFY命令によって、スタックの一番上にある値が0（偽）である場合には検証を終了し、検証結果は無効となる。1（真）であ
る場合にはスタックの一番上にある1（真）が取り出される。この時点でのスタックの内容は（上から）<PubKey> <Sig>
• 7.OP_CHECKSIG命令が実行される。即ち、スタックの一番上とその下にある<PubKey> <Sig>により署名検証が行われ、署名が
正当な場合は1（真）がスタックに積まれる。
• 8.スクリプトの終端に到達し、スクリプトの評価が完了した。スタックの一番上にある値が1（真）ならば取引入力は有効である。

2014/12/04更新
• スクリプト要約値への支払い（pay-to-script-hash：P2SH）
• 公開鍵要約値の代わりに解放スクリプト（redeem script/redemption script）
の要約値を使うもの。
• OP_HASH160 <RedeemScriptHash> OP_EQUAL
• <RedeemScriptHash>は解放スクリプトの要約値
• <sig> [sig] [sig...] <RedeemScript>
• <RedeemScript>は解放スクリプト

2014/12/05作成
• スクリプト要約値への支払いのスクリプトの検証
• スクリプト（取引入力の署名スクリプトの後に被参照取引出力の公開鍵スク
リプトを繋げたもの）
• <sig> [sig] [sig...] <RedeemScript> OP_HASH160 <RedeemScriptHash> OP_EQUAL
• これを評価する。スクリプト要約値への支払いのスクリプトの場合はスクリプ
トをそのまま（解放スクリプトは一塊の値として）スタック機械（stack machine）
で評価した後に、解放スクリプトを（一塊の値としてではなく分解して）評価す
る。

2014/12/06作成
• 例：1つの署名を必要とするスクリプト要約値への支払いによる取引
• 解放スクリプト
• <PubKey> OP_CHECKSIG
• OP_HASH160 <Hash of {<PubKey> OP_CHECKSIG}> OP_EQUAL
• <Hash of {<PubKey> OP_CHECKSIG}>は{<PubKey> OP_CHECKSIG}の要約値＝スクリプト要約値
• <Sig> {<PubKey> OP_CHECKSIG}
• <Sig>は公開鍵に対応する秘密鍵による署名
• <PubKey>は公開鍵
• スクリプト（取引入力の署名スクリプトの後に被参照取引出力の公開鍵スクリプトを繋げたもの）
• <Sig> {<PubKey> OP_CHECKSIG} OP_HASH160 <Hash of {<PubKey> OP_CHECKSIG}> OP_EQUAL
• これを評価する。
• 1.<Sig>がスタックに積まれる。この時点でのスタックの内容は（上から）<Sig>
• 2.{<PubKey> OP_CHECKSIG}がスタックに積まれる。この時点でのスタックの内容は（上から）{<PubKey> OP_CHECKSIG} <Sig>
• 3.OP_HASH160命令が実行される。即ち、スタックの一番上にある{<PubKey> OP_CHECKSIG}がSha256Ripemd160要約値に変換される。この時点でのスタックの内容は（上から）
<Hash of {<PubKey> OP_CHECKSIG}> <Sig>
• 4.<Hash of {<PubKey> OP_CHECKSIG}>がスタックに積まれる。この時点でのスタックの内容は（上から）<Hash of {<PubKey> OP_CHECKSIG}> <Hash of {<PubKey> OP_CHECKSIG}>
<Sig>
• 5.OP_EQUALVERIFY命令が実行される。即ち、スタックの一番上とその下にある<Hash of {<PubKey> OP_CHECKSIG}> <Hash of {<PubKey> OP_CHECKSIG}>が取り出され、同等か
どうか比較され、同等な場合は1（真）がスタックに積まれ、同等でない場合は0（偽）がスタックに積まれる。
• 6.スクリプトの終端に到達し、スクリプト全体の評価が完了した。スタックの一番上にある値が0（偽）である場合には検証を終了し、検証結果は無効となる。1（真）である場合に
はスタックの一番上にある1（真）が取り出される。この時点でのスタックの内容は（上から）<Sig>
• 7.解放スクリプトの評価に入る。<PubKey>がスタックに積まれる。この時点でのスタックの内容は（上から）<PubKey> <Sig>
• 8.OP_CHECKSIG命令が実行される。即ち、スタックの一番上とその下にある<PubKey> <Sig>により署名検証が行われ、署名が正当な場合は1（真）がスタックに積まれる。
• 9.解放スクリプトの終端に到達し、解放スクリプトの評価が完了した。スタックの一番上にある値が1（真）ならば取引入力は有効である。

2014/12/06作成
• 複数署名（multisignature）
• m-of-n
• 必要最低署名数（minimum number of signature：m）
• 公開鍵数（number of public key：n）
• スクリプト要約値への支払いを用いない場合
• <m> <PubKey1> [PubKey2] [PubKey3...] <n> OP_CHECKMULTISIG
• OP_0 <Sig1> [Sig2] [Sig3...]
• スクリプト要約値への支払いを用いる場合
• 解放スクリプト
• <m> <PubKey1> [PubKey2] [PubKey3...] <n> OP_CHECKMULTISIG
• OP_HASH160 <Hash of {<m> <PubKey1> [PubKey2] [PubKey3...] <n> OP_CHECKMULTISIG}> OP_EQUAL
• OP_0 <Sig1> [Sig2] [Sig3...] {<m> <PubKey1> [PubKey2] [PubKey3...] <n> OP_CHECKMULTISIG}
• 単一署名と比較して、基本的には公開鍵や署名の数が複数になったというだけ。
• 本来は不必要なのだが、瑕疵の所為でOP_0をscriptSigの先頭に置く必要がある。

• 公開鍵
• <pubkey> OP_CHECKSIG
• <sig>
• 空データ（null data）
• 40バイトまでの任意のデータを含めることができる。
• OP_RETURN <data>

標準取引/超準取引（non-standard transaction）
2014/12/06更新
• スクリプト機能は標準的なものと超準的なものに大別される。
• 標準的なスクリプト機能のみを使用する取引を標準取引と言う。超準的なスクリプト機能を使用する取引を超準取引と言う。
• 標準的な設定のノードは超準取引を受信しても、受理することはなく、他のノードに転送したり、ブロックの中に含めたりはしない。
• 超準的な設定のノードは超準取引を受理する可能性を有し、他のノードに転送したり、ブロックの中に含める可能性がある。
• つまり、超準取引は無視される可能性がある。
• ブロックに超準取引が含められた場合は標準的な設定のノードも有効な取引と承認する。
• 標準取引が有効となるためには次の要件を充足しなければならない。
• locktimeが過去の時刻であるか、或いは、現在のブロックの高さに等しいか、小さくなければならない。若しくは、全てのsequenceが0xffffffffで
なければならない。
• 100Kバイトより小さくなければならない。
• 全ての取引入力が500バイトより小さくなければならない。
• 署名スクリプトにはデータのみしか含めることができない。即ち、単にデータをスタックに追加する以外の演算コード（operation code）を含め
ることはできない。
• 最小値（minimal value）未満の数量の取引出力を含める場合には必ず最小取引手数料（minimum transaction fee）以上を支払わなければな
らない。
• 解放スクリプトはそれ自体が標準的でなければならない。
• 解放スクリプトの要約値から解放スクリプト自体の内容を知ることはできないので、超準的な解放スクリプトの要約値が含まれる
取引出力は標準的な設定のノードにも受理される。しかしながら、取引入力に超準的な解放スクリプトが含まれていても標準的
な設定のノードには却下されるため、（超準的な設定のノードによってブロックに含められない限り）使用することができない。

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

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

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

ブロック作成
2014/12/06更新
• 新しい取引を作成したノード（原点（origin）と言う）はその取引を近接ノードに送信し、近
接ノードは更にその近接ノードに送信し、新しい取引は最終的にネットワーク全体に伝
播される。
• ノードが受信した新しい取引は記憶領域（mempool）に暫定的に収容されるが、ある期
間が経過するまでにブロックに格納されなかった場合には破棄される。
• 破棄された場合には、原点は取引を再度伝播させなければならない。
• 暫定的に収容された取引の内、どの取引をブロックに格納するかはノードの自由裁量
に任されている。ただし、現在ブロックの大きさは1MBまでに制限されている。
• ブロックの大きさ：b
• 通常、ブロックの内50KBは高順位取引のために予約されている。それ以外の部分には1バイト当
たりの手数料が高い取引から順次格納されていく。
• 他にはブロック（の取引のスクリプト）に含めることのできる署名演算（signature operation）にも上
限（20000）が設定されている。
• OP_CHECKSIG及びOP_CHECKSIGVERIFY は1署名演算。
• OP_CHECKMULTISIG及びOP_CHECKMULTISIGVERIFY20署名演算。
• ただし、スクリプト要約値への支払いの場合は夫々OP_1、OP_2、・・・、OP_16の後にあるものに限っては夫々1、2、・・・、
16署名演算。

ブロック作成2
• ブロックを作成するには仕事証明（proof-of-work）に対する解（nonce）を発見しなければならない。
• ブロックの頭部と解を結合したものの要約値の先頭何ビットかが0となるようにしなければならない（ある値以下の要約値を生成する解を発見
しなければならない）。
• ある値以下の要約値は解に関してほぼ一様に分布している筈なので、平均的には発見された解の半分はある値の半分以下となるし、発見された解の3分の1
はある値の3分の1以下となる。一般に、発見された解の1/nはある値の1/n以下となる。
• 即ち、解は平均的には一定時間毎に、夫々のノードの仕事に関して平等な確率で発見できるようになっている。
• hashrate[h/s] × prob[block/h] = λ[block/s] = 1/600[block/s]
• 600[s/block]
• hashrateはネットワーク全体の要約値計算能力（hashing power）。採掘能力（mining power）とも言う。probはブロック生成成功確率。λは平均
ブロック生成速度。
• ネットワーク上の夫々のノードの要約値計算能力の占有率をp_1, p_2, …,p_nとすると総和sum p_i = 1
• 従って、ネットワーク上の夫々のノードの平均ブロック生成速度はp_i × λ
• 解を求めるのは困難であるが、解が正当であるかを検証するのは容易である。解は虱潰し（brute force）に探索するしかない。
• 要約値はブロックを識別するためにも使用される。
• ブロック作成を試みるノードを採掘者（miner）と言う。ブロック作成を採掘（mining）と言う。
• ブロックを発見した採掘者は近接ノードにブロックを送信する。ブロックを発見した採掘者を、ネットワークの観点から見て、原点と言う。
• ブロックを発見した採掘者は報酬として新たに鋳造されたBitcoinを受け取る（ただし、ブロック鎖の頭部に接続できなければならない）。
• これが、採掘者が仕事を行う動機となる。

ブロック作成3
2014/11/22更新
• 採掘によるBitcoinの鋳造も特殊な形式の取引として表現される。
• 貨幣の素となる取引（coinbase transaction/generation transaction）
• 取引入力を有せず、1つ以上の取引出力を有する。
• データとしては1つの取引入力を有するが、意味のないデータである。
• txidは00…00でoutput indexは0xFFFFFFFF
• 2から100バイトの仕事証明の追加の解（extranonce）を有する。
• script sigとして格納されるが、任意のデータなのでscriptとして解釈できる訳ではない。
• 採掘者はブロックを生成する際に必ず貨幣の素となる取引を1つ含めなければならない。
• 採掘者は貨幣の素となる取引を含めることによってブロック（或いは、ブロックを生成するために要した計算能力）に署名している。
• この取引にはブロックに格納されている全ての取引の取引手数料も含められる。
• 貨幣の素となる取引の未使用の出力はそれが格納されているブロックから100ブロック以上離れたブロックでしか使用でき
ない。
• ブロック鎖分岐が発生している状態で使用されるのを防ぐため。
• 取引はMerkle木（Merkle tree）の葉の1つとしてブロックに格納される。
• 実際には取引そのものではなく、取引識別子。
• 2つの取引識別子の組を作り、ハッシュ値を取る。2つのハッシュ値の組を作り、ハッシュ値を取る。結果として生じるハッ
シュ値が1つだけになるまで繰り返す。
• 相手がいない取引識別子或いはハッシュ値は自己の複製と組を作り、ハッシュ値を取る。

目標（target）、難易度（difficulty）
2014/06/20更新
• 目標
• 有効なブロックを生成するために、どのような値となるブロックのハッシュ値を発見しなければならないかを
表す。
• あるブロックのハッシュ値が目標より大きい場合、そのブロックは無効である。
• 逆に、あるブロックのハッシュ値が目標以下である場合、そのブロックは有効になり得る。
• 他の要件も全て充足していれば、そのブロックは有効である。
• 目標はネットワーク全体で約10分に1個のブロックが生成されるように、ノード間で合意される。
• ただし、2016ブロック毎にしか調整は行われない。
• ブロックの目標値は4バイトの小型形式（compact format）でブロックの頭部に格納される。
• （256ビットの）目標値を256進数で表す。
• 最初の桁が127より大きい場合には、先頭に（256進数の）0を追加する。
• 256進数の目標値の桁数（先頭に0が追加された場合はその0も含む）が小型形式の最初のバイトである。
• 残りの3つのバイトは256進数の目標値の最初の3桁（先頭に0が追加された場合はその0も含む）である。桁が足りない場合
には（桁数が1か2の場合には）、残ったバイトには0を格納する。
• 難易度
• 有効なブロックを作成するのがどれくらい難しいかを表す。
• 目標は2016ブロック毎に調整されるので、難易度も2016ブロック毎に変化する。
• 目標が小さい程難易度は大きい。目標が大きい程難易度は小さい。

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

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

ブロック鎖2
• 時刻tにおけるブロック木：tree(t)
• 時刻tにおけるブロック鎖の頭部：longest(t)
• ブロックBの高さ：depth(B)、作成時刻：time(B)、作成ノード：owner(B)、親ブロック：parent(B)
• ブロックBを根とした場合の部分木：subtree(B)
• ブロックBの子ブロックの集まり：Childrem(B)
• 時刻tにおけるノードuが知っているブロック木：treeu(t)
• 起源ブロックを根とするtree(t)の部分木となる。
• 時刻tにおけるノードuが知っているブロック木の中におけるブロック鎖の頭部：longestu(t)
• 親ブロック選択方針（parent selection policy）：su(treeu(t))=longestu(t)
• ブロック鎖の長さがn-1からnへと成長するのに掛かる時間（確率変数（random variable））：τn
• ブロック鎖の長さが1成長するのに掛かる平均時間：τ = lim n --> inf 1/n sum i=1 to n τn
• ブロック鎖に新しいブロックが追加される平均速度（平均ブロック鎖成長速度）：β = 1/E[τ]
• ブロック木に新しいブロックが追加される平均速度（平均ブロック生成速度）はλ = 1/600
• ブロック鎖の成長速度はブロック生成速度とブロックの大きさに依存する。
• 更には、ネットワークの形状とノード間の遅延と要約値計算能力の分布に依存する。

ブロック鎖3
• ネットワークの効率性はλとβとbによって決まる。
• 1秒当たりの取引数（transactions per second：TPS）=β(λ, b) × b × K
• 1KiB当たりの取引数：K
• ノード間の遅延はb（ブロックの大きさ）に依存する。
• d = d(b)
• そもそもβの値とλの値が異なるのは何故なのか？
• βの値は必ずλの値より小さくなる。この差は、新たに生成されるブロックが全てブロック鎖の一部
になる訳ではないということから生じる。
• ブロック鎖分岐が発生した場合には、最終的には何れか1つの分岐が最長のものとなり、それが
有効なものとしてブロック鎖として確定し、それ以外は無効なものとして破棄される。
• 幾らかの確率でブロックの破棄が発生するために、平均的なブロック鎖成長速度は平均的なブ
ロック生成速度より必ず遅くなる。
• そして、この差を求めるためには、ブロックが破棄される確率を求めなければならない。

ブロック鎖の役割
2014/11/30更新
• 1.取引の順番を決定する。
• 2.要約値計算能力による安全性を提供する。
• 要約値は誓約（commitment）
• 3.口座残高を管理する。
• これらの3つの役割を全て担っているのがブロック鎖。

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

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

歴史改変攻撃（history-revision attack）
2014/07/11作成
• 改変したいブロックbdから改変ブロックbd’を生成し、改変ブロックに接続する新し
いブロックを現在のブロック鎖の長さを越えるまで生成していけば、 bd’を通る道
が新しいブロック鎖となる。
• 通常は不可能
• 難易度的に最長の新しいブロック鎖を単独で作るのは、通常は不可能。
• だが、ネットワークの要約値計算能力の多くの部分を支配している場合には、
可能性はある。
• 51%攻撃（51% attack）

51%攻撃
2014/06/11更新
• あるノードがネットワークの要約値計算能力の多くの部分を支配している場合には、そのノードは平均的に
はネットワークの残りの全てのノードが全体として新しいブロックを発見するより早く別の新しいブロックを発
見することができるので、任意の取引を取り消すことができる。
• 取り消したい取引が含まれるブロックbdからその取引を除いた別の新しいブロックbd’を生成し、その新しいブロックに接続
する新しいブロックを現在のブロック鎖の長さを越えるまで生成していけば、 bd’を通る道が新しいブロック鎖となる。
• 1ノードである必要はなく、複数のノードが共謀しても良い。
• 他の採掘者の採掘を阻止することもできる。
• 攻撃者と他の採掘者の採掘競争となった場合には、最終的には必ず攻撃者が勝利する。
• 攻撃者がネットワークの要約値計算能力の多くの部分を支配している限りは、何時までも攻撃者のみが採掘報酬と取引
手数料を獲得する。
• どの取引を承認し、どの取引を棄却するかの選択権を獲得する。
• 攻撃者のみが採掘に成功することになるため。
• 攻撃者の口座以外の口座の残高を自在に操作することはできない。
• 採掘以外で新しい貨幣を生成することはできない。

51%攻撃（承前）
2014/07/11更新
• 51%攻撃と呼ばれることが多いが、実際には過半数より若干少ない
割合でも攻撃は可能である。
• ネットワークの伝播遅延等により、一部の要約値計算能力は無駄になって
いるため（破棄ブロックを生成するために実行された計算は結果的に無駄と
なる）。
• 過半数を超えれば51%攻撃の成功は100%保証される（但し、どれだけの時
間で成功するか、延いては、どれだけの資金投入で成功するかは確率的）。
• 勿論、継続的に過半数を超えなければならない。そのため、難易度が上昇している場
合より、低下している場合の方が容易である。

ブロックの検証
2014/05/30作成
• 高さHのブロックの前に本当にH個の有効なブロックがあるか確認す
ることをブロック高さ検証（block height verification）と言う。
• 深さDのブロックの後に本当にD個の有効なブロックがあるか確認す
ることをブロック深さ検証（block depth verification）と言う。
• Dを確証度（confirmation）と言う。

確証度
• 総当たり攻撃（brute force attack）
• 取り消したい取引が含まれるブロックbdからその取引を除いた別の新しいブロックbd’を生成し、その新しいブロックに接続する新しいブロック
を現在のブロック鎖の長さを越えるまで生成していけば、 bd’を通る道が新しいブロック鎖となる。
• ネットワークの要約値計算能力の多くの部分を支配していない限り、取引が発生してから時間が経過する程、本来正当なブロック鎖の長さが
長くなっていくので、別の分岐によって追い付くのが難しくなり、51%攻撃を成功させるのに掛かる費用も高くなる。
• ギャンブラーの破産問題（gambler's ruin problem）
• 取引を転覆する（二重消費攻撃を実行する）のにどれだけのブロックを生成しなければならないか。
• 確証度が高い程取引は指数関数的に転覆され難くなる。
• 確証度0：取引は未だブロックに含められていない。確実な取引として信用してはならない。
• 確証度1：取引は最新のブロックに含められている。二重消費攻撃の実現性はかなり低下するが、偶発的なブロック鎖分岐が発
生している蓋然性も高いので、確実な取引として信用することはできない。
• 確証度2：取引は最新のブロックより1つ前のブロックに含められている。2ブロック以上の長さのブロック鎖分岐が発生する蓋然
性はかなり低く、二重消費攻撃も極めて困難である。ある程度確実な取引として信用することができる。
• 確証度6：ほぼ確実な取引として信用することができる。Bitcoinの仕組みに二重消費攻撃の実行に悪用できるような欠陥がない
限り、現実的に二重消費攻撃を実行することはできない。
• ブロック（取引）確証度熟成期間（confirmation time）

様々な攻撃
2014/06/04作成
• 競争攻撃（race attack）
• 確証度が0の取引を信用する者に対する攻撃。
• 自身の所有する貨幣を自分自身に送金する取引と攻撃対象に送金する取引の2つを作成し、攻撃対象のノードには後者を送信し、ネット
ワークの他の多くのノードには前者を送信する。確証度が0の矛盾する2つの取引が存在する場合には、通常最初に受信した取引が有効（で
ある蓋然性が高い）と見做されるため、攻撃対象以外のノードは前者を有効である（蓋然性が高い）と見做し、ブロックに格納し、採掘が行わ
れ、最終的に前者が有効となる（蓋然性が高い）。
• Finney攻撃／ブロック保留攻撃（Finney attack/block withholding attack）
• 自身の所有する貨幣を自分自身に送金する取引を含むブロックを先に作成し、同一の貨幣を攻撃対象に送金する取引をネットワークに公開
してから、先に作成していたブロックを公開する。結果として、自分自身に送金する取引が有効となり、攻撃対象に送金する取引は無効となり、
破棄される。
• Vector76攻撃／確証度1における攻撃（Vector76 attack/1 confirmation attack）
• 競争攻撃とFinney攻撃の組み合わせ。
• 鍵推測／衝突攻撃（key guessing/collision attack）
• 口座に結び付けられている秘密鍵が分かれば、口座が保持している貨幣を自由に使用することができる。
• 基盤攻撃（infrastructure attack）
• Bitcoinの埒外での攻撃。
• 取引所への攻撃など。

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

時間歪曲攻撃
• ブロックの時刻印に関する要件
• 直近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と計算される。
• これによって、攻撃者のブロック鎖の難易度を不当に低下させることができる。

検問所（checkpoint）
2014/05/28作成
• ブロック鎖のブロックの中で十分古いものの幾つかは、要約値がクライアント
（client）に直接書き込まれている。
• 最後の検問所以前のブロック鎖は完全に確定したものとして変更できない（仮
に最後の検問所より前のブロックから分岐を作って最長のブロック鎖を作ること
ができたとしても、有効なブロック鎖とはならない）。
• 検問所以前のブロックに格納されている取引に対して51%攻撃を実行することは不可能。
• 起源ブロックから難易度1のブロックを繋げていき、そのブロックを攻撃対象のノードに送り
付けて攻撃対象の計算機資源を奪うようなDOS攻撃も不可能。
• 新しい検問所を追加するためにはクライアントを更新する必要がある。
• 長期間クライアントが更新されなければ、51%攻撃に対してより脆弱になる。
• 良い検問所である条件
• 妥当な時刻印を有する。
• 未知の取引を含まない。

高度な検問所の作成（advanced checkpointing：
ACP）
2014/05/28作成
• 検問所をクライアントに直接書き込むのではなく、最上ノード（master
node）が配信する。
• 新しい検問所を追加するのにクライアントを更新する必要がない。

手続きの更新
2014/05/26作成
• Bitcoin手続きを更新する必要が生じたときどうするか。
• 硬質分岐（hard fork）
• 従前の手続きにおいては無効なブロックや取引が有効になる更新（によって引き起こされるブロック鎖の分岐）。
• ブロックや取引が有効となる要件を緩める手続きの更新（ｒｙ。
• ブロックの大きさの最大値の引き上げ、ブロックの大きさの最大値の自動調整、ブロックの構造の変更、ブロックの要約値計算方法の変更、難易度算出方法
の変更、取引が有効となる条件の変更は基本的に硬質分岐を引き起こす。
• 全ての使用者がクライアントを新たな手続きに対応したものに更新する必要がある。
• 既存のブロックとは独立した変更でどうしても硬質分岐を起こしたくない場合は、別のブロック鎖（alt-chain）を新設して並行採掘（merged
mining）を行うという方法も考えられなくはない。
• 軟質分岐（soft fork）
• 従前の手続きにおいては有効なブロックや取引が無効になる更新（によって引き起こされるブロック鎖の分岐）。
• ブロックや取引が有効となる要件を厳しくする手続きの更新（ｒｙ。
• 採掘者の過半数がクライアントを新たな手続きに対応したものに更新しさえすれば更新が実現する。
• 望ましい更新の手順
• ブロックと取引のバージョン番号を上げる。新しいクライアントは新しいバージョン番号のブロックや取引を作成する。
• ブロック鎖の直近1000ブロックの75%未満が新しいバージョンのものである場合には、古い手続きを適用する。
• 75%規則（75% rule）：ブロック鎖の直近1000ブロックの75%以上が新しいバージョンのものである場合には、古いバージョンを有するものに対
しては古い手続きを適用し、新しいバージョンを有するものに対しては新しい手続きを適用する。
• 95%規則（95% rule）（復帰不能点（point of no return））：ブロック鎖の直近1000ブロックの95%以上が新しいバージョンのものである場合には、
新しい手続きを適用する。

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

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

設定値
2014/06/12作成
• MAX_BLOCK_SIZE = 1000000：ブロックの大きさの最大値
• DEFAULT_BLOCK_MAX_SIZE = 750000
• DEFAULT_BLOCK_MIN_SIZE = 0
• DEFAULT_BLOCK_PRIORITY_SIZE = 50000：ブロックの中で高順位取引に与えられる領域の最大値
• MAX_STANDARD_TX_SIZE = 100000：取引の大きさの最大値
• MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50：ブロック内の署名の数の最大値
• MAX_ORPHAN_TRANSACTIONS = MAX_BLOCK_SIZE/100
• DEFAULT_MAX_ORPHAN_BLOCKS = 750
• MAX_BLOCKFILE_SIZE = 0x8000000：ブロックを保存する夫々のファイルの大きさの最大値（128MiB）
• BLOCKFILE_CHUNK_SIZE = 0x1000000
• UNDOFILE_CHUNK_SIZE = 0x100000
• COINBASE_MATURITY = 100：新しい貨幣を生成する取引に含まれる取引出力が使用できるようになるまでのブロック数（新しい貨幣を生成する取引の熟成期間）
• LOCKTIME_THRESHOLD = 500000000：取引の待機時間（locktime）の解釈基準（時刻かブロックの高さか）。
• MAX_SCRIPTCHECK_THREADS = 16：スクリプトを検証する際のスレッド数の最大値
• DEFAULT_SCRIPTCHECK_THREADS = 0
• MAX_BLOCKS_IN_TRANSIT_PER_PEER = 128
• BLOCK_DOWNLOAD_TIMEOUT = 60

• REJECT_MALFORMED
• REJECT_INVALID
• REJECT_OBSOLETE
• REJECT_DUPLICATE
• REJECT_NONSTANDARD
• REJECT_DUST
• REJECT_INSUFFICIENTFEE
• REJECT_CHECKPOINT

Bitcoinネットワーク
• Bitcoindの場合。
• 接続数は8（MAX_OUTBOUND_CONNECTIONS）
• 接続数より小さくならないように常に接続を維持する。
• Bitcoinネットワークに存在するノードが8以下の場合には、当然ながら、接続数より
少ない接続しかできない。
• ポートが開放されていないノードは、最大で8個のノードまでしか接続しない。
• ポートが開放されているノードは、8個より多くのノードと接続する可能性がある。
• 平均で32個のノードと接続しているらしい[1]。
• 30分以上接続している夫々のノードと通信しなかった場合にはそのノード
に通信文を送信する。
• 90分以上接続している夫々のノードから通信文を受信しなかった場合に
は接続が切断されたと見做す。

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

Bitcoinノード
• おかしな動作をしているノードに対しては追放点数（banscore）を加
点していき、ある点数を超えた場合には追放時間（bantime）分だけ
追放される。
• 通常は24時間。

通信文（message）
• addr
• ノード情報
• getaddr
• version
• 他のノードに接続したら最初にこの通信文を送信しなければならない。
• verack
• version通信文への返信。
• alert
• 攻撃などによって問題が生じた場合の開発者からの警報。
• RSSフィードの形式
• ECDSA署名付き

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

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

採掘
• 単独採掘（solo mining）
• 報酬と取引手数料の全てを獲得することができるが、採掘に成功することは
滅多にない。
• 集団採掘（pooled mining）
• 報酬と取引手数料は他の採掘者との間で（採掘者の貢献度を決定する）何
らかの計算式に基づいて分配されるが、頻繁に採掘に成功する。
• getwork RPC
• getblocktemplate RPC
• Stratum mining protocol

採掘方式（mining algorithm）
• 暗号学的要約関数を使用するもの
• SHA256
• Bitcoin
• SHA3
• Scrypt
• Litecoin
• Scrypt-N
• 記憶領域集約的（memory intensive）
• ASIC耐性（ASIC resistance）
• Groestl
• Quark
• X11
• ASIC耐性
• 低電力
• ネットワークの安全性
• Darkcoin
• 素数を利用するもの
• Primecoin, Riecoin

並行採掘
2014/06/15作成
• 複数のブロック鎖における採掘を同時に行う。
• 親ブロック鎖（parent blockchain）
• 実際の採掘が行われるブロック鎖。同時に付随仕事証明（auxiliary proof-of-work）が行われていることを認識する必要はない。
• 付随ブロック鎖（auxiliary blockchain）
• 親ブロック鎖で行われた仕事証明を有効なものとして受け入れるブロック鎖。
• 付随ブロックの要約値を親ブロックにおける有効な取引となるような形で親ブロックに格納する。
• 額面価格が0の新しい貨幣を生成する取引のscriptに格納する。
• これによって親ブロックに対する仕事証明が付随ブロックに対する仕事証明にもなる。
• 付随ブロック鎖の難易度要件を充足する場合には、付随ブロック鎖は親ブロックを有効なブロックとして受け入れる。
• 親ブロック鎖の難易度要件を充足する場合には、付随ブロック鎖だけではなく親ブロック鎖も親ブロックを有効なブロックとして受け入れる。
• ある親ブロック鎖に対する付随ブロック鎖が複数ある場合は親ブロック鎖と全ての付随ブロック鎖の採掘を並行して行った方が
有利。
• 親ブロック鎖と全ての付随ブロック鎖において報酬を獲得できる可能性があるから。
• しかしながら、並行採掘を行う場合には、並行採掘を行おうとしている全てのブロック鎖に関する情報を収集する必要がある。
• 小規模な採掘者は親ブロック鎖と全ての付随ブロック鎖に関する情報を収集することができない（或いは、困難、費用が嵩む）かもしれない。
• 従って、並行採掘は採掘の集中化を昂進する可能性がある。
• ブロック鎖に関する情報の収集や採掘するブロックに含める取引の選択や検証を第三者に負託することも考えられなくはないが、
それで採掘の分散度を維持したとしても、取引の選択や検証の分散度は維持されない訳だから余り意味がない。

Bitcoinの応用1
2014/06/26作成
• 別のブロック鎖
• ブロック鎖の枠組みは貨幣以外のためにも使える（分散型の合意形成が必
要となる様々な場合で使える）。
• 貨幣以外のために別の異なるブロック鎖を新設し、採掘者は複数のブロック
鎖の採掘を同時に行う。
• 1つのブロック鎖に多くの機能を盛り込むこともできるが、皆が皆全ての機能を使いたい
訳ではない。
• Bitcoinの（現在の）ブロック鎖は基本的に貨幣を管理するためのものであり、必ずしも
他の目的には適しない。

Bitcoinの応用2
2014/05/31更新
• 第三者預託取引（escrow transaction）
• 複数署名口座番号（multisignature address）
• 支払い人、受け取り人、調停者の内2人以上が取引入力に署名した場合のみ有効な取引と
なる。支払い人と受け取り人が合意すれば、調停者を変更することができる。
• 保証契約／クラウドファンディング（assurance contract/crowdfunding）
• 小額決済手段（micropayment channel）
• 保証金取引（bond transaction）と返金取引（refund transaction）の組み合わせ。
• CoinJoin
• 複数の参加者の入力から等しい割合を出力する取引。
• 購入者で行うCoinJoin（purchaser CoinJoin）
• 複数の（典型的には物品を購入しようとしている）参加者の入力を別々の商人の口座に出
力する取引。
• 即ち、CoinJoinと物品の購入1つの取引で実行する。そのため、取引手数料の節約となる。

Bitcoinの応用3
2014/05/31更新
• 電子財産（smart property）
• 電子契約（smart contract）
• 賭博
• 共同預金口座
• 金融市場
• 信託基金
• 自律型代行プログラム（autonomous agent）
• 分散型自治体（decentralized/distributed autonomous organization
（corporation）：DAO（DAC））
• BitcoinそのものもDAOであるという考え方がある。
• decentralized Dropbox
• 自律経済（autonomous economy/auconomy）

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

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

Bitcoinの問題点2
2014/07/08更新
• 取引や取引の有効性の確認に時間が掛かる
• ブロック生成間隔は10分なので、取引がブロックに取り込まれて有効性が確認されるまでに時間が掛かる。
• ブロック鎖分岐が発生している可能性があるので、更に何ブロックか生成されるまで待たないと、取引の有効性が覆される可能性がある。
• かと言って、安易にブロック生成間隔を短縮すると、伝播遅延のために頻繁にブロック鎖分岐が発生する状況となり、どれが本当に有効な取引か分からない混乱状態
に陥る可能性がある。
• 匿名性が低い。
• 採掘者が手数料のある取引をその取引を含んだブロックを作成するまで他のノードに伝えない可能性がある。
• 最小手数料が固定されている。
• 手数料の自動調整（smart fee）が実現すれば解決するが・・・。
• 新たに採掘されるBitcoinの量は逓減し、最終的には新しいBitcoinは採掘されなくなる。
• 採掘されるBitcoinの量には上限がある。
• 極めてデフレ的な特性を有する。Bitcoinの経済規模が大きくなった場合、Bitcoinの価格は上昇するしかない。価格の上昇を期待して保蔵され易い。
• 遺失貨幣（lost coin/zombie coin）（結び付けられている秘密鍵が失われ、使用することのできなくなった貨幣）により、新しいBitcoinの採掘が終了したら、使用できる
Bitcoinの量は減っていくのみである。
• 手続きの改定が難しい。
• 手続きを改定するには少なくともネットワーク全体の要約値計算能力の過半数を有する採掘者の賛同が必要である。
• 結果として、
• Bitcoin以外の新種の貨幣や貨幣以外の資産に対応するような変更が難しい。
• 匿名性の向上が難しい。
• 少数派が新機能を実現することはほぼ不可能。

拡張性の問題を改善する1
2014/11/22更新
• 簡易決済検証（simplified payment verification：SPV）
• 軽量ノード/簡易決済検証クライアント（light node/simplified payment verification client：SPV client）は完全
ノードからブロックの頭部のみ取得し、ブロックが鎖状に接続されているか確認し、ブロックの難易度が十分
に高いかどうか確認する。
• 難易度的に最長のブロック鎖が正しいブロック鎖であると信頼する。
• 十分に古いブロックの頭部は取得せず、十分に古くなったブロックの頭部は破棄する（場合もある）。
• 即ち、ブロック高さ検証を行わない（場合もある）。
• 完全ノードから確認したい取引（自己の所有する口座に関する取引）が格納されているブロックのMerkle木
の一部（根から取引識別子に至るまでの中間ハッシュ値）のみを取得して取引（出力）がブロックに含まれて
いるかどうか確認する。
• 又、取引が格納されているブロックの深さが十分に大きい場合には、取引は有効であると見做す。
• ブロック深さ検証。
• 二重使用されているかを直接確認することはない。
• 取引の有効性に関しては採掘者を信頼する。
• 接続している全てのノードが不当であるような場合には、二重使用攻撃を実行される危険がある。攻撃者はネットワーク全体
の過半数の要約値計算能力を支配している必要はない。
• つまり、ブロック鎖全体を取得しなくても取引がブロックに含まれているかを確認することができる！！
• ブロック鎖のブロックの頭部＋取引に関係のあるMerkle木の一部を合わせて簡易決済検証証明（simplified
payment verification proof：SPV proof）と言う。

2014/11/22更新
• 簡易決済検証（simplified payment verification：SPV）
• 軽量ノードに対して、ブロックに格納されていない取引を格納されていると錯覚させ
ることはできないが、ブロックに格納されている取引を格納されていないと錯覚させ
ることはできる。
• 複数のノードからデータを取得すべき。
• ネットワーク全体の要約値計算能力の過半数を有していれば軽量ノードを完全に
欺罔することはできる。
• Sybil攻撃によって軽量ノードを完全に欺罔することもできる。
• これは純粋P2P全般の話であって簡易決済検証に限られるものではない。
• ある取引出力が使用済みか未使用かも分からない？
• 通常自己の所有する口座に関する取引しか取得しないので、取得したノードに自
己の所有する口座に関する情報が知られることになる。
• 撹乱するために大量の取引データを取得することもできるが、そんなことをしたら軽量ノード
である意味がなくなってしまう。
• Bloomフィルタを使おう。

dynamic-membership multi-party signature
（DMMS）
2014/11/22作成
• 固定されていない（不特定の）署名者の集合によって生成される電子署名。
• ブロックの頭部はDMMSと考えることができる。
• 署名者が最初から決まっている訳ではなく、仕事証明の枠組みによって署名者は後から決まる
から（運良くブロックの頭部の要約値が目標値より小さくなるような解を見付けた者が署名者とな
るから）。
• この場合、情報（knowledge）に関するDMMSではなく、計算量（computational power）に対する
DMMS。
• ブロックの頭部の牽連は最初のブロックに関するDMMSと考えることができる。
• ブロックの頭部は直前のブロックの要約値を含んでいるから（牽連するブロックの仕事証明は累
積的だから）。
• 完全ノードは取引の順序を決定するために（最長のブロック鎖を決定するために）
DMMSを使っている。
• SPVノードは取引の有効性を判断するためにDMMSを使っている（署名した採掘者の取
引の検証を信頼することになる）。
• compressed DMMS

Bloomフィルタ
• 要素の帰属を検査するための空間効率の良い確率的データ構造
• 偽陽性（false positive）
• BIP37
• filterload通信文

2014/05/31更新
• 安全性の水準
• 水準4：小型軽量クライアント（thin client）
• クライアントは未使用の取引出力木を保持せず、サーバが保持しているものを信用する。
• 水準3：簡易決済検証
• 簡易決済検証によって達成される安全性の水準を簡易決済検証安全性（simplified payment
verification security：SPV security）と言う。
• 水準2：強化された簡易決済検証（enhanced simplified payment verification：SPV+）
• ブロック鎖には未使用の取引出力木（unused output tree：UOT）の根のハッシュ値が含まれる。
• クライアントは自身に関連する未使用の取引出力を問い合わせ、包含証明（proof of inclusion）付きの
未使用の取引出力の一覧を取得する（或いは、関連する未使用の取引出力が存在しないという証明を
取得する）。
• 水準1：最初に未使用の取引出力木やブロック鎖を他のノードからダウンロードし、矛盾がな
いことを検証し、それ以降の未使用の取引出力木やブロック鎖は自ら構築する。
• 水準0：完全ノード（full node）
• ブロック鎖の起源ブロックから最新のブロックまで全てを自ら構築する。
• 完全ノードは取引の有効性を検証するためにブロック深さ検証を用いることはない。

枝刈り（pruning）
2014/06/04作成
• 取引の取引出力が全て使用され、その後十分にブロック鎖が成長し
たら、その取引のデータを破棄することができる（破棄しても安全性
が損なわれることはない）。

データ転送量の削減、伝播遅延の縮減
2014/06/09作成
• 現在は、ブロックを転送する場合において、ブロックに含まれる全て
の取引も同時に転送されているが、
• これを、ブロックに含まれる取引の識別子のみを転送するように改良する。
• （新しい貨幣を生成する取引以外の）取引は作成時に一度全てのノードに転
送されている筈なので、転送された後にネットワークに参加し始めたノード以
外は既に知っている筈。
• なので、新しい貨幣を生成する取引だけは一緒に転送した方が良い。
• 新しい貨幣を生成する取引の大きさを制限すべきかもしれない。
• 新しいブロックを受け取ったら、含まれている取引の識別子の一覧と既に受
け取っている取引の一覧を照合し、知らない取引があった場合にのみ他の
ノードにその取引を要求する。

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

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

ブロック鎖外の取引（off-chain transaction）
2014/11/30更新
• ブロック鎖以外の（通常は公開されていない）元帳の上で行われる取引。
• ブロック鎖の上で行われる取引はブロック鎖内の取引（on-chain transaction）。
• ブロック鎖外の取引は通常は公開されず、検証も不可能なので信頼性は低い。
• というか、誰も信用する必要のないブロック鎖内の取引と比較して、誰か（元帳の管理者）を
信用しなければならない。
• しかしながら、ブロック鎖外の取引は早いし、取引手数料が掛からない。
• Bitcoinネットワークには拡張性の問題があり、ブロック鎖には肥大化の問題が
ある。
• 複数署名によるブロック鎖外の取引（multi-signature off-chain transaction）
• 元帳の管理者が複数人のもの。
• 複数の管理者（全ての管理者、或いは、規定の員数以上の管理者）が署名しなければ取引
が執行されない（有効な取引とならない）。
• 小規模な場合、仕事証明に基づいた合意形成より安全だという見解がある。

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

匿名性を向上させるには？
2014/06/15更新
• 通信の匿名化のためにはTorを利用する。
• Torの使用を阻止する攻撃方法が存在する。
• tumbler
• CoinJoin
• CoinJoin Sudoku
• 購入者で行うCoinJoin
• 統合回避（merge avoidance）
• 別々の口座で受け取ったBitcoinを1つの口座に纏めると、別々の口座の間に関連性を与えることになり、口座の監視者に
対して情報を与えてしまう可能性がある。これを統合（merge）と言う。
• 秘密の口座番号（stealth address）
• 受け取り人のみが認識することのできる暗号化された口座番号。
• ブロック鎖だけでは支払い人と受け取り人を結び付けることができない。
• cryptographic accumulator
• 環署名（ring signature）
• 不視署名

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

匿名性を向上させるには？3
2014/06/05作成
• APPECoin（anonymous peer-to-peer electronic coin）
• 追跡不可能性
• 採掘者が再暗号化によって取引を攪拌する。取引の作成者だけが、攪拌された複数の
取引の中で何れが自己の取引なのか認識できる。
• 採掘者の攪拌が有効であることはゼロ知識証明によって検証される。
• 取引の作成者は何度かの攪拌によって取引が匿名化されたと確信することができる。
• 額面価格は封印され、受け取り人が開封するまで分からない。
• 口座の所有者以外から口座残高が分からない。
• 欠点
• データが大きい。検証により多くの計算能力が必要。

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

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

Bitcoinの個人的勉強ノート第3版（2015年1月4日）

Bitcoinの個人的勉強ノート第3版（2015年1月4日）

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Recently uploaded

Recently uploaded (9)