Mining Target

説明用に上限を 20 とすると、19 と 20 は合格ですが、21 は不合格です。実際のマイニングではずっと大きな数値を使いますが、関係は同じです。hash ≤ target は、厳密に小さいだけでなく、等しい場合も含みます。Bitcoin Core は、ネットワーク参加者がブロックや取引を検証するためのソフトウェアです。ここで参照する v29.0 も、ヘッダー全体のハッシュをこの方法で比較します。探索中に変更する nonce は入力値の一つであり、ターゲット以下になる必要がある計算結果そのものではありません。 [1]

ヤナは、長いゼロの列から始まる成功したハッシュの画像を見ます。これは便利な説明です。同じ長さの表記なら、先頭のゼロが多いほど数値は小さくなります。しかし、先頭のゼロが同数でも、二つのハッシュがターゲットの両側に分かれる場合があります。残りの桁も重要なのです。ゼロの数は完全な hash ≤ target の比較を代替しません。求められているのは見栄えのよい文字の並びではなく、厳密な数値条件です。 [1]

ビットはゼロか一を表し、八ビットで一バイトになります。長い数値をそのままヘッダーに保存しないよう、Bitcoin は 32 ビットの nBits フィールドを使います。係数、シフトを決める指数、符号ビットによって、256 ビットの数値空間のターゲットを符号化します。例えば 0x04123456 を数値に戻すと 0x12345600 になります。接頭辞 0x は文字も使う十六進表記を示します。これは符号化の例で、現在のネットワークのターゲットではありません。まずは数値そのものと短縮表記を区別できれば十分です。 [3] [5]

生データでは同じ数値が逆向きに見える場合があります。80 バイトのヘッダー内で nBits は四バイトを占め、最下位のバイトが先に来る little-endian 形式で保存されます。そのため数値 0x1d00ffff はデータ上で ff ff 00 1d と並びます。バイト順はターゲットを変えるものではなく、保存方法です。生データを扱う際の詳細であり、通常のブロックエクスプローラーの読者が表示された数値を逆にする必要はありません。 [2]

ヤナは、大きな数値を入れれば探索を楽にできると考えるかもしれません。しかしソフトウェアは、nBits を読めるかだけを確認するのではありません。Bitcoin Core v29.0 の DeriveTarget は負のターゲット、ゼロ、数値範囲のオーバーフロー、そのネットワークで許される最大ターゲット powLimit を超える値を拒否します。元の数値を読み取れても、何の数値を表すかが分かっただけで、使用が許可されたわけではありません。 [1]

許された範囲内のターゲットでも、特定のブロックには誤りとなる場合があります。Bitcoin Core は nBits を、前のブロックとネットワークのルールに基づく GetNextWorkRequired の計算結果と比較します。不一致なら bad-diffbits になります。自分で設定した容易なターゲット以下のハッシュを見つけても、ヘッダーの誤った値は正当化できません。ヤナが要件を緩めるだけで承認されるブロックを作ることはできず、ルールを検証するコンピューターである他のノードが拒否します。 [4]

256 ビットのハッシュが一様に分布するモデルでは、すべての結果が同じ確率で発生します。有効なターゲット T に対して、ゼロから T までが両端を含めて受け入れられます。したがって一回の試行では p = (T + 1) / 2^256 となり、p は成功確率です。足した一はゼロも数えるためです。この関係から、低いターゲットほど難しい理由が分かります。ただし、機器が毎秒何回試せるかや、次のブロックがいつ現れるかは分かりません。 [1]

条件を満たしたヤナが証明したのは必要な計算作業であり、ブロック内のすべてが正しいことではありません。Bitcoin Core は、取引をまとめた指紋、coinbase という特別な報酬取引、ブロックの制限、取引の有効性も検証します。ここで coinbase はブロックの最初の取引の技術的名称で、取引所のことではありません。低いハッシュでも無効な内容は修正できません。ターゲットは重要なルールの一部であり、残りを無視する許可ではないのです。 [4]