Bitcoinの技術面を学ぶにはこれしかないと言われているほどの名著Mastering Bitcoin を今更読んだので、自分の中での復習を兼ねて、ところどころ解説付きでまとめを書いていきます。

元の本ではサラッと流されているところもしっかり解説するつもりでお節介に書いたので初学者の人には分かりやすいかもしれません。

日本語版PDFはここで無料公開されているので翻訳者の方々への感謝を常に感じながら読みました。

無料公開版ということもあって誤字脱字もたまにあったりするので、

しっかり製本されたものが読みたいという方はAmazonで買って読むことをお勧めします。

前回↓

第8章 マイニングとコンセンサス 前半

マイニングはBitcoinの最も根幹の発明部分であり、Bitcoinが非中央集権的なシステムを成り立たせているものです。

マイニングとは「トランザクションの検証プロセス」であり、「新規Bitcoinの発行プロセス」でもあります。

具体的には「暗号学的ハッシュアルゴリズム(SHA256)をひたすら計算する作業」です。

マイニングをするノードのことをマイナーと呼びます。

マイナーは、「新規発行されたBitcoin」と「各トランザクションに含まれる手数料」をインセンティブに計算資源を投入してマイニングをするのです。

⑴Bitcoin の発行量について

新たなbitcoin は約10分ごとに生成されるブロックに含まれ、何もないところから生成されます。

マイニングを通して新たに作られるbitcoinの量は約4年ごと(正確には210,000ブロックごと)に減っていきます。

2009年1月の時点で1ブロックあたり50bitcoinから始まり、2012年11月には半分の1ブロックあたり25bitcoinになりました。

この1ブロックあたりの発行量は指数関数的に減少し、64回の半減を繰り返して13,230,000ブロック(おおよそ2137年にマイニングされるはずのブロック)まで減少していきます。これ以降はbitcoinの最小通貨単位である1satoshiを下回ってしまうため新しくbitcoinを発行できなくなり、最終的には2140年あたりに1344万ブロック(13.44Mブロック)でほぼ2100万bitcoin(2,099,999,997,690,000satoshi)が発行されることになります。この後、ブロックには新しいbitcoinが含まれなくなり、マイナーはトランザクション手数料のみを通して報酬を得るようになります。

Bitcoinの供給量は以下のグラフのようになります。

また、1bitcoinあたりの発行量はあくまでも、発行できる”最大値”であり、実際マイナーはブロックを採掘しても、1bitcoinあたりの発行量よりも得る報酬を故意に少なくする可能性があります。そのようにする動機は不明ですが、そのようなブロックの可能性があるため、結果的な通貨総発行総量は単純計算したものよりも少なくなるかもしれません。

このように1ブロックあたりの発行量を制限することによってインフレを防ぐことができます。

一方で逆にBitcoinという通貨は本質的にデフレ傾向になると言われています。

⑵分散化されたコンセンサス(合意形成)

Satoshi Nakamotoの主要な発明はemergent consensus(創発的コンセンサス) に対する分散メカニズムであり、「通貨、トランザクション、支払い、および中央権力や信用に依存しないセキュリティモデル」といったBitcoinの全ての特徴はこの発明の賜物です。emergentは、"決められた行動による明示的な同意ではない"という意味で、”emergent consensusに対する分散メカニズム”は簡単にいうと”全員が完全に独立して好き勝手に動いても全体として最適に動くメカニズム”という感じでしょうか。

このBitcoinの分散化されたコンセンサスは以下のという4つの相互作用で成り立っています。

①独立したトランザクション検証
(全てのフルノードによる独立したトランザクション検証)

②マイナーによる独立したトランザクション集積
(proof-of- workアルゴリズムによる計算と結びついた、マイニングノードによるブロックへのトランザクションの集積)

③独立した新規ブロック検証とブロックチェーンへの埋め込み
(全てのノードによって新しいブロックが検証され、このブロックがブロックチェーンに取り込まれる)

④独立したブロックチェーン選択
(個々のノードで、proof of workを通して証明された最も多くの累積計算量を持っているブロックチェーンが選ばれる)

これらについて一つずつ説明していきます。

①独立したトランザクション検証

第2章・第6章で触れてきましたが、ウォレットなどの各ノードによって新しく作られたトランザクションは、Bitcoinネットワーク内の隣接ノードに送られ、Bitcoinネットワーク全体に伝搬していきます。

新しいトランザクションを受け取った全てのBitcoinノードは最初にトランザクションを検証します。これによって有効なトランザクションだけが次のノードに伝搬され、無効なトランザクションは最初にこのトランザクションに会ったノードによって破棄されます。

それぞれのノードは全てのトランザクションを以下の長いチェックリストを判断基準として検証します。

• トランザクションの文法、データ構造は正しいか
  
• インプットとアウトプットのいずれも空でないか
  
• byte単位のトランザクションデータサイズが MAX_BLOCK_SIZE よりも小さいか 
• それぞれのアウトプットvalueおよびtotal valueは許されている値の範囲内(0より大きく、2100万 bitcoinよりも小さい)にあるか
• インプットのいずれもhash=0, N=-1でないか(coinbaseトランザクションでないかのチェック) 
• nLockTime は INT_MAX 以下か
• byte単位でのトランザクションデータサイズは100以上か
• トランザクションに含まれている署名オペレーション数は、署名オペレーション回数上限よりも小さいか
  
• unlocking script(scriptSig)はスタックに数字をpushすることだけでき、locking script(scriptPubkey)は isStandard()関数の形式に合っているか(つまり”非標準"トランザクションは拒否されます)
  
• トランザクションプールorメインブランチブロックチェーンのブロックに同じトランザクションが存在しないか
  
• それぞれのインプットに対して、もしこのインプットが参照しているUTXOをトランザクションプールの他のトランザクションも参照していた場合、このトランザクションを拒否する
  
• それぞれのインプットに対して、メインブランチブロックチェーンかトランザクションプールにインプットが参照しているトランザクションアウトプットが見つかるかを確認する。もし参照しているアウトプットが見つからなければ、これはorphan(孤児)トランザクションとみなし、orphanトランザクションプールに まだこのトランザクションがなければ、orphanトランザクションプールにこのトランザクションを追加する
  
• それぞれのインプットに対して、もしインプットが参照しているアウトプットがcoinbaseアウトプットだった場合、このアウトプットは少なくとも COINBASE_MATURITY (100) の承認数を持っているか
  
• それぞれのインプットに対して、参照しているアウトプットがすでに使用されて使用不可になっていないか
  
• 参照しているアウトプットを使って、それぞれのインプットvalueとその総和が許されている値の範囲内(0より大きく、2100万bitcoinよりも小さい)にあるか
  
• もしインプットvalueの総和がアウトプットvalueの総和よりも小さければ拒否する
  
• もしトランザクション手数料が少なすぎて空ブロックに入れることができない場合は拒否する
  
• それぞれのインプットにあるunlocking scriptは、対応したアウトプットのlocking scriptを解除できるか (ECDSAデジタル署名の検証を参照)
  

※これらの判断条件は、Bitcoin リファレンスクライアントのAcceptToMemoryPool, CheckTransaction, CheckInputs 関数に定義されており、随時変更されて行く可能性があります。

検証の結果有効となったトランザクションを次のノードに伝搬すると同時に、各ノードがトランザクションプール 、メモリプール(mempoolと呼ばれる)を構築して、有効なトランザクションを保存して行きます。

トランザクションを受け取ったときや他のノードに伝搬させたりする前に独立にそれぞれのトランザクションを検証することによって、「ありもしないBitcoinを送ろうとしているトランザクション」や「他人のBitcoinを動かそうとしているトランザクション」などの不正や「そもそもトランザクションの程をなしていないデータを大量に送りつける」ことによるネットワークの攻撃に関するトランザクションがBitcoinネットワークを伝搬しないようになっているのです。

②マイナーによる独立したトランザクション集積

全てのノードは①の「独立したトランザクションの検証」を行いますが、いくつかのノードは同時に「マイニングによってブロックを作り出し、そこにトランザクションを集積する」という行為をしています。

これらのノードはマイニングノード、マイナーと呼ばれます。

マイナーは「SHA256アルゴリズムをひたすら計算し、特定のnonce(ナンス)を見つける[詳細は(b)で後述]」ことでブロックの生成権を得て、ブロックを生成することによって「そのブロックで新規に発行されるbitcoin」と「そのブロックに含めるトランザクションの総手数料」を手に入れることができます。

そのために、全てのマイナーはこのブロック権を得るための競争をしているのです。

(a)マイナーは何を生成するのか -報酬の計算、ブロックの構造、generationトランザクション-

まずはマイナー達が生成するブロックの構造を見ていきます。

ブロックの生成権を得たマイナーが生成するのは「ブロック生成報酬の集計値」、「generationトランザクション(coinbase トランザクション)」と「ブロックヘッダ」です。

1. coinbase報酬とトランザクション手数料の集計

generationトランザクションを構築するために、マイナーはまずは自身への報酬を計算します。

始めに、ブロックに含める全てのトランザクションの ‘Input - Output’の総和がマイナー自身に入る手数料になるので、これを計算します。

次に、そのブロックを生成することによって発行されるBitcoinをブロック高から計算します。

この計算は[⑴Bitcoin の発行量について]でも述べたようなロジックであり、bitcoin Githubのmain.cppのGetBlockSubsidy関数 (Subsidyは補助金という意味)で定義されています。

この部分のコードはわかりやすいので見て行くと、

nSubsidyが初期のマイニング報酬として設定されたもので、COIN定数(1bitcoinを示す、1億satoshi)に50をかけた50億satoshi(50bitcoin)です。

nSubsidyHalvingIntervalが、何ブロックごとに報酬を半減させるかを定義したもので別のソースコードで210,000ブロック と決められています。

nHeightというのがそのブロックのブロック高なので、nHeightをnSubsidyHalvingIntervalで割って求められるhalvingが今までに何回報酬が半減したかを表す回数です。

半減回数halvingが64以上になったら0をreturnするという部分で、最大半減回数は64回と決められていますね。64回目の半減以降はブロック生成によるBitcion新規発行がなくなるということです。

半減回数が64回未満の場合には、その半減回数の分だけ初期の50億satoshiを2進数右シフト演算(簡単にいうと”2で割る”操作)してその結果をブロック生成の報酬としています。

こうして求めたブロック生成による報酬(coinbase報酬)とトランザクション手数料の総和を合計したものがマイナー自身への報酬となります。

2. generationトランザクションの構造

generation(coinbase)トランザクションは、「そのブロックで新たに発行されたbitcoinをマイナー自身に送信するトランザクション」でした。

このgenerationトランザクションの構造を通常のトランザクションの構造と比較して以下の画像で見ていきます。

generationトランザクションは何もないところから生成されるトランザクションであり、インプットに入れるUTXOは存在しません。

そのため、UTXOのハッシュが入るTransaction Hashフィールドは全てのbitが0、UTXO内で何番目のアウトプットかを示すOutput Indexも全てのbitが1となっており意味のないものになっています。

通常Unlocking Scriptが入るところには、UTXOが存在せずunlockするlocking scriptも存在しないため、Coinbase Dataというデータが入れられます。

Coinbase Dataフィールドに入るデータは2byteから100byteの間のデータでないといけません。

version-2 ブロック(ブロックヘッダのversionフィールドが2)では、ブロック高をリトルエンディアンでエンコードした16進数の形でCoinbase Dataフィールドの最初に入れておかなければならないと、Bitcoin Improvement Proposal 34 (BIP0034)で決められています。

具体例で見て行きます。

ブロック277,316では、Coinbase Dataフィールドに 03443b0403858402062f503253482f という16進数(16進数では2桁で1byteなのでこれは15byteですね)が含まれていたとします。

最初の1byte 03 はscript実行エンジンに次の3byteをscriptスタックにpushするという意味です。

次の3byte 0x443b04 は、リトルエンディアン(逆読み、最下位バイトが最初に来る)でエンコードされたブロック高です。バイトの順番を逆にして 0x043b44 にし、これを10進数で読むと277,316になります。これがこのブロックのブロック高になっていますね。

(※1byte = 8bit で8bitは2進数で00000000 ~ 11111111までを表し、16進数では0x00 ~ 0xffを表します。0xは「これは16進数ですよ」という接頭辞です。)

Coinbase Dataフィールドの最後の部分(2f503253482f)は「 /P2SH/ 」のASCIIコード(文字列を数字で表したものと思ってもらえれば)で、このブロックを採掘したマイニングBitcoinノードがpay-to- script-hash (P2SH) をサポートしているということを示しています。

最初のブロック高と最後の「P2SH ASCIIコード」の間の数値は、どんな数値でも入れることができ、Coinbase Dataフィールド全体が100byteになるまでは拡張できます。

この余白部分は、多くの場合、proof of workアルゴリズムにおける適切なナンス解を探すためのextra nonceとして使われています。extra nonceについては後述します。

またマイニングプール[後述]によっては、「このブロックを生成したのは俺たちのプールだ！」の意味を込めて、プール名をここに記述する場合もあります。

ちなみにgenesisブロックのCoinbase Dataフィールドには、

日付と”The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"(リーマンショックの影響を受けた銀行へのイギリス政府からの資金援助に関する記事)というテキストが書き入れられています。

これはイギリスの新聞 タイムズ紙 のその日付での見出しであり、genesisブロックが2009年1月3日以前になかったことの証明になっています。

また、前例のない世界規模の金融危機と同時期にビットコインが稼働を始めたという事実の証拠であり、独立した金融システムの重要性を訴えるSatoshi Nakamotoからの永遠にブロックチェーン上に刻まれるメッセージなのかもしれません。

ちなみに僕はこれを知った時、カッコ良すぎて震えました。笑

<疑問点>

・coinbase報酬と手数料 は計算されるはいいものの、どこに含まれるの？coinbase トランザクションのインプットに入れ込まれるんじゃないの？

3. ブロックヘッダの構造

詳細は以下のようになっています。

Version ：versionは2で、このフィールドの4byte(0x00000002)をリトルエンディアンでエンコードした 0x02000000 が入ります。

Previous Block Hash：一つ前のブロックのブロックヘッダのダブルハッシュを入れます。この親ブロックをどれにするかはマイナーが任意に決定できます。(基本的に最新のブロックにしないとのちの承認プロセスで承認されませんが、。)

Merkle Root：第7章で説明したMerkle Treeから導かれるハッシュです。マイナーはそのブロックに含める全てのトランザクションデータからMerkle Treeを用いてこの値を計算します。

Timestamp：ブロッックが生成された時刻が、Unixの"Epoch"タイムスタンプのようにエンコードされた4byteのタイムスタンプで入ります。

Difficulty Target：後述するProof of Work アルゴリズムでマイナーが目標とする数値です。

Nonce：後述するProof of Workアルゴリズムでマイナーが正解を求めて調整する数値です。マイナーがブロックヘッダを生成した段階では初期値0です。

以上で見て来た、「coinbase報酬とトランザクション手数料の集計値」「generationトランザクション」「ブロックヘッダ」の3つをマイナーはブロックを生成する準備として生成するのです。

この3つが揃った準備段階のブロックを「候補ブロック(candidate block)」と言います。

マイナーはこの候補ブロックを用意した上で、次節で説明するproof-of-workアルゴリズムに対する解でこの候補ブロックを有効にするのです。

(b)Proof-of-Workアルゴリズムによる新ブロック生成権の付与

マイナーが生成するブロックの大体の構造がわかったところで、マイナーがブロックの生成権をどのように得るのかについて説明していきます。

ここで説明するのが「Proof of Workアルゴリズム(PoW)」です。

Proof of Workについて説明する前にこれまでも出て来たSHA256というハッシュ関数について軽く復習しておきます。(詳細はまた別にまとめようと思います)

ハッシュ関数は不可逆関数であり、以下の特徴を持ちます。

Aをハッシュ関数に通したものを B とすると、

①AからBを求めるのは(ハッシュ関数を通すだけなので)容易だが、BからAを求めるには「Aを総当たりでハッシュ関数に通してBになるものを探す」しか不可能

②同じAというものを同じハッシュ関数に通せば、どんな環境で誰がやっても同じBが得られる

③以下のSHA256を使った例のようにAに類似性があったとしても、ハッシュ関数を通して出力されたBには全く類似性がない

I am Satoshi Nakamoto0 => a80a81401765c8eddee25df36728d732...
I am Satoshi Nakamoto1 => f7bc9a6304a4647bb41241a677b5345f...
I am Satoshi Nakamoto2 => ea758a8134b115298a1583ffb80ae629…

「このSHA256というハッシュ関数を通した時に、dificultyという数値(例えば000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7) よりも小さい値が出力されるような値はなんでしょうか？」というのがProof of Workアルゴリズムの問いです。

もっと正確にいうと、「あなた(マイナー)が用意した候補ブロックヘッダは nonce の部分にどんな数字を入れたら、ダブルハッシュ(Double SHA256)に通した時にdifficultyよりも小さい値になるでしょうか？」というのがマイナーが解いている問題なのです。

ハッシュ関数の性質①より、マイナーはnonceの部分に手当たり次第に数字を入れていくしかありません。

ハッシュ関数の出力結果は完全にランダムなものと考えると、先ほどの例の

000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7(16進数)

がdifficultyだとすると0が先頭に14個並んでいるので、この0の並びを実現するには 単純計算で (1/16)の14乗 の確率ということになります。

つまり、difficultyの値が小さくなればなるほど正解の範囲が狭くなるので正解を見つけるのが困難になるということですね。

このDifficultyは、 (a)-3 ブロックヘッダの構造でも見た通り、ブロックヘッダの”Difficulty target”という4byteの枠に入れられています。

他のパラメータとは異なり、このDifficultyはブロックヘッダを構築するマイナー自身が決めることはできません(難易度を自分で設定できたらおかしいですよね笑)

以下でその表現記法とどのようにDifficulty targetが設定されるのかを見ていきます。

Difficulty の表現記法 「difficulty bits」

ブロックヘッダのDifficulty targetには、”difficulty bits"または単に"bits"と呼ばれる記法で記述されたデータが入れられます。

この記法はdifficulty targetを係数部/指数部形式で表すもので、最初の2桁の16進数が指数部(exponent)、次の6桁の16進数が係数(coefficient)です。

具体例で見ていきます。

ブロック277,316では0x1903a30cという値がdifficulty bitsに入っていたとすると、このブロックでは、指数部が 0x19 、係数が 0x03a30c と言うことになります。

この指数部(exponent)と係数(coefficient)から以下の式で求められる値がDifficultyとなります。

実際に計算してみると

10進数で表すと

16進数で表すと

となります。

この数字は16進数表現で最初の15桁つまり7.5byteが0であり、2進数で言うと、60bitが0になっています。このレベルのdifficultyは、仮に秒間10億個のハッシュ(秒間1テラハッシュ、または1TH/sec)を生成できるマイナーで考えると、平均的に8,496ブロックに1回解が見つかるだけ、59日に1回解が見つかるだけということになります。

Difficulty targetとRetargeting

Bitcoinのブロックは平均的に10分毎に生成されると言われていますが、年月が経つにつれてコンピュータの計算能力は指数関数的に上昇していますよね(ムーアの法則)。

ということは、このDifficultyが常に「その時点のコンピュータの計算能力で約10分で解ける難易度」に調整されていると言うことになります。

このDifficultyの調整をRetargeting(再設定)と言います。

分散化されたネットワークでこのDifficultyがどのように調整されているのでしょうか？

この調整は全てのフルノードで自動的に行われるようになっており、2,016ブロック毎に全てのBitcoinノードはproof- of-workのdifficultyをretargetします。(1ブロックあたりのBitcoin発行量が半減するのは21万ブロック毎でしたので混同しないように注意してください)

retargetingを行う時は、直近の2,016ブロックが生成されたのにかかった時間(Actual Time of Last 2016 Blocks) を測定して、1ブロック平均10分だとしたときの時間20,160分(10分間でブロック生成が起きたとするとこれは約2週間に相当)と比較します。

実際にかかった時間と求められる時間との比が計算され、調整が行われます。もしBitcoinネットワークが10分毎よりも速くブロックを見つけていればdifficultyは上がりま す。もしブロックの発見が予想よりも遅ければ、difficultyは下がります。

この調整の計算式は以下のような単純なものです。

コードはbitcoin Githubのpow.cpp のCalculateNextWorkRequired()関数に書かれています。

ただし、以下のような特別な注意点もあります。

①difficultyが極端に動きすぎないように、retargetingは調整ごとに4倍または1/4以内になるようになっています。もし急激な計算速度の上昇(下落)があり、必要なdifficultyの調整が4倍よりも大きいまたは1/4よりも小さい場合でも、最大でも4倍、最小でも1/4になりそれを超えたものにはなりません。その場合、1ブロックの平均生成時間が10分ではない不均衡状態が、次の2,016ブロックの間続いてしまいますが、さらなる調整は次のretargetingのときに行われます。

このような仕組みのため、コンピュータの計算能力が恒久的に想定外の伸び方(落ち方)をしない限り、ハッシュ生成速度とdifficultyの大きな食い違いは数回のretargetingを経て均衡するようになります。

②difficultyの調整は2016ブロックに1回起きますが、difficultyの調整は(本来すべき2016ブロックの総時間ではなく)前の2015ブロックの総時間に基づいています。この結果、difficultyは0.05%だけ高くなるようなretargetingバイアスが生じています。 この原因はオリジナルのBitcoin Coreクライアントにあるoff-by-oneエラーのためです。

DifficultyとBitcoinネットワークとの関係

difficultyはトランザクションの数とは何の関係もありません。つまり「Bitcoinがめちゃめちゃ利用されるようになってトランザクションの数が爆増した」場合、直感的にはネットワーク全体のコンピュータの処理能力も上がっていないといけないように感じますが、difficultyが常に「1ブロック平均10分」でブロック生成されるように調整されているので、ネットワーク全体の処理能力が何だろうと関係ありません。

また、マイナーは

平均して1ブロック生成するために投入しなければならない計算処理を動かすための電気代 < 1ブロックの報酬

であればマイニングをしますが、逆であればマイニングから撤退します。

日本でマイニングするマイナーを具体例にして考えると、

bitcoinが半減を二回経験し、coinbase報酬(1ブロッック生成した時に発行されるbitcoin)が12.5bitcoinだとします。

マイナーがブロック生成で得られる報酬は「12.5bitcoin + トランザクション手数料の総和」です。

今回の2016ブロックの間のdifficultyは0x1903a30c(difficulty bits)だったとし、このdifficultyの正解を一番初めに見つけるまでASIC(マイニング専用のスペシャルコンピュータと思ってもらえれば)を稼働するための電気代が平均して50万円だったとします。(必要な電力が20,000kW/h、1kW/hあたりの単価が25円としてます)

この時、bitcoinと日本円(JPY)の交換レートが「1bitcoin = 4万円」ならば、トランザクション手数料の分bitcoinが儲かるのでマイナーはマイニングをするかもしれません。

しかし、電気代は急激には変化しないと仮定した上で、bitcoin/JPYの交換レートが「1bitcoin = 2万円」に落ち込んだらどうなるでしょうか？

この時、ブロック生成でのマイナーの損益は、「(使用する電力 * 電力単価25円) - (日本円で25万円のcoinbase報酬 + トランザクション手数料)」となりますので、マイナーは

(1)使用する電力量を下げる

(2)トランザクション手数料を上げる

という選択肢を取らざるを得なくなります。

(1)の結果としてネットワーク全体の計算能力が下がりdifficulty retargeting でdifficultyは減少します。

このように「Bitcoinの価格(上記の例では対JPY)」「ネットワーク全体で使用される電力量」「電気代」「difficulty」「トランザクション手数料」は密接に関係しているのです。

<現状の疑問点>

・bitcoinのブロック生成が10分毎だから遅いって言うなら、このDifficultyを調整して早くしてやればいいんじゃないの？

→[第8章後半]で見ていくが、ブロック生成が早すぎるとフォークが頻発するため、トレードオフである。

(c)マイナーが新ブロックを生成して報酬を得る一連の流れ

以上で[(a)マイナーは何を生成するのか -報酬の計算、ブロックの構造、generationトランザクション-]、[(b)Proof-of-Workアルゴリズムによる新ブロック生成権の付与]を見てきました。

ここで、第5章でも登場したマイナーであるマイニング仙人を例にして、マイニングの一連の流れを説明していこうと思います。

マイニング仙人のマイニングノードはフルブロックチェーンデータを保持し、「新しく伝播してくるトランザクションをリレーする」「新しいブロックをマイニングする」「新しいブロックが送られてくるかどうかチェックする」ということを同時に行っています。

マイニング仙人のマイニングノードが保持している最新ブロックが277,314だと仮定して、その行動を見ていきます。

(1)

マイニング仙人のマイニングノードは、まず「coinbase報酬とトランザクション手数料の集計値」「generationトランザクション」「ブロックヘッダ」からなる次のブロック277,315の候補ブロックを作成します。

(2)

[①独立したトランザクション検証]で見たように、通常のノードが検証した新規トランザクションを自身のトランザクションプールに入れていくのに対し、マイニングノードは検証後の新規有効トランザクションを「候補ブロック(candidate block)」に入れていきます。

※この候補ブロックにトランザクションを入れていく過程は以下の「トランザクション年齢とトランザクション手数料による優先度の決定ロジック」に従います。

<ブロック内のトランザクションスペースの最初の50KB>

Value of Input = インプットにあるUTXOのbitcoinの額

Input Age = インプットにあるUTXOのblock depth (そのUTXOがどれだけ古いか)

Transaction size = そのトランザクションのデータサイズ

とした時の

という計算式で計算される優先度の高い順にトランザクションが入れられる。

<それ以降のトランザクションスペース>

トランザクション手数料をトランザクションのデータサイズ(KB単位)で割った値の高い順で入れられる。

(3) 

(1), (2)で次のブロックのブロックヘッダのnonce以外が完成すると、次のブロック277,315を完成させるためのnonceをひたすら計算していきます。

⑷

同時に常に伝播してくる新規のトランザクションをリレーしながら、蓄えていきます。

<注意点>

前もってたくさんの候補ブロックの雛形を生成しておいて、そこに新規トランザクションを蓄えていっていることもありそう

⑸ 

マイニング仙人が277,315のnonceを見つける前に、正解を見つけた他のノードからブロック277,315が送られてきたとすると、そのブロックを検証し、ローカルブロックチェーンに追加し、すぐに自分のメモリプールにある全てのトランザクションをチェックしブロック277,315に含まれていたトランザクションをメモリプールから削除していきます。

⑹

 ⑸の時点で277,315のマイニング競争にマイニング仙人は敗れたことになるので、新たに277,316の候補ブロックを作成します

⑺

 277,316の候補ブロックに(4)で集めていたトランザクションを入れていきます。

⑻

277,316のnonceをひたすら計算します。この時同時に(4)も行っています。

⑼

他のノードからブロックが送られてくる前にマイニング仙人が「ブロックヘッダハッシュがdifficultyよりも小さくなるnonce」を見つけたとすると、すぐにそのブロックを他のノードに送信し、自身のローカルブロックチェーンに277,316を追加します。

マイニング仙人から送信されたブロックは他のノードを伝播していき、他のノードはそれを検証後、自身のブロックチェーンに追加します。

続き↓