ジェネシスブロックの​謎 — なぜハードコードされ、​なぜ5日間採掘されなかったのか

ブロック0、すなわちビットコインのジェネシスブロックは、Bitcoin v0.1のソースコード内に定数としてハードコードされている。空のブロックデータベースで起動したノードは、ピアからブロック0をダウンロードせず、他のすべてのノードと同じパラメーターからローカルに再構築する。ブロックは暗号学的な意味で証明可能な作成者を持たない。50 BTCのコインベースは使用不能：AddToBlockIndex() 内の分岐構造が、ブロック0のコインベース登録経路を後続全ブロックと分けており、UTXOセットへの登録に必要なConnectBlock() 呼び出しをブロック0だけが経由しない。そして2009年1月3日のタイムスタンプから、最初に公開採掘されたブロック1（2009年1月9日）まで、サトシの採掘プロセスが後続ブロックを残さなかった5日間がある。本分析はソースコードの機構を読み、それが5日間の空白・帰属・使用不能コインベースという、ジェネシスブロックをめぐる3つの長期論点に何を示唆するかを検討する。

技術的事実はBitcoin v0.1ソースコードで検証可能。

2009年1月8-12日のリリース週におけるサトシ本人の運用環境についての独立した推論は、サトシのリリース期環境分析を参照。

1. 本分析で用いる核心的区別

これらの区別は本分析全体で一貫して用いる。§4と §5はこの区別に依拠している。

2. ハードコードされたパラメーター

Bitcoin v0.1のsrc/main.cppでは、ブロック0の全フィールドがコンパイル時定数として埋め込まれている。

• hashGenesisBlock = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f（L24）
• nTime = 1231006505（2009-01-03 18:15:05 UTC）
• nBits = 0x1d00ffff
• nNonce = 2083236893
• pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
• 期待されるマークルルートと期待されるブロックハッシュも定数としてassertされる

v0.1にはMineGenesisBlock() 関数は存在しない。ランタイムでジェネシスのナンスを探索するコードパスは存在しない。LoadBlockIndex() が空のデータベースを検出すると、上記定数からジェネシスブロックを決定論的に再構築し、ハッシュをassert() で検証してディスクに書き込むだけである。

Yes経路の分岐は、ノードのライフタイムで一度だけ、すなわち空のDBでの初回起動時にのみ実行される。ピアとの接続は不要、PoW検証も呼ばれない。ブロック0のコンセンサスはハッシュ等価性のみ。

現代のBitcoin Core（src/kernel/chainparams.cpp）も同じ4つの定数（1231006505, 2083236893, 0x1d00ffff, 1）を使用する。この機構は17年間変わっていない。

実用上の帰結：

• これまで空のブロックデータベースで起動した全ビットコインノードは、各自のローカル環境でバイト単位で同一のブロック0を構築してきた
• どのノードもブロック0を他ノードから受信していない
• 「ブロック0を作成する」ことに採掘は要求されない
• ブロック0は唯一である。全ノードは配布経路なしで同じ唯一のブロックを手元に組み立てる

3. 5日間の空白

ブロック0のタイムスタンプは2009-01-03 18:15:05 UTC、ブロック1は2009-01-09 02:54:25 UTC。間隔は5日8時間39分で、想定されている10分間隔の約770倍に相当する。

この空白をめぐってBitcoin Wikiやピート・リゾの2024年Bitcoin Magazine記事等では、バックデート説、天地創造説、美しいハッシュ説、プレネット仮説、ピア発見要件説など様々な説が語られてきた。だが、これらを同じリストに並べて「ギャップの原因の選択肢」として扱うのはカテゴリーの誤りである。技術的には設問が二つ混在している:

• Q1. ギャップそのものは、なぜ存在するのか。
• Q2. その5日間に、サトシは何をしていたのか。

Q1は構造的にほぼ確定する。Q2は公開記録からは不定のまま残る。本節はこの二つを明確に分離して扱う。

3.1 Q1 (ギャップの原因): ハードコードとリリース日の差

Q1の答えは、仮説の選択ではなく、ソースコードから直接読み取れる構造として確定する:

5日間の空白は、ハードコード値が決定された日と、ライブネットワークが初めて起動した日の差である。ライブチェーン上で実際に経過した時間ではない。

時系列での整理：

ブロック0とブロック1は同一の夜に生まれた実質的な兄弟である。「サトシが5日間ブロック0だけを抱えて待っていた」というイメージは、空白を経過時間として読むことで生じた副産物にすぎない。

従来の「バックデート説」「タイムズの見出しに合わせた遡及的タイムスタンプ設定」「ハードコード・アーティファクト」などは、すべて同じ構造を別の言葉で述べたものであり、互いに競合する仮説ではない。単一の現象に対する複数の命名である。

3.2 Q1の反転: なぜ1月3日に間に合わなかったのか

Q1の形を反転すると、なぜ1月3日にリリースできなかったのかという、より実質のある論点が立ち上がる。タイムスタンプを1月3日に選んだ時点で、1月3日は目標日付だった。実際の公開は1月8日で、メーリングリストへの告知にSourceForgeのダウンロードリンクが付いていた。ブロック1のマイニングは1月9日02:54:25 UTC（チェーン上の確定、nTime。サトシのノード起動はその数分前と推定されるがチェーン上には残らない）。5日間の空白は、目標に間に合わなかった開発者の遅れと読めるが、次段落で述べる通り、記録はこれを判定できない。

2009-01-08 19:27:40 UTCの暗号学メーリングリスト告知（metzdowd.com archive）から2009-01-09 02:54:25 UTCのブロック1マイニングまで約7時間半しかないという公開記録の手がかりは、「余裕を取った計画通りの進行」よりも「ぎりぎりの仕上げ」を弱く示唆する。ただしこの推測はソースコードとチェーンデータからは判定できない。

3.3 Q2 (期間中の活動): 経験的に不定

Q1とは独立に、2009-01-03 〜 01-08のあいだサトシが具体的に何をしていたかは、公開記録からは確定できない。冒頭で列挙した従来の「仮説群」のうちバックデート説以外は、本来このQ2のカテゴリに属する:

これらはQ1のギャップ原因ではなく、Q2の期間中活動の推定材料として位置づけるべき情報である。同じリストに並べると5日間の空白が単一の謎として誇張されるが、実際には構造的に確定したQ1と経験的に不定のQ2に分解される問題にすぎない。

4. 「ブロック0の作者」とは何か

決定論的再構築には、あまり明示されない構造的な帰結がある。本節では同じ論点を二つの層に分けて整理する。

4.1通常のブロックとブロック0の構造的差異

通常のブロックには、明確に定まる単一の帰属対象、すなわち最初にPoWを解いてブロックをブロードキャストしたマイナーが存在する。ブロック0ではそのマッピングのあらゆる列が異なる：

「全ノードが各自構築する」は「複数の異なるジェネシスが存在する」意味ではない。ハッシュ定数（機構A、§5）がコンセンサスレベルで「正しいジェネシスは唯一」を強制し、自動構築分岐（機構B、§5）が「その唯一のブロックを配布なしに各ノードが構築可能」にする。結果として、唯一のブロックに対して単一の出所が存在しない。

4.2認識論的層：ナンス探索

ハードコードされたナンス2083236893は、誰かのマシン上でv0.1リリース以前に一度だけ実行された物理的計算に対応する。総当たり探索が必要で、探索は2009-01-08より前であればどのマシンでも可能であった。

この探索をサトシが行ったという帰属は状況証拠に依拠する：

• サトシが定数を含むソースコードを公開した → サトシが値を決めた、もしくは知っていた
• タイムズの一面の引用がコインベースを特定の日付以降に固定する。サトシは当該期間に活動が確認されている
• コインベースの出力アドレス1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNaはサトシのものとされるが、対応する秘密鍵からの有効な署名提示は一度もない
• ラーナーのPatoshiパターンが初期約64ブロックを単一マイナーに結びつけており、連続性からそのマイナーがブロック0のナンス探索も行ったと推定される

ただし：

• Patoshiパターンは ブロック1以降からしか復元できない。ブロック0のコインベース構造は特殊で、統計的手法の適用対象外である。PLOS ONE 2021の論文及びラーナー自身の記述で明記されている
• ラーナー自身は「Patoshi」と「Satoshi」を同一視する主張を明確に回避している

チェーンデータから区別できないこと：

• ブロック0がv0.1リリース前に構築され一度破棄されたのか、それともリリース後にサトシ運用のノード上で初めて実体化したのか
• ナンス探索を行ったのは誰か
• ナンス探索が完了したのはいつか

認識論的レベル（利用可能な証拠から何が結論できるか）では、ブロック0のナンス探索の帰属は不定である。存在するのは暗号学的証明ではなく、状況証拠の強い集積のみ。

ただしこの枠組みは「単一の正解が存在するが、記録がそれを明らかにしていない」という前提を置いていることに注意する。次のサブセクションでは、この前提そのものを問い直す価値があると論じる。

4.3存在論的層：ナンス探索者はブロック0の作者ではない

ナンス探索を行った人物は「ソースコードに埋め込む値を計算した人」であった。その人物は以下のいずれでもない：

• ブロック0の所有者ではない（コインベース出力がUTXOセットに入らない、§6）
• ブロック0の配布者ではない（配布が存在しない、§4.1）
• ブロック0を他者に渡した事実がない（各ノードが定数からブロックを組み立てる）

値がソースコードに埋め込まれた瞬間から、それは定数となる。コンパイルして実行する誰もが、同じ定数から同じブロックを再構築する。値の歴史的起源（誰が探索したか）は、チェーン上のアーティファクトから切り離される。

「マイナー = 作者」という等式は、通常のあらゆるブロックに対して自然である。ブロック0では崩れる。「マイナー = 作者」を意味あるものとする構造的条件（PoWを唯一の構築事件とすること、ピア配布を唯一の出所とすること、UTXO登録を唯一の所有機構とすること）がすべて、設計によって欠けているからである。

存在論的な読みでは、ブロック0は「単一の作者が存在するが、特定できない」という状況ではない。「単一作者という概念がこのオブジェクトに対して適用できない」という状況である。「作者はサトシ一人なのか、サトシと協力者か、それとも別人が値だけサトシに渡してコードに埋め込ませたのか」という問いかけに特権的な答えはない。それは記録が不完全だからではなく、設計が単数値の作者エンティティをそもそも実体化していないからである。

4.4「サトシがビットコインを作った」 — 慣習的帰属と技術的帰属

「サトシがジェネシスブロックを作った」という言明は、文学的・歴史的記述として有意味であり続ける。サトシはv0.1ソースコードを書き、ハードコード値を決め、状況証拠から最も可能性の高いナンス探索者である。これらは強い根拠である。

しかしその言明は、他のどのブロックに対する同じ言明とも等価ではない。「ブロックNのマイナーはYである」は技術的に裏付けられる。コインベース出力アドレスが特定の秘密鍵保有者に報酬を結びつけ、PoWの痕跡がチェーン上で採掘イベントを記録するからである。ブロック0については、コインベースアドレス自体がハードコードされた定数（秘密鍵保有は未検証）であり、PoWの痕跡もチェーンデータ上のブロック0には付随しない。

したがって「サトシがブロック0を作った」は、「サトシがコードを書いた」「サトシがソフトウェアをリリースした」という別レベルの事実から推論された慣習的な帰属言明である。チェーン上の意味での技術的な帰属言明ではない（チェーン上の帰属を支える技術的装置がブロック0に関与していないため）。

4.5匿名化vs脱帰属設計

§5の議論を貫く核心的区別：

サトシの匿名化実践とブロック0の設計は、同じ種類の操作ではない。前者は存在するシグナルを隠す。後者はシグナルそのものを生まない。§5は、この第二のモードこそがブロック0設計のより強い読みであり、匿名化実践の延長や強化ではなく、質的に異なるものであることを論じる。

5. ハードコード機構の設計分解

5.1 2つの独立した機構

v0.1のジェネシス処理は、論理的に独立な2つの機構に分解できる：

5.2ハッシュ一致検証だけで済ませる代替設計

想定可能な代替案：

1. ソースコードにはhashGenesisBlockのハッシュ定数のみ埋め込む
2. 空DBで起動した新ノードは、最初のピアからブロック0データを受信する
3. 受信データのハッシュを計算し、定数と一致すれば採用、一致しなければ拒否

これは他の全ブロックで使われる通常の処理と同じ構造をブロック0にも適用するだけで、実装的にはむしろ小さい。新規に空DB分岐を加える必要がなく、既存のネットワーキング処理の再利用で済む。

この代替設計では、ブロック0には配布元が存在する。最初にナンスを発見した人（＝ ブロック0の最初の実体化者）だけがブロック0のデータを持ち、その配布元はP2P層に痕跡を残す。各初期ピアは誰か特定ノードから最初のブロック0を受け取るため、起源痕跡が残り得る。その痕跡が実ネットワーク条件下で起源を一意に特定できるかは別の経験的問題だが、本分析にとって必要な構造的主張はより狭い：配布元という概念が発生する、ということで十分である。機構Bはこの概念そのものを消している。

5.3ソースコードは対称、行動証拠は非対称

サトシは機構Bを選んだ。その選択の2つの読み：

解釈A：実装上の便宜。自動構築は、新ノードがライブピアなしでブートストラップできるようにするための素直な実装。未帰属性は、最短立ち上げを優先した結果として生じた意図しない副産物。

解釈B：脱帰属設計（un-ownership by design）。ブロック0は、作者が明確に定まる対象として成立しないように構築されている（§4.3）。これは「意図的な匿名化」よりも正確に述べた表現である。匿名化は存在する著者の識別情報を隠蔽する操作を前提とするが、脱帰属設計は著者を明確に定まる概念として構造レベルで成立させない。

ソースコード単体では解釈AとBを判別できない。v0.1が実際に行っていることは両解釈と技術的に矛盾しない。このレベルではどちらを採るかは解釈的判断である。

しかし周辺の記録を加味すると、両解釈の重みは均等ではない：

1. 代替設計の方が厳密に小さい。ハッシュのみ検証 + ピア受信によるブロック0取得は、既存のネットワーキング処理を流用し、空DB分岐を追加する必要もない。もし実装上の便宜が実際の動機なら、小さい設計の方が自然な選択となる。自動構築はより大きい実装であり、この選択は小さい設計なら節約できたはずの複雑さを支払っている
2. 公知の行動パターンとの整合性。Tor、使い分けメールアドレス、英米スペル混在、打鍵パターン配慮、自発的離脱、wallet.dat削除は、すべて同じ方向を指す：識別シグナルを残さない（層別の全体像はサトシの匿名性アーキテクチャ分析に記載）。そのパターンのうちジェネシス設計だけを「便宜」と読み、他を「意図的」と読むのは、記録の対称性を破る唯一の解釈になる
3. コインベースアドレスを共有定数にしたこと。呼び出しごとに生成すれば、個人的シグナルがもう一つ残っていた。ソースに共有定数として埋め込む選択は「個人特定の手がかりを残さない」と整合する
4. **タイムズの見出しが唯一の個人的要素。**ナンス、アドレス、処理構造はすべて非人格化されている。唯一、個人の声を帯びるのはコインベースペイロードのテキストだけ。他を徹底して非人格化しながら一点だけ意図的に例外を置いた設計は、「意図的」と読む方が「偶然均質」と読むより自然。なおChain Bulletinの2020年分析は同じ見出しを「英国紙＋英国式スペル慣習」として地理的証拠に読み替え、ロンドン在住仮説を支持する。同じ残存シグナルを「意図」ではなく「地理」に読む別視点である
5. §6と同じオッカムの剃刀。 §6は50 BTC使用不能を「見落とし」ではなく「初期状態として扱った帰結」と論じる。前者は追加の仮定を必要とし、後者は必要としないためである。ここに対称的に適用すると：解釈Bは追加仮定を必要としない。解釈Aは、他の選択が一貫して意図的なプロジェクトで、この一箇所だけ「特に理由なく」より大きく必須でない実装が選ばれたと仮定することになる

ソースコードレベルでAとBは対等である。記録の総体としては、Bの方が追加仮定を必要としない。本分析の以降のセクションはBをより蓋然性の高い読みとして扱うが、事実ではなく解釈として明示し続ける。

ソースコード自身が（AとBの判別とは独立に）はっきり示していること：未帰属性はブロック0に内在する性質ではなく、独立した設計判断の帰結である。別の、同等に成立する実装であれば配布元が存在していた。より大きく、必須でない実装を、配布元を持たない形で選んだ判断を下したのはサトシである。

5.4二次的観察：PoW余裕（ジェネシスハッシュの目標値を下回る幅）

機構Bはブロック0に見える唯一の必須でない設計選択ではない。ジェネシスハッシュは難易度1の目標値を数値的に大きく下回っている。これはより小さく解釈的な観察ではあるが、正確に述べておく価値がある。

3つの層を、各層が実際に何を検証するかに即して整理：

v0.1コンセンサス上、ブロック0はハッシュ等価性検証のみで通る。理論上は任意のハッシュ値でもプロトコル上は動作した。実際のジェネシスハッシュは難易度1の境界を余裕をもって満たしており、数値的に意味のある差を持つ。この余裕を「意図的な設計シグナル」と読むかどうかは、§5.3の配布元の議論より根拠が弱い論点である：

• 解釈A：余裕は保守的な実装選択と読める。外部者が標準的なPoWチェックを難易度1で走らせた時、境界すれすれで通るのではなく余裕を持って通る方が安全なためである
• 解釈B：同じ余裕は重み付け的な刻印と読める。この読み方では、非人格化された設計の中で、タイムズの見出し（編集的コンテンツ）と、目標値を明らかに下回るハッシュを、設計が依然として帯びる個別的要素の2つとして残すことになる

ソースコードは両解釈を鋭く分けない。観察は解釈Bと整合する（特に見出しと組になった時に顕著）が、保守的エンジニアリングの読みを単独で排除できない。§5.3のように小さい代替実装が存在して選ばれなかったというケースと違い、ここでの代替（境界すれすれのハッシュ）は構造的ではなく様式的なものである。

したがって、ここで指摘するに値するパターンは「サトシはジェネシスに意図的重みを加えた」より狭い：

「8桁が要求、10桁が観察」という枠組みは数値比較を桁数カウントと取り違えるため、この弱い強度で述べる。

探索モードの考察。2009年頃のCPU SHA-256dハッシュレートのオーダー（約1〜10 MH/s、ラーナーのPatoshi推定と整合）では、観察されたジェネシスハッシュのナンス探索は数時間から数日のスケールに落ちる。観察結果と整合する探索モードは二つあり、チェーンデータからは区別できない：

• ターゲットベース：目標となる先頭ゼロ桁数に達するハッシュが見つかった時点で停止する。上記レートでは先頭ゼロ10桁の期待到達時間は1〜2日程度
• ハーヴェスト・ベスト：事前に決めた探索時間（実時間）だけ回し続け、その時点で見つかっていた最良値を採用する。1月3日〜1月9日のギャップ区間のスケールで走らせた場合、期待される最良の先頭ゼロ数は10桁前後に落ちる。これは観察値と数値的にサイズが一致する

ハーヴェスト・ベストの読みは「意図的に深さNを選んだ」という読みに対する真の代替となる：これに従えば、10桁という結果は別途選ばれた目標ではなく、選ばれた探索時間の統計的帰結となる。これは §5.3の機構B論証（小さい代替設計が存在して採られなかった、という点に依拠する）を変更するものではない。ただし、PoW余裕を解釈Bと整合させる経路が両方成立することを意味する（ターゲットベースでは「意図的な深さ」、ハーヴェスト・ベストでは「意図的な時間」）。その意味で、特定の探索モードが判定不能なままでも、観察自体が設計スケールのシグナルとしてやや強固になる。

6. 使用不能な50 BTC — ブートストラップの帰結

6.1技術的挙動

ブロック0の50 BTC報酬は一度も動いていない、かつ動かせない。v0.1でも現代のBitcoin Coreでも、空DBからのジェネシス構築はブロック0をブロックデータベースには書くが、コインベース出力をUTXOセットには書かない。現代chainparams.cppのコメントに明記されている：「コインベーストランザクションの出力は使用できない、元来データベースに存在しなかったため」

Bitcoin Wikiは「意図的に行われたか偶発的に行われたか不明」と控えめに記述している。ビットコイン史上のあらゆる他のコインベース出力は、ブロック・チェーン設計ページに記録されている通常の成熟規則(100承認後に使用可能)に従う。ブロック0のコインベースだけが、その規則の唯一の例外として今も残っている。

6.2偶発vs意図的ブートストラップ解釈

マイニング主体のブロック処理系に生じた不整合として読むと、この挙動は穴に見える。通常のブロック処理はProcessBlock → AcceptBlock → AddToBlockIndex → ConnectBlock → ConnectInputs → txdb.AddTxIndexと一本の連鎖で走る。ジェネシスの空DB分岐はblock.WriteToDiskとblock.AddToBlockIndexしか走らず、ConnectBlockを呼ばない。したがってAddTxIndexも呼ばれず、コインベースはトランザクションインデックスに入らない。

別の枠組みで読むと、記述対象そのものが変わる。ブロック0は「最初に採掘されたブロック」ではない。ネットワークの初期状態であり、定数からのブートストラップ構築物であって、受信したマイニングイベントではない。この枠組みの下では、従来「見落としの証拠」と読まれていた5つの観察はすべて、設計通りの期待挙動となる：

現代Coreのコメントをこの枠組みで読み直すと、レガシーな変則への言い訳ではない。「元来データベースに存在しなかった」は記述そのものである：ブロック0はトランザクションイベントとして起こったことがないので、その出力はトランザクションとしてインデックスされない。

オッカムの剃刀はブートストラップの読みの方を支持する。偶発の読みは、エッジケース処理が概して綿密なリリースにおいて、見落としが一箇所存在したと仮定する必要がある。ブートストラップの読みは何も仮定する必要がない。観察される挙動はすべて、一つの意味論的選択から導出される。

6.3 §4との統一構造（二重の不在）

§6.2のブートストラップ枠組みは、§4の存在論的な読みと直接接続する。ブロック0を定数から導かれる初期状態として扱い、P2P層を介して到着するブロックとは見なさないという同じ設計判断から、二つの整合的な不在が同時に流れ出る：

Block 0 = ブートストラップ初期化（意図的設計、解釈 B）
  ├── 自動構築：ネットワーク観察できる出所なし
  │     → チェーン上で単一作者が確定しない（§4 — 創造的帰属の不在）
  └── 初期状態、トランザクションイベントではない
        → コインベース出力が UTXO セットに入らない（§6 — 経済的帰属の不在）

ブロック0は両軸とも構造的に帰属を欠く：暗号学的に特定可能な作者も、暗号学的に特定可能な受益者もない。解釈Bのもとでは、これらは二つの別個の偶然ではなく、一つの整合的な設計意図の二つの帰結である。ブロック0は、どちらの軸でも特定の誰かに属さないアーティファクトとして世界に置かれた。

6.4ジェネシスアドレスへの献金

ブロック0の後に1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNaに送られたトランザクション（累計100 BTC超の献金・チップ）は、初期状態除外の対象にはならず、通常の出力である。秘密鍵保有者なら使用可能。それらも一度も動いていない。秘密鍵が実在するなら、その保有者が無活動であることの弱い傍証。

6.5秘密鍵保有性 — 切り離して扱うべき別次元

本分析の全セクションとは別の論点：ブロック0のコインベース出力アドレスに対応する秘密鍵を、誰かが保有しているのか？

混同しやすいので次元を整理する：

鍵保有性の技術的状況：

• コインベース出力の公開鍵はハードコードされた定数である。対応する秘密鍵は数学的に存在する（ある時点で誰かが生成した）
• 誰が生成したか（サトシ推定）は状況証拠のみ
• 誰が現在保有しているかは不明である。有効な署名は実演されていない
• 50 BTCはUTXOセットから除外されている（§6.1）ため、鍵を保有してもそのコインを動かすことはできない。一方で、任意のメッセージに署名することは技術的に可能である。ただし実演はされていない

後のサトシ帰属鍵との関係：ブロック0のコインベースアドレスはソースコード上のハードコード定数である。ブロック1以降の初期ブロックのコインベースアドレスは、サトシのウォレットがブロックごとに新規鍵ペアを生成したものである。ブロック0の鍵は、約110万BTCのPatoshiパターン保有量を構成する数千のアドレスのどれとも一致しない。ブロック0の鍵は唯一かつ独立である。

クレイグ・ライト / COPA v. Wright裁判はこの領域の代表的な公の事件である。2016年以降クレイグ・ライトは「自分はサトシである」と主張し、身元証明の軸を ブロック1〜9の鍵での署名に置いた。最も注目を集めた2016年5月のブログ投稿は、2009年のブロック9（サトシ→ハル・フィニー送金）から再利用した署名であることが即座に指摘された。ライトの公の主張と実演はブロック0（ジェネシス）のコインベース鍵には及んでいない。同時期の批判者たちが指摘したように、サトシ帰属の本当の試金石はブロック0の鍵での署名であり、ライトを含め誰もそれを提示したことがない。

2024年のCOPA v. Wright判決において、ジェームズ・メラー判事は約400ページの判決文でライトはサトシではないと認定し、その証拠提出を産業規模の偽造と特徴づけた。最も積極的な身元主張ですらブロック0の鍵に踏み込まなかったこと自体が記録の一部である：決定的たりえる単発の試験が、今日まで未実行のまま残されている。本アーカイブのクレイグ・ライト正体仮説エントリーも、このジェネシス鍵未署名という同じ不在をライトの主張に対する決定的な反証として扱っている。

シナリオ（すべてソースコードと整合、いずれもチェーンデータから確定不可）：

秘密鍵保有性は経験的に未確定である。§4の作者性および §6の使用可能性とは論理的に独立しており、§5の議論は特定の答えに依存しない。脱帰属設計の読みは、鍵保有性のどのシナリオによっても「チェーンオブジェクトとしてのブロック0に、明確に定まる所有者を回復する」ものにならないからである。

7. ソースコードによる検証（引証）

Bitcoin v0.1 src/main.cpp

• L24：const uint256 hashGenesisBlock("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f");
• L1420〜1489：LoadBlockIndex() — 空DB分岐でジェネシスブロックを構築・書き込み
• L1455〜1470：

  char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
  ...
  block.nTime    = 1231006505;
  block.nBits    = 0x1d00ffff;
  block.nNonce   = 2083236893;

• L1472：//// debug print, delete this later
• L1478：assert(block.hashMerkleRoot == uint256("0x4a5e1e..."));
• L1480：assert(block.GetHash() == hashGenesisBlock);
• L1485：block.WriteToDisk(...)
• L1487：block.AddToBlockIndex(...) — この経路ではConnectBlock() は呼ばれない
• L2195〜2199：while (vNodes.empty()) { Sleep(1000); ... } — 採掘開始前のピア待機

現代Bitcoin Core src/kernel/chainparams.cpp

• L57〜60：「ジェネシスブロックを構築する。コインベーストランザクションの出力は使用できないことに注意、元来データベースに存在しなかったため」
• L126：CreateGenesisBlock(1231006505, 2083236893, 0x1d00ffff, 1, ...)

v0.1と現行Coreで定数値は同一である。

8. 未解決の論点

• Patoshi ExtraNonceパターンがブロック0を形式的に含むか（PLOS ONE 2021論文は「最初の64ブロック」と言及するが、ブロック0の扱いを完全には明示していない）
• nTime = 1231006505がナンス探索時の実マシン時刻なのか、タイムズの掲載日に合わせて事後設定された値なのか。チェーンデータだけでは判定できない
• ナンス探索がターゲットベース（目標深さに到達したら停止）で行われたのか、ハーヴェスト・ベスト（一定の実時間だけ回した後に最良値を採用）で行われたのか。両モードとも観察されたナンスおよび1月3日〜9日のタイミングと整合し、チェーンデータからは区別できない（§5.4）
• 2009年1月3日〜8日にプライベートなテストネットワークが走っていたか（プレネット仮説）。§3で示したコード整備のみだったとする解釈と競合するが、どちらも現在までの証拠と矛盾しない
• ブロック0のコインベース秘密鍵を誰かが保有しているか、そうであれば誰か（§6.5）。有効な署名は実演されていない

ブロック0はビットコインの中で最も象徴的なアーティファクトであり、かつあらゆる軸で明確に定まる所有者から最も遠いブロックである。配布元がなく、特定可能な作者もいない。トランザクションイベントがなく、使用可能な出力もない。解釈Aではこの対は偶然、解釈Bではこの対は構造そのもの。ブロック0は、単数でも複数でも、特定の誰かに属する物として世界に置かれたのではない。それが追加仮定を必要としない読み方である。