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

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

@pizyumi

https://twitter.com/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）） 12014/12/03更新

•公開鍵要約値への支払い（pay-to-pubkey-hash：P2PKH）• ある口座から別の口座へのBitcoinの移動

• 公開鍵スクリプト• OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

• <PubKeyHash>は被参照取引出力が所属する口座の公開鍵の要約値＝口座番号

• 署名スクリプト• <Sig> <PubKey>

• <Sig>は被参照取引出力が所属する口座の秘密鍵による署名

• <PubKey>は被参照取引出力が所属する口座の公開鍵

取引の種類（標準取引） 22014/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（真）ならば取引入力は有効である。

取引の種類（標準取引） 32014/12/04更新

• スクリプト要約値への支払い（pay-to-script-hash：P2SH）• 公開鍵要約値の代わりに解放スクリプト（redeem script/redemption script）の要約値を使うもの。

• 公開鍵スクリプト• OP_HASH160 <RedeemScriptHash> OP_EQUAL

• <RedeemScriptHash>は解放スクリプトの要約値

• 署名スクリプト• <sig> [sig] [sig...] <RedeemScript>

• <RedeemScript>は解放スクリプト


• スクリプト要約値への支払いのスクリプトの検証• スクリプト（取引入力の署名スクリプトの後に被参照取引出力の公開鍵スクリプトを繋げたもの）• <sig> [sig] [sig...] <RedeemScript> OP_HASH160 <RedeemScriptHash> OP_EQUAL

• これを評価する。スクリプト要約値への支払いのスクリプトの場合はスクリプトをそのまま（解放スクリプトは一塊の値として）スタック機械（stack machine）で評価した後に、解放スクリプトを（一塊の値としてではなく分解して）評価する。


• 例：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（真）ならば取引入力は有効である。


• 複数署名（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の先頭に置く必要がある。

取引の種類（標準取引） 7

•公開鍵• 公開鍵スクリプト

• <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を受け取る（ただし、ブロック鎖の頭部に接続できなければならない）。• これが、採掘者が仕事を行う動機となる。

仕事証明

ブロック作成32014/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）• 確証度が0の取引を信用する者に対する攻撃。

• 自身の所有する貨幣を自分自身に送金する取引を含むブロックを先に作成し、同一の貨幣を攻撃対象に送金する取引をネットワークに公開してから、先に作成していたブロックを公開する。結果として、自分自身に送金する取引が有効となり、攻撃対象に送金する取引は無効となり、破棄される。

• Vector76攻撃／確証度1における攻撃（Vector76 attack/1 confirmation attack）• 確証度が1の取引を信用する者に対する攻撃。• 競争攻撃と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がないから。

• 苫前町地域通貨流通実験

取引ネットワーク2

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の応用12014/06/26作成

•別のブロック鎖• ブロック鎖の枠組みは貨幣以外のためにも使える（分散型の合意形成が必要となる様々な場合で使える）。

• 貨幣以外のために別の異なるブロック鎖を新設し、採掘者は複数のブロック鎖の採掘を同時に行う。• 1つのブロック鎖に多くの機能を盛り込むこともできるが、皆が皆全ての機能を使いたい訳ではない。

• Bitcoinの（現在の）ブロック鎖は基本的に貨幣を管理するためのものであり、必ずしも他の目的には適しない。

Bitcoinの応用22014/05/31更新

• 第三者預託取引（escrow transaction）• 複数署名口座番号（multisignature address）• 支払い人、受け取り人、調停者の内2人以上が取引入力に署名した場合のみ有効な取引となる。支払い人と受け取り人が合意すれば、調停者を変更することができる。

• 保証契約／クラウドファンディング（assurance contract/crowdfunding）

• 小額決済手段（micropayment channel）• 保証金取引（bond transaction）と返金取引（refund transaction）の組み合わせ。

• CoinJoin• 複数の参加者の入力から等しい割合を出力する取引。

• 購入者で行うCoinJoin（purchaser CoinJoin）• 複数の（典型的には物品を購入しようとしている）参加者の入力を別々の商人の口座に出力する取引。

• 即ち、CoinJoinと物品の購入1つの取引で実行する。そのため、取引手数料の節約となる。


•電子財産（smart property）

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

• 自律経済（autonomous economy/auconomy）


•双方向の固定（two-way pegging）• 副ブロック鎖（side chain）を作る。

• 主ブロック鎖（main chain）と副ブロック鎖の間で貨幣を移動できるようにする。• 電子契約

• 私的ブロック鎖（private chain）

• 安全性の防壁（security firewall）• 副ブロック鎖での安全性の瑕疵が主ブロック鎖に影響しないこと。

•確率的支払（probabilistic payment）

Bitcoinの問題点1

• 拡張性（scalability）• ノード数が増えた場合• 取引が増えた場合

• 現在ブロックの大きさは1MBまでに制限されている。また、ブロックは平均して10分に1個ずつ生成されるように調整されている。従って、処理可能な取引数には上限がある（上限があるというよりは、ネットワークの処理能力を超過しないように制限を設定していると言った方が正しい）。

• 平均的な取引の大きさを考慮すると、現在の取引数の上限は約3.3取引/秒である。

• データ転送量• 伝播遅延• 検証時間• ブロックの大きさの最大値

• ブロックの大きさが大きくなれば伝播遅延も大きくなる。

• データ量（ブロック鎖の肥大化（blockchain bloat））

Bitcoinの問題点22014/07/08更新

• 取引や取引の有効性の確認に時間が掛かる• ブロック生成間隔は10分なので、取引がブロックに取り込まれて有効性が確認されるまでに時間が掛かる。

• ブロック鎖分岐が発生している可能性があるので、更に何ブロックか生成されるまで待たないと、取引の有効性が覆される可能性がある。

• かと言って、安易にブロック生成間隔を短縮すると、伝播遅延のために頻繁にブロック鎖分岐が発生する状況となり、どれが本当に有効な取引か分からない混乱状態に陥る可能性がある。

• 匿名性が低い。

• 採掘者が手数料のある取引をその取引を含んだブロックを作成するまで他のノードに伝えない可能性がある。

• 最小手数料が固定されている。• 手数料の自動調整（smart fee）が実現すれば解決するが・・・。

• 新たに採掘されるBitcoinの量は逓減し、最終的には新しいBitcoinは採掘されなくなる。• 採掘されるBitcoinの量には上限がある。

• 極めてデフレ的な特性を有する。Bitcoinの経済規模が大きくなった場合、Bitcoinの価格は上昇するしかない。価格の上昇を期待して保蔵され易い。

• 遺失貨幣（lost coin/zombie coin）（結び付けられている秘密鍵が失われ、使用することのできなくなった貨幣）により、新しいBitcoinの採掘が終了したら、使用できるBitcoinの量は減っていくのみである。

• 手続きの改定が難しい。• 手続きを改定するには少なくともネットワーク全体の要約値計算能力の過半数を有する採掘者の賛同が必要である。

• 結果として、• Bitcoin以外の新種の貨幣や貨幣以外の資産に対応するような変更が難しい。

• 匿名性の向上が難しい。

• 少数派が新機能を実現することはほぼ不可能。

拡張性の問題を改善する12014/11/22更新

• 簡易決済検証（simplified payment verification：SPV）• 軽量ノード/簡易決済検証クライアント（light node/simplified payment verification client：SPV client）は完全ノードからブロックの頭部のみ取得し、ブロックが鎖状に接続されているか確認し、ブロックの難易度が十分に高いかどうか確認する。

• 難易度的に最長のブロック鎖が正しいブロック鎖であると信頼する。• 十分に古いブロックの頭部は取得せず、十分に古くなったブロックの頭部は破棄する（場合もある）。• 即ち、ブロック高さ検証を行わない（場合もある）。

• 完全ノードから確認したい取引（自己の所有する口座に関する取引）が格納されているブロックのMerkle木の一部（根から取引識別子に至るまでの中間ハッシュ値）のみを取得して取引（出力）がブロックに含まれているかどうか確認する。

• 又、取引が格納されているブロックの深さが十分に大きい場合には、取引は有効であると見做す。• ブロック深さ検証。• 二重使用されているかを直接確認することはない。• 取引の有効性に関しては採掘者を信頼する。• 接続している全てのノードが不当であるような場合には、二重使用攻撃を実行される危険がある。攻撃者はネットワーク全体の過半数の要約値計算能力を支配している必要はない。

• つまり、ブロック鎖全体を取得しなくても取引がブロックに含まれているかを確認することができる！！• ブロック鎖のブロックの頭部＋取引に関係のあるMerkle木の一部を合わせて簡易決済検証証明（simplified

payment verification proof：SPV proof）と言う。


• 簡易決済検証（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通信文


• 安全性の水準• 水準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）

• 不視署名

匿名性を向上させるには？22014/05/27更新

• Darkcoin• DarkSendサーバ

• CoinJoinを実行するサーバ

• Zerocoin, Anoncoin, Zerocash, Nxtcash, etc• CoinWitness

• NxtCashの場合• 匿名性

• 貨幣の送信者と受信者を結び付けることができない（誰が誰に送金したのかが当事者以外には分からない）。

• 無信用性• 信用できる第三者機関を必要としない。

• 分散性• 単一機関ではない。単一障害点（single point of failure）がない。

• 暗号学的な安全性• 悪意のある攻撃からの保護。

• 効率性• 多くの取引を処理することができる。

• ゼロ知識証明（zero-knowledge proof）• zk-SNARK

• 信頼される設定（trusted setup）

匿名性を向上させるには？32014/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

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関連論文2BITCOIN 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 Vasekand 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.

Information Propagation in the Bitcoin Network 1梗概

•本論文では、• 全てのノードによって共有されている元帳を最新の状態に更新させるため、新しい取引やブロックを全てのノードに伝播させる際に、Bitcoinがどのようにして多段中継の一斉同報通信（multi-hop broadcast）を使用するのか（どのように情報が伝播するのか）を分析する。

• ネットワークの伝播遅延がブロック鎖分岐の主要な原因であるか検証する。

• クライアントの挙動に一方的な変更を加えるだけで、現在のプロトコルに変更を加えず限界まで利用して、何を達成することができるか示す。

Information Propagation in the BitcoinNetwork 2• ブロックの伝播について、その大きさを考慮しない場合

• 中央値は6.5秒。• 平均値は12.6秒。• ロングテール。• ブロックの伝播が始まってから40秒経過しても5%のノードには未だ伝播していない。

•取引とブロックの伝播について、その大きさを考慮した場合• 小さい取引やブロックは遅延の、大きさに対する比率が大きい。• 20kByteを超えるブロックでは遅延の、大きさに対する比率がほぼ一定。

• 20KByteを超えた場合は、ブロックが大きくなっても一定の比率でしか伝播遅延は増加しない。

• inv通信文とgetdata通信文の往復に非常に時間が掛かっている

Information Propagation in the BitcoinNetwork 3•矛盾する2つの取引やブロックを検出した場合にそれを他のノードに転送しないとどうなるか？• 一方の取引やブロックが有効であると見做しているネットワークと他方の取引やブロックが有効であると見做しているネットワークに分裂している状態であるから、その2つの分裂したネットワークの正に境界にあるノードのみが矛盾する2つの取引やブロックが存在することを認識しているだけである。

•取引の場合は、スパム取引によるネットワークの不安定化を防止するため、矛盾する取引を転送しないのは妥当な選択だろう。

• しかし、ブロックの場合は、矛盾するブロックを転送しないと、ブロック鎖分岐が発生したことを認識できるノードが極少数に限られてしまう。

Information Propagation in the BitcoinNetwork 4• ブロック鎖分岐割合（到達できるノードのみに関して調べた値）

• 1.69%

• 伝播遅延が大きくなればなるほどブロック鎖分岐が発生しやすい。

• ブロック鎖分岐割合（理論値）• 1.78%

•微妙に実測値より大きいのは、要約値計算能力が全てのノードに一様に分布しているという仮定がおかしいからだろう。

• とは言え、実測値と十分良く一致している。

Information Propagation in the BitcoinNetwork 5•新しいブロックが見付かる毎に11.37秒分のネットワーク全体の要約値計算能力が無駄になっている。• 伝播遅延が大きくなればなるほど要約値計算能力が無駄になる。

• つまり、元帳の安全のために実際に役に立っている要約値計算能力は投入されている要約値計算能力の98.20%• 全体の要約値計算能力の過半数の要約値計算能力を支配していれば51%攻撃を実行できるとされているが、実際には49.1%を超えれば51%攻撃を実行できる。

• 伝播遅延が大きくなればなるほど51%攻撃に必要な要約値計算能力の割合が低下する。

Information Propagation in the BitcoinNetwork 6•伝播遅延には悪影響が多い。

• 何とかして伝播遅延をできる限り小さくしよう！

Information Propagation in the BitcoinNetwork 7• 検証の最小化

• ブロックの検証には難易度の検証と取引の検証の2つがあるが、難易度の検証をして直ぐにinv通信文を発行するようにする。• たとえ無意味なデータを含んでいるブロックであっても、難易度の検証に通るように作るのは、有効なブロックを作るのと同程度の要約値計算能力が必要になるので、DDoS攻撃に悪用される心配はない。

• ブロック伝播の並列化• inv通信文を受信したら、直ぐに近接ノードにそのinv通信文を転送する。

• 幾らでも虚偽のinv通信文を発行することができる。しかしながら、inv通信文は61バイトしかないし、tx通信文を発行することでも同様のことはできるので、影響は少ない。

• 接続数の増加• 接続数を4000以上にすると全ての到達可能なノードに接続できる。

• 100MB/s程度のデータ転送量が必要

Information Propagation in the BitcoinNetwork 8

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

• 53.41%の向上！

Purely P2P Crypto-Currency With Finite Mini-Blockchain 1

梗概• 殆ど全ての分散型暗号貨幣はブロック鎖という仕組みを使って二重消費攻撃を阻止している。• しかしながら、ブロック鎖には肥大化の問題がある。

• 本論文では、制限的なブロック鎖を使用する分散型暗号貨幣を提案する。

• 制限的なブロック鎖では、ブロック鎖の中にあるブロックの数が上限に達している場合には、新しいブロックが発見され、ブロック鎖に追加されると、ブロック鎖の中で終端に存在する最古のブロックが削除される。• ブロックの削除が引き起こす安全性低下の問題は証明鎖（proof chain）によって解決される。

• ブロックを削除するとブロックに含まれている未使用の取引出力も削除されてしまい口座残高の全部又は一部が消失するという結果を齎すが、それは空でない口座の残高を保持する口座木（account tree）を構築することによって回避される。

Purely P2P Crypto-Currency With Finite Mini-Blockchain 2• 制限的なブロック鎖

• 口座木• 全ての空でない口座の残高を管理する。• 口座番号、口座残高、参照ブロック（reference block）• 参照ブロックは、口座の取引出力を使用する最後の取引が含まれているブロックの番号。• できる限りデータの大きさが小さくなるようにすべき。

• 小型ブロック鎖（mini-blockchain）• 十分に古いブロックが削除されることによってブロックの数が制限的である以外は普通のブロック鎖と同様である。

• それぞれのブロックはそれらが生成された時点における口座木のハッシュ値を含む。• 口座木が正しいことを検証することができる。

• 証明鎖• 起源ブロックから最新ブロックまでの一連の仕事証明の解からなる鎖。

Purely P2P Crypto-Currency With Finite Mini-Blockchain 3•制限的なブロック鎖

• ネットワークの同期• 1.最大の累積難易度（cumulative difficulty）を有する証明鎖を取得する。

• 2.証明鎖に結び付けられている小型ブロック鎖を取得する。

• 3.最近ブロックの主ハッシュ値（master hash）に結び付けられている部分ハッシュ値（sector hashes）を取得する。

• 4.口座木を構築し、それぞれの部分（sector）のハッシュ値が部分ハッシュ値に一致するか検証する。

Purely P2P Crypto-Currency With Finite Mini-Blockchain 4•動的な最大ブロック長の決定

• 採掘者がブロックに希望する最大ブロック長を格納する。• 小型ブロック鎖に含まれる全てのブロックの希望最大ブロック長を平均したものが次のブロックの最大ブロック長になる。

• ある程度上限や下限を設定すべき。

• 最大ブロック長と実際のブロック長がどれくらい近いか。

•失われた貨幣の再採掘• 一定期間使用されなかった貨幣は特別の取引を使って採掘者が取得することができるようにする。

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 1

梗概• Bitcoinの仕組みは非常に高い頻度の取引の発生にも耐えられるのか？

• ノード間のデータ転送量の多寡や伝播遅延の長短は、取引の処理効率を左右し、延いては、一定時間に処理可能な取引数を左右する要因である。• データ転送量の多寡より伝播遅延の長短の方が遥かに影響が大きい。

• Nakamotoの論文では、ブロック生成間隔に比べると、伝播遅延は無視できる程に短いと仮定している。• しかしながら、この仮定は必ずしも妥当ではない。

• ブロック生成間隔をもっと短縮してほしいという要求もある。

• そこで、本論文では、• Bitcoinプロトコルが1秒間に安全に処理可能な取引数の上限を与える。• 完全な取引データの代わりに取引のハッシュ値を使用するという現在計画されているプロトコルへの改善がこの上限を著しく緩和する効果があることを示す。

• 攻撃者からの保護性能を向上させるブロック鎖の構成方法を提案する。• 上限を更に緩和する効果がある。• 取引確証度熟成期間も顕著に短縮させることができる。• ブロック生成間隔を安全に1秒まで短縮することができる。

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 3• どれくらいの速さでブロック鎖が成長するのか（ブロック鎖成長速度βはどれくらいなのか）？

• β=β(λ, b)• ブロック鎖成長速度βはブロック生成速度λとブロックの大きさbに依存する。• 更には、ネットワークの形状とノード間の遅延と要約値計算能力の分布に依存する。

• 先ず、ネットワークが2つのノードのみから成る場合におけるブロック鎖成長速度を考える。• 2つのノード間には双方向の通信路が確立している。• 2つのノードは別々に採掘を実行しており（実行している可能性があり）、一方のノードが新しいブロックを生成した場合には、確立している通信路を通して他方のノードに生成された新しいブロックが送信される。

• 通信路には遅延dがあり、一方のノードが生成したブロックを送信してから、他方のノードがそれを受信するまでに時間が掛かる。

• その間にも2つのノードは採掘を継続しており、更に新しいブロックが生成される可能性がある。

• 定理4.1• ネットワークが2つのノードu, vから成り（2つのノード間で双方向の通信が確立しており）、u, vのブロック生成速度が夫々

p_uλ, p_vλであり、ブロックの大きさがbであり、u, v間の遅延がd=d(b)であるとすると、• β(λ) = (((p_uλ)^2 e^(p_uλ2d)) - ((p_vλ)^2 e^(p_vλ2d))) / ((p_uλe^(p_uλ2d)) - p_vλe^(p_vλ2d))

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 4• ブロック鎖成長速度βはブロックが破棄される確率（或いは、ブロックが破棄されない確率）から得られる。

• ブロックが破棄されるのはブロック鎖分岐が発生したとき。

• ブロック鎖分岐が発生したとき、• 高さが同一の2つ以上のブロックが存在する。

• ノードuが新しいブロックUを生成した時刻をt_Uとする。• [t_U - d, t_U + d]をUの時間帯（window）とする。

• 時刻の原点をt_U - dに取ると（t_U - d = 0とすると）、[t_U - d, t_U + d]=[0, 2d]となる。

• ノードvが作成した新しいブロックがノードuに到達するまでにはdだけ時間が掛かるため、t_U - dより後にノードvで新しいブロックVが生成されると、ブロックUとブロックVが競合する（compete）可能性がある（ブロック鎖分岐が発生する可能性がある）。

• 又、ノードuが作成した新しいブロックがノードvに到達するまでにもdだけ時間が掛かるため、t_U + dより前にノードvで新しいブロックVが生成されると、ブロックUとブロックVが競合する可能性がある。

• 即ち、[t_U - d, t_U + d]においてブロック鎖分岐が発生する可能性がある。• より正確には、[t_U - d, t_U + d]の内、ノードvのブロック鎖の長さがブロックUの高さより1小さいような期間においてのみ、ブロック鎖分岐が発生する可能性がある。この期間においてノードvが新しいブロックの生成に成功すると、ブロック鎖分岐が実際に発生する。

• この期間の左端を開始時刻（open）とし、右端を終了時刻（close）とし、この期間を[t_open(U), t_close(U)]と表す。

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 5• ノードuのn番目の新しいブロックU_nの開始時刻t_open(U_n)及び終了時刻t_close(U_n)は[0, 2d]における確率変数であり、t_open(U_n) <= t_close(U_n)である。

• t_open(U_n)はt_open(U_n)=(0, 2d]の連続的な部分とt_open(U_n)=0の離散的な部分に分かれる。• α_n(x), α_n,0と表すことにする。

• T_close(U_n)もt_close(U_n)=[0, 2d)の連続的な部分とt_close(U_n)=2dの離散的な部分に分かれる。• ω_n(x), ω_n,2dと表すことにする。

• f_u, f_vを夫々平均p_u× λ, p_v× λの指数分布の確率密度関数とする。

• このとき、• α_n(x) = ∫[x,2d] ω_n-1(y) × f_u(y-x) dy + ω_n-1,2d × f_u(2d-x)• ω_n(x) = ∫[0,x] α_n(z) × f_v(x-z) dz + α_n,0 × f_v(x)

• t_open(U_n)及びt_close(U_n)はMarkov性（Markov property）を有するから、極限分布（limiting distribution）α(x)及びω(x)を使って、

• α(x) = ∫[x,2d] ω(y) × f_u(y-x) dy + ω_2d × f_u(2d-x)• ω(x) = ∫[0,x] α(z) × f_v(x-z) dz + α_0 × f_v(x)

• 上の2つの式から常微分方程式系が導かれる。常微分方程式系から次の式が得られる。

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 5• Greedy heaviest-observed sub-tree：GHOST

• 特に平均ブロック生成間隔が短いネットワークにおいて攻撃者からの保護性能を向上させる新しいブロック鎖の構成方法。

• 安全にブロック生成間隔を短縮することができるため、結果として、取引確証度熟成期間を短縮させることができる。

• 親ブロック選択方針（採掘者が新しいブロックを採掘する際にどのブロックを親ブロックにするかを決定する方法）GHOST(T)• 1.Bをブロック木Tの起源ブロックとする。

• 2.Bの子ブロックが存在しない場合には、Bを親ブロックとする。そうでない場合には、Bの子ブロックの中でその子孫ブロックの数が最多であるものを新しいBとし、2の最初に戻る。

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 5• Greedy heaviest-observed sub-tree：GHOST

• 全てのブロックは最終的にネットワーク上の全てのノードによって破棄されるか、或いは、採用されるかの何れかである。

Enabling Blockchain Innovations with Pegged Sidechains

2014/11/28作成• 1つのブロック鎖だけでは無理がある

• 少額取引に対する要請と高額取引に対する要請は相反する（ことがある）。• 少額取引

• 取引の確定が高速な方が良い。

• そこまで安全性が高くなくても良い。

• 高額取引• 安全性が最重要。

• 高速である必要はない。

• 拡張性を取るか分散性を取るか。• 安全性を取るか費用軽減を取るか。• 多機能を取るか性能を取るか。

• 暗号貨幣は安全性を確保するために暗号技術を使っているが、暗号技術の安全性が損なわれる可能性がある。• 1つの暗号技術に依存するべきではない。

Enabling Blockchain Innovations with Pegged Sidechains 2

2014/11/28作成• 代替ブロック鎖（altchain）（＝代替貨幣）を作ろう

• 確かにブロック鎖に新機能を盛り込んだり、特定用途に特化したものを作ったりできるが、似たような代替貨幣が沢山・・・• 初期配布が大変• 少ない要約値計算能力しか投入されない＝安全性が低い• 流動性が低い、価格変動の危険が大きい• そもそも値段が付くのか？

• 暗号貨幣の界隈全体で見ても、代替貨幣が氾濫するのは宜しくない。• 代替貨幣が沢山誕生するということはそれらの代替貨幣の間で熾烈な生存競争が発生するということ• 基本的には使用者の多寡で確固たる地位を確立できるかが決まるので、技術的に優れていても消滅してしまう代替貨幣は沢山あるだろう。つまり、技術革新に向かいにくくなる。

• 分断の危険• 代替貨幣を使った詐欺の危険• 暗号貨幣分野が危険であると公衆に認識されてしまうと暗号貨幣分野全体が自然に、或いは、立法的に切り捨てられる可能性がある。


2014/11/28作成• ブロック鎖と貨幣／資産（asset）は本来別個のもの

• ブロック鎖は分散型（純粋P2P型）の合意形成手段

• 貨幣／資産は価値の媒体

• Bitcoinは貨幣に関する取引の合意形成のためにブロック鎖を用いただけ

• 分けて考えるべき

• 複数の種類の貨幣／資産が複数のブロック鎖を往来できるのが本来あるべき姿

• ある特定の種類の貨幣／資産であっても別のブロック鎖に移動すれば（そのブロック鎖で認められている）別の機能を使える。

• そうすれば、新しい機能や特性を有するブロック鎖を作るのに、価値が付くかも分からないような代替貨幣／資産を作る必要はなくなる。

• 使用者も、新しいブロック鎖を使用するのに価値が保たれるかも分からないような代替貨幣／資産を使う必要がなくなる。

• 貨幣／資産を元のブロック鎖に戻すこともできる。


2014/11/28作成• 望ましい性質

• 移動ができるなら逆移動もできるべき• 無論逆移動ができるのは現所有者のみ。

• 移動の際に取引相手を必要としない（取引相手がいなくて移動させられないという危険がない）

• 移動が原子性（atomicity）を有する（移動は完全に成功するか、或いは、完全に失敗するか）

• ブロック鎖間には防壁（firewall）があるべき（あるブロック鎖における安全性の瑕疵が別のブロック鎖に波及しない）

• 夫々のブロック鎖は完全に独立している（fully independent）べき（あるブロック鎖の検証者は別のブロック鎖の情報を収集する必要がない）• 別のブロック鎖の必要な情報は使用者（利害関係人）が提供することになる。• あるブロック鎖で再編製が発生した場合であっても、別のブロック鎖と矛盾してはならない。

• 使用者は自身に無関係のブロック鎖に一切関与する必要がない（関知しないで良い）


2014/11/28作成• 一方向の固定（one-way peg）

• 貨幣／資産が移出する側のブロック鎖で貨幣の破壊を実行し、貨幣／資産が移入する側のブロック鎖でこれを検出し、（破壊された貨幣／資産と同量／同様の）新しい貨幣／資産を生成する仕組み。• 焼却証明（proof of burn：POB）を利用する？

• 両方向の固定（two-way peg）• ブロック鎖間での貨幣／資産の移動を行う仕組み。• 対称的な両方向の固定（symmetric two-way peg）

• 貨幣／資産の移動を行う2つのブロック鎖の夫々の検証者はお互いに他方のブロック鎖に関する検証を行う必要がない。

• 非対称的な両方向の固定（asymmetric two-way peg）• 貨幣／資産の移動を行う2つのブロック鎖の何れかの検証者は他方のブロック鎖に関する検証も行う必要がある。

• 検証される側のブロック鎖で再編製が発生した場合は検証する側のブロック鎖でも再編製が必要となる。


2014/11/28作成• 固定された副ブロック鎖（pegged sidechain）

• 副ブロック鎖（sidechain）• 他のブロック鎖を起源とする貨幣／資産に関する取引の検証を行うブロック鎖一般。

• 固定された副ブロック鎖• 両方向の固定を用いて他のブロック鎖を起源とする貨幣／資産に関する取引の検証を行うことによって他のブロック鎖を起源とする貨幣／資産を移入又は移出させることのできる副ブロック鎖。

• 即ち、両方向の固定に対応している副ブロック鎖。• もしかしてtwo-way pegged sidechainの略称？

• 複数の固定された副ブロック鎖の間で貨幣／資産を移動させることができる。

• 具体的にはどうすれば良いのだろう？• 簡易決済検証による固定（simplified payment verification peg：SPV peg）

• 信頼が存在しない（trustless）• 連合による固定（federated peg）

• 信頼が存在する（trustfull）• 単一障害点


2014/11/28作成• 簡易決済検証による固定

• 貨幣／資産が移出する側のブロック鎖（親ブロック鎖（parent chain））• 貨幣／資産を凍結する取引を作成する。

• 特別な口座（凍結口座とでも呼ぶべきか、実装方法によっては単に特別な取引出力であって口座と呼ぶべきではないのかもしれない）に貨幣／資産を移動する取引。

• 取引出力の送付口座が凍結口座となる。• 別のブロック鎖に貨幣／資産を移動させるための準備をするということ。• 凍結口座に移動された貨幣／資産は凍結状態となり、そのブロック鎖の中では最早移動できなくなる。• 凍結状態の貨幣／資産を解凍するには貨幣／資産が移入する側のブロック鎖で簡易決済検証証明（simplified payment verification proof：SPV proof）を提出する必要がある。

• 貨幣／資産が移入する側のブロック鎖（副ブロック鎖（sidechain））• 貨幣／資産を解凍する取引を作成する。

• 貨幣／資産が親ブロック鎖の凍結口座にあることを証明する簡易決済検証証明を取引入力として含む取引。• 取引入力には、貨幣／資産がどのブロック鎖で生じたものかを識別するための値（例えば、起源ブロックの要約値）も格納する。

• その結果、凍結状態の貨幣／資産がそのブロック鎖で使用可能（＝別の口座に移動することが可能）になる。

• 簡易決済検証証明を提供するのは使用者（利害関係人）なので、検証者（採掘者）は親ブロック鎖の情報を収集する必要がない。


2014/11/28作成• 簡易決済検証による固定（承前）

• 確認期間（conformation period）• 凍結された貨幣／資産が解凍可能になるまでの期間。• 結局これはブロック深さ検証を行うということ。• 解凍は副ブロック鎖で行われるので、具体的な期間は副ブロック鎖の設定に依る。

• 競争期間（contest period）• 解凍された貨幣／資産が使用可能になるまでの期間。• 親ブロック鎖で凍結取引が作成され、親ブロック鎖のブロックに格納され、確認期間が経過し、それにも拘らずブロック鎖分岐とその収斂による再編製が発生して凍結取引が格納されているブロックが破棄ブロックとなった場合、凍結取引は遡及的に無効となる（retroactively invalidated）。

• 親ブロック鎖での再編製の発生は（前述の枠組みだけでは）直ぐには副ブロック鎖に認識されない。より大きな累積難易度を有する簡易決済検証証明を含む解凍取引（実装方法によっては必ずしも解凍取引の形態を取る必要はないのかもしれない）が副ブロック鎖に出現して初めて認識される。特にこのような簡易決済検証証明を再編製証明（reorganization proof）と言う。

• 再編製証明が（格納されている解凍取引が）副ブロック鎖に中々出現せず、親ブロック鎖と副ブロック鎖の状態に齟齬が生じるのは何かと問題なので副ブロック鎖のノードが自発的に再編製証明を提供することもあり得る。

• と言うか、基本的には、競争期間を徒過する前に当該凍結取引を巻き込むような再編製が発生した場合は競争期間を徒過する前に再編製証明が提供されること及び競争期間を徒過した後に当該凍結取引を巻き込むような再編製が発生しないことを想定している。


2014/11/28作成• 簡易決済検証による固定（承前）

• 競争期間（承前）• 基本的には想定しない上述の事態が発生した場合どうするか？

• 不作為

• 親ブロック鎖での凍結取引は遡及的に無効となるが、副ブロック鎖での対応する解凍取引は有効なままとなる。従って、親ブロック鎖で凍結された貨幣／資産の量と副ブロック鎖で解凍された貨幣／資産の量との間に不均衡が生じ、副ブロック鎖で解凍された貨幣／資産の量の方が常に多い状態となる。ある意味、本来存在しない筈の架空の貨幣／資産が存在するという状況であり、貨幣／資産の流通量が増加したということである。

• 競争期間を徒過した後に当該凍結取引を巻き込むような再編製を実行することができれば、攻撃者は自身の貨幣を（他人の貨幣を引き換えにして）増やすことができる。

• 親ブロック鎖で凍結された貨幣／資産の量を超過する分の貨幣／資産の親ブロック鎖への移動を認めるかどうかは実装次第だが、認めない場合は副ブロック鎖（全体）では一度に親ブロック鎖に戻すことができない貨幣／資産が常に存在するということとなる。そのような貨幣／資産の量が副ブロック鎖での遺失貨幣／資産の量より少ない場合は問題ないとしても、そうでない場合は何らかの事象に起因して取り付け騒動のような事態が発生する可能性がある。

• 解凍取引の無効化• 親ブロック鎖での凍結取引が遡及的に無効となった場合は、副ブロック鎖での対応する解凍取引も遡及的に無効となる。

• 副ブロック鎖全体での余剰分の貨幣／資産の銷却を行う。銷却分は副ブロック鎖での貨幣／資産の所有者で按分。• 副ブロック鎖で解凍された貨幣／資産と親ブロック鎖で凍結された貨幣／資産の交換比率を減少させる。

• 具体的な期間は副ブロック鎖の設定に依る。

• 非対称的な両方向の固定の場合は親ブロック鎖と副ブロック鎖は最初から決まっているが、対称的な両方向の固定の場合は場合によって何れもが親ブロック鎖にも副ブロック鎖にもなり得る。


2014/11/28作成• 簡易決済検証による固定を実現するために何が必要か？

• 簡易決済検証証明を検証するためのスクリプト機能の拡張。

• 軟質分岐

• 簡易決済検証証明の長大性をどうするか？

• 長大なままでは手数料が高過ぎる。

• 出来れば圧縮したいが・・・。


2014/11/28作成• 連合による固定

• 相互に信頼しない職員（fanctionary）の連合を信頼して、凍結／解凍の枠組みに参加させる。

• 手続きの補助者（protocol adaptor）

• 夫々の職員を信頼しなければならない。

• 職員の連合は全体として単一障害点

• 職員は自身の秘密鍵を漏洩してはならない。

• 職員は自身の秘密鍵を教えろという強要に屈してはならない。

• 職員はネットワークに参加し続けなければならない。

• 貨幣／資産を副ブロック鎖に移動したい者は複数の職員の複数署名を要するスクリプト要約値への支払いを行う。

• 職員の公開鍵は予め公開されているものとする。

• 複数署名によるブロック鎖外の取引と同様の手法。


2014/12/06作成• 連合による固定における口座番号と使い捨ての値（nonce）の作成

• 入力1：貨幣／資産を副ブロック鎖に移動する際の移動先となる取引出力

• 入力2：職員の公開鍵1～n

• 入力3：解放スクリプトの雛形{<m> <PubKey1> [PubKey2] [PubKey3...] <n> OP_CHECKMULTISIG}

• 出力1：複数署名を要するスクリプト要約値への支払いの口座番号

• 出力2：使い捨ての値

• 1：使い捨ての値を無作為に決定する。

• 2：職員の公開鍵1～nに対して夫々次の処理を実行する

• 2-1：職員の公開鍵を使って使い捨ての値と取引出力（入力1）を結合したもののHMAC-SHA256符号を計算する。

• 2-2：HMAC-SHA256符号がsecp256k1_order以上である場合は1からやり直す。

• 2-3：職員の公開鍵にG*HMAC-SHA256符号を加えたものを職員の新たな公開鍵とする。

• 3：解放スクリプトの雛形に職員の新たな公開鍵を埋め込んでから要約値＝口座番号を計算する。

• 階層的決定論的鍵生成の手法（BIP32）を用いて毎回複数の職員の新たな公開鍵を生成して、その複数の公開鍵に対する複数署名を要するスクリプト要約値への支払いを行う。

• その後、当該職員に対して使い捨ての値と取引出力と簡易決済検証証明を通知して貨幣／資産の副ブロック鎖への移動を要求する。


2014/11/28作成• 副ブロック鎖で何ができるか

• 新しいスクリプト機能の導入• 有色貨幣

• 新しい暗号学的要素（cryptographic primitive）の導入

• Lamport署名（Lamport signature）

• 新しい種類の取引の導入

• 取引の非頑強性（transaction malleability）の修正

• 異なる合意形成方法の採用• 信頼が存在する（trustfull）ものでも良い

• 匿名性の向上• 環署名（ring signature）

• 貨幣／資産の経済学的な特性を変更する• 減価貨幣（demurrage）

• 時限貨幣

• 手数料の繰り延べ

• 可逆な取引

• 資産の発行• 株式、債券、選択売買権、借用証書（IOU）、商品引換券、金融派生商品

• 補完的貨幣

• 共同体貨幣、ゲーム内貨幣、上客特典制度

• 交換取引

• 分散型市場

• 新しい手続きへの移行• 参加者は自由に危険なく別の手続きを実装した副ブロック鎖に移住することができる。いつ移住するかは随意的である。


2014/12/13作成• 小型簡易決済検証証明（compact simplified payment verification proof：

compact SPV proof）• ブロックの難易度要件を満たす要約値（＝目標値以下の要約値）は目標値以下であれば何でも良い。

• 例えば、目標値の2分の1である要約値であっても良いが、この要約値はブロックの難易度の2倍までの難易度要件を満たしているということになる。

• 所与の要約値に対してその要約値が満たす最大の難易度要件の難易度をその要約値の難易度と見做そう！• ブロックの難易度とは別の新しい概念。

• 有効なブロックの難易度と有効なブロックの要約値の難易度• ブロックの要約値＝ブロックの目標値であるような稀有な場合はブロックの難易度とブロックの要約値の難易度は等しいが、そのようなことはまず起こらず、通常はブロックの要約値はブロックの目標値より小さく、ブロックの要約値の難易度はブロックの難易度より大きい。

• 長さNのブロック鎖の累積難易度はブロック鎖の夫々のブロックの要約値の累積難易度より小さい。• 長さNのブロック鎖の累積難易度をブロック鎖の先頭からx個のブロックの要約値の累積難易度が超える確率はx/N。期待値はN+1/2。


2014/12/13作成• 原子的な交換（atomic swap）

• ブロック鎖1で（十分な量の）貨幣／資産を所有している甲及びブロック鎖2で（十分な量の）貨幣／資産を所有している乙が夫々の所有する貨幣／資産を交換することが可能である。

• 夫々の貨幣／資産は同種であっても、異種であっても良い。夫々の貨幣／資産の量も如何様であっても良い。

• 結局、両者に合意があれば良いだけということである。

• 1.甲は秘密値aを生成する。

• 2.甲は自身が所有する貨幣／資産を取引出力O1に移動する取引を作成する。取引出力O1は次の何れかの値があれば使用することができる。甲は当該取引をまだ公開しないでおく。

• a.秘密値a及び乙の署名

• b.甲及び乙の署名

• 3.甲は取引出力O1の貨幣／資産を自身の口座に移動する取引を作成する。この取引のlocktimeは48時間とする（48時間経過するまでは有効な取引とならない）。甲は当該取引を乙に送付し、署名してもらう。乙が当該取引に署名して甲に返付した場合には、甲は安全に2の取引を公開することができる。

• 4.甲は2の取引を公開する。

• 5.乙は自身が所有する貨幣／資産を取引出力O2に移動する取引を作成する。取引出力O2は次の何れかの値があれば使用することができる。乙は当該取引をまだ公開しないでおく。

• a.秘密値a及び甲の署名

• b.甲及び乙の署名

• 6.乙は取引出力O2の貨幣／資産を自身の口座に移動する取引を作成する。この取引のlocatimeは24時間とする（24時間経過するまでは有効な取引とならない）。乙は当該取引を甲に送付し、署名してもらう。甲が当該取引に署名して乙に返付した場合には、乙は安全に5の取引を公開することができる。

• 7.甲は秘密値aを知っているため、取引出力O2を使用することができる。甲が取引出力O2を使用した場合には、秘密値aが公開され、乙は取引出力O1を使用することができる。即ち、甲及び乙が夫々所有する貨幣／資産を交換することができる。甲が取引出力O2を使用しない場合には、24時間経過後乙は6の取引を使って取引出力O2の貨幣／資産を自身の口座に移動することができる。48時間経過後甲は3の取引を使って取引出力O1の貨幣／資産を自身の口座に移動することができる。即ち、甲が何もしないで24時間経過すると交換が行われないまま一連の取引の執行の完了となる。

Majority is not Enough: Bitcoin Mining is Vulnerable 1

2014/06/11作成• 採掘者は共謀することによって共謀しない場合より多くの利益を得ることができる。• 利己的な採掘（selfish mining）• 合理的な採掘者は共謀を選択する。

• 共謀する採掘者の集団は拡大し続け、その要約値計算能力は最終的にネットワーク全体の要約値計算能力の過半数を超え、分散型の暗号貨幣系は崩壊するか、少なくとも分散型の暗号貨幣系ではなくなる（共謀する採掘者の集団によって管理される集中型の暗号貨幣に変貌する）。

• 共謀による採掘からネットワークを保護するBitcoin手続きの改良を提案する。• 共謀する採掘者の集団がネットワーク全体の要約値計算能力の1/4未満しか支配していない場合に限られる（それ以上支配している場合には、ネットワークは脆弱である）。

Majority is not Enough: Bitcoin Mining is Vulnerable 2

2014/06/16•利己的な採掘

• 発見した新しいブロックを公開しないで、そのブロックの先を採掘し続ける。他の採掘者が採掘しているブロック鎖の長さが自己の採掘しているものの長さに追い付いたら自己の採掘したものを公開する。

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

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)（三角不等式）

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つ識別子を生成し、ノード探索を実行する。

Kademlia3通信手続き

• 4つの遠隔手続き呼び出し

• PING• ノードが生きているか調べる。

• STORE• ノードに鍵と値の結合を格納する。

• FIND_NODE• 引数として識別子を取る。• ノードが知っている識別子に近いk個のノードの情報を返す（ノードがk個以下のノード情報しか知らない場合には知っている全てのノード情報を返す）。

• FIND_VALUE• 引数として識別子を取る。• ノードが知っている識別子に近いk個のノードの情報を返す（ノードがk個以下のノード情報しか知らない場合には知っている全てのノード情報を返す）。• ただし、鍵としての識別子に対応する値を有する場合には値を返す。

Kademlia4ノード探索（node lookup）、値探索

• 識別子に近いk個のノードを探索する。• FIND_NODE• 探索ノードは識別子に近いα個のノード情報をk-バケツから選出し、それらのノード情報に対応するノードに対してFIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。

• 新しく得たノード情報から識別子に近いα個のノード情報を選出し、それらのノード情報に対応するノードに対してFIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。

• 識別子に近いk個のノード情報に対応するノードで未だFIND_NODE遠隔手続き呼び出しを実行していないノードに対してFIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。

• 識別子に近いk個のノード情報に対応するノードからの応答を得られたら終わり。

• 識別子に近いk個のノードを探索しながら、鍵に対応する値を探索する。• FIND_VALUE• 上の場合とほぼ同様だが、値が取得できたら終わり。• 最後まで値が取得できなかったら、値は存在しない（可能性が高い。仮に存在していても取得する術がない）。

Kademlia5

• 鍵と値の結合は鍵と識別子の距離が近いノードに格納される。• FIND_NODE + STORE

• 一定時間毎に鍵と値の結合を距離が近いノードに再格納する。• FIND_NODE + STORE

• 新しいノードを発見したら新しいノードの識別子と距離が近い鍵と値の結合を新しいノードに格納する。• STORE

• 鍵に対応する値を取得する。• 鍵と近いノードで鍵に対応する値を保持していないノードがあったら、値を取得した後にノードに値を格納する。

• 取得した値はキャッシュする。値との間に多くのノードがあるノード程早くキャッシュが削除される。• FIND_VALUE + STORE

• ネットワークに参加したいノードは何らかの方法で1個以上の既にネットワークに参加しているノードの情報を入手し、ノード情報をk-バケツに挿入し、自身の識別子と距離が近いノードを探索する。• FIND_NODE

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

Technology

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