ジェネシスブロックの​謎 — なぜコードに​書き込まれ、​なぜ5日間、​次の​ブロックが​掘られなかったのか

ブロック0、すなわちビットコインのジェネシスブロックは、Bitcoin v0.1のソースコードの中に、決まった値（定数）として書き込まれている。ブロックのデータベースが空のまま起動したノードは、ブロック0をほかのノードからダウンロードせず、ほかのすべてのノードと同じ値を使って、自分の手元で組み立て直す。このブロックには、暗号で証明できる作り手がいない。50 BTCのコインベースは使えない。AddToBlockIndex() の中の分かれ道で、ブロック0のコインベースだけが、ほかのすべてのブロックと別の道を通り、UTXOセットに入るのに必要なConnectBlock() を通らないからである。そして、2009年1月3日のタイムスタンプから、公開されて最初に掘られたブロック1（2009年1月9日）までのあいだ、サトシの採掘のプログラムが次のブロックを一つも残さなかった5日間がある。ここでは、ソースコードの仕組みを読み、ジェネシスブロックをめぐって長く議論されてきた三つの問題、つまり5日間の空白、誰が作ったと言えるのか、使えないコインベースについて、その仕組みから何が言えるかを考える。

技術の事実は、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」の道は、一つのノードにつき一度だけ、つまり、データベースが空の状態で初めて起動したときにだけ通る。ほかのノードとつながる必要はなく、PoWの確認もしない。ブロック0について全員が合意するのは、ハッシュが一致するかどうか、という点だけである。

今のBitcoin Core（src/kernel/chainparams.cpp）も、同じ4つの定数（1231006505, 2083236893, 0x1d00ffff, 1）を使っている。この仕組みは17年間変わっていない。

実際には、次のことになる：

• これまでに、データベースが空の状態で起動したビットコインのノードは、どれも、自分の手元で、1バイトも違わない同じブロック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日間の空白は、コードに書き込む値を決めた日と、本物のネットワークが初めて動き出した日の差である。動いているチェーンの上で、実際に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のあいだ、サトシが具体的に何をしていたかは、公開の記録からは決められない。冒頭に挙げたこれまでの説は、日付をさかのぼらせた説を除けば、どれもQ1ではなくQ2の論点である:

これらは、Q1の空白の原因ではなく、Q2の期間に何をしていたかを推し量る材料として扱うべきものである。一つの一覧に並べると、5日間の空白は、大きな一つの謎に見える。だが実際には、仕組みから答えの決まるQ1と、記録からは決められないQ2に分ければすむ問題である。

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

ブロック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では、どれも、設計によって欠けているからである。

問いが成り立つかどうかの層で見ると、ブロック0は、「作った人が一人いるが、誰かは分からない」という状態ではない。「一人の作った人、という考え方が、このブロックには当てはまらない」という状態である。「作者はサトシ一人なのか、サトシと協力者か、それとも別人が値だけサトシに渡してコードに埋め込ませたのか」という論点には、どれか一つを正しいと言える答えがない。記録が不完全だからではない。ただ一人の作者がいる、という形を、設計が初めから作らないからである。

4.4 「サトシがビットコインを作った」 — 習慣としての言い方と、仕組みの上での言い方

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

しかし、この言い方は、ほかのブロックについて「誰々が掘った」と言うのと同じ意味ではない。「ブロックNを掘ったのはYだ」ということは、技術の上で裏付けられる。コインベースの出力のアドレスが、報酬を、ある秘密鍵を持つ人に結びつけ、PoWの跡が、チェーンの上に、掘ったという事実を残すからである。ブロック0では、コインベースのアドレスそのものが、コードに書き込まれた定数で（秘密鍵を誰が持つかは確かめられていない）、チェーンのデータにあるブロック0には、PoWの跡も付いていない。

だから「サトシがブロック0を作った」は、「サトシがコードを書いた」「サトシがソフトウェアを公開した」という、別の種類の事実から推し量った、習慣としての言い方である。チェーンの記録から、技術の上で作り手を言い当てたものではない（チェーンで作り手を決める仕組みが、ブロック0には働かないため）。

4.5 身元を隠すことと、誰のものにもならない設計

§5の議論の芯になる区別である：

サトシが身元を隠したやり方と、ブロック0の設計は、同じ種類のものではない。前者は、もともとある手がかりを隠す。後者は、そもそも手がかりを生まない。§5では、後者のほうが、ブロック0の設計の読み方として説得力があり、身元を隠す工夫をさらに強めたものではなく、種類の違うものだと論じる。

5 値をコードに書き込む仕組みを分けて見る

5.1 別々の2つの仕組み

v0.1のジェネシスブロックの処理は、互いに独立した2つの仕組みに分けられる：

5.2 ハッシュが合うかを確かめるだけですませる、別の設計

考えられる別の設計は、こうである：

1. ソースコードには、hashGenesisBlockのハッシュの定数だけを書き込む
2. データベースが空のまま起動した新しいノードは、最初につながったノードから、ブロック0のデータを受け取る
3. 受け取ったデータのハッシュを計算し、定数と合えば使い、合わなければ受け取らない

これは、ほかのすべてのブロックに使う普通の処理を、ブロック0にも当てはめるだけなので、作るのはむしろ簡単である。データベースが空のときの分かれ道を新しく足す必要もなく、もとからあるネットワークの処理を使い回せばすむ。

この設計なら、ブロック0には配った人がいることになる。最初にナンスを見つけた人（＝ ブロック0を最初に作った人）だけがブロック0のデータを持ち、その人がネットワークにデータを流した跡が、P2Pの層に残る。最初のころのノードは、どれも、誰か特定のノードから最初のブロック0を受け取るので、どこから来たかの跡が残りうる。その跡から、実際のネットワークで、出どころを一つに特定できるかは、確かめてみないと分からない別の問題だが、ここではそこまで要らない。配った人、という考え方が生まれる、ということだけで十分である。機構Bでは、配った人という考え方が初めから生まれない。

5.3 ソースコードからはどちらとも言えないが、振る舞いの証拠は一方に傾く

サトシは仕組みBを選んだ。その選び方には、二つの読み方がある：

読み方A：作りやすさのため。自動で組み立てるのは、新しいノードが、ほかのノードがいなくても立ち上がれるようにするための、素直な作り方である。ブロック0が誰のものでもないのは、一番早く立ち上げることを優先した結果、たまたまそうなっただけ、ということになる。

読み方B：誰のものにもならない設計。ブロック0は、作った人がはっきり決まらないように組み立てられている（§4.3）。「わざと匿名にした」と言うより、このほうが正確である。身元を隠すことは、もともといる作った人の手がかりを隠すことだが、誰のものにもならない設計は、はっきり決まる作った人というものを、仕組みの段階から生まない。

ソースコードだけでは、読み方AとBを見分けられない。v0.1が実際にしていることは、技術の上では、どちらの読み方とも矛盾しない。ここまでは、どちらを取るかは読む人の判断になる。

しかし、まわりの記録も合わせて見ると、二つの読み方の重みは同じではない：

1. 別の設計のほうが、はっきり小さい。ハッシュだけを確かめ、ブロック0はほかのノードから受け取るやり方なら、もとからあるネットワークの処理を使い回せて、データベースが空のときの分かれ道も足さなくてすむ。作りやすさが本当の理由なら、小さい設計を選ぶほうが自然である。自動で組み立てるやり方は、もっと大きな作りで、小さい設計ならいらなかった手間を、わざわざ引き受けている
2. 知られている振る舞いと合う。匿名のメールアドレス、匿名でのドメインの登録、少しずつ身を引いたことは、どれも同じことを示している。身元の手がかりを残さない、ということである（層ごとの全体はサトシの匿名性アーキテクチャ分析にまとめてある）。その中でジェネシスブロックの設計だけを「作りやすさのため」と読み、ほかを「わざと」と読むのは、記録を同じ物差しで扱わない読み方になる。そんな読み方をするのは、ここだけである
3. コインベースのアドレスを、全員に共通の定数にしたこと。呼び出すたびに作っていれば、個人につながる手がかりが、もう一つ残っていた。ソースに共通の定数として書き込んだのは、「個人を特定する手がかりを残さない」という考えと合う
4. タイムズの見出しだけが、個人の色を帯びている。ナンス、アドレス、処理の作りは、どれも個人の色を消してある。個人の声が出ているのは、コインベースに入れた文の部分だけである。ほかをとことん個人の色のないものにしながら、一か所だけ例外を置いた設計は、たまたまそうなったと考えるより、わざとそうしたと考えるほうが、説明しやすい。なおChain Bulletinの2020年分析は同じ見出しを「英国紙＋英国式スペル慣習」として地理的証拠に読み替え、ロンドン在住仮説を支持する。同じ手がかりを、「意図」ではなく「地理」の手がかりとして読む見方である
5. §6と同じ物差し（オッカムの剃刀）で比べる。 §6では、50 BTCが使えないのは「見落とし」ではなく「最初の状態として扱った結果」だと論じる。「見落とし」とする見方には、余分な仮定が要り、「最初の状態」とする見方には要らないからである。同じ物差しをここにも当てると、読み方Bには余分な仮定が要らない。読み方Aでは、ほかの選び方がどれもわざとだったプロジェクトで、ここ一か所だけ、「特に理由もなく」、もっと大きく、欠かせないわけでもない作りが選ばれた、と考えなければならない

ソースコードの上では、AとBは五分五分である。記録の全体で見ると、Bのほうが、余分な仮定がいらない。このあとの節では、Bのほうがありそうな読み方として扱うが、事実ではなく、読み方であることは、はっきりさせ続ける。

AかBかとは別に、ソースコードそのものがはっきり示していることがある。ブロック0が誰のものでもないのは、ブロック0にもともと備わった性質ではなく、別に下された設計の判断の結果だ、ということである。同じように成り立つ別の作り方なら、配った人がいたはずである。もっと大きく、欠かせないわけでもない作りを、配った人のいない形で選んだのは、サトシである。

5.4 補足：PoWの余裕（ジェネシスブロックのハッシュが目標値をどれだけ下回るか）

ブロック0に見られる、欠かせないわけではない設計の選び方は、仕組みBだけではない。ジェネシスブロックのハッシュは、難易度1の目標値を、数の上で大きく下回っている。これは、もっと小さな、読み方に左右される話ではあるが、正確に書いておく意味がある。

3つの層が、それぞれ実際に何を確かめているかを並べる：

v0.1の合意では、ブロック0は、ハッシュが同じかどうかを確かめるだけで通る。理屈の上では、どんなハッシュでも、プロトコルとしては動いた。実際のジェネシスブロックのハッシュは、難易度1の境目を、余裕をもって満たしていて、数として意味のある差がある。この余裕を「わざと込めた設計のしるし」と読むかどうかは、§5.3の、配った人がいるかどうかの議論より、根拠の弱い話である：

• 読み方A：余裕は、慎重な作り方の結果と読める。ほかの人が、難易度1で普通のPoWの確かめをしたときに、境目すれすれで通るより、余裕を持って通るほうが安全だからである
• 読み方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と結びつける道が、どちらでも成り立つことを意味する（ターゲットベースでは「意図的な深さ」、ハーヴェスト・ベストでは「意図的な時間」）。その意味で、どちらの探し方だったかは決められないままでも、PoWの余裕は、意図して設計されたことを示す手がかりとして、少し強まる。

6 使えない50 BTC — 定数から立ち上げたことの結果

6.1 技術の上での振る舞い

ブロック0の報酬の50 BTCは、一度も動いておらず、動かすこともできない。v0.1でも今のBitcoin Coreでも、データベースが空の状態からジェネシスブロックを組み立てるとき、ブロック0はブロックのデータベースには書かれるが、コインベースの出力はUTXOセットには書かれない。今のchainparams.cppのコメントに、はっきりそう書いてある：「コインベーストランザクションの出力は使えない。もともとデータベースになかったからである」

Bitcoin Wikiは、「意図的に行われたか偶発的に行われたか不明」と控えめに書いている。ビットコインのほかのすべてのコインベースの出力は、ブロックとチェーンの設計のページにある、普通の決まり（100回承認されたあとで使える）に従う。その決まりの例外として今も残っているのは、ブロック0のコインベースだけである。

6.2 たまたまか、わざと最初の状態にしたのか

掘ることを中心にしたブロックの処理に生じた食い違いと見れば、この振る舞いは穴に見える。通常のブロック処理はProcessBlock → AcceptBlock → AddToBlockIndex → ConnectBlock → ConnectInputs → txdb.AddTxIndexと一本の連鎖で走る。ジェネシスの空DB分岐はblock.WriteToDiskとblock.AddToBlockIndexしか走らず、ConnectBlockを呼ばない。したがってAddTxIndexも呼ばれず、コインベースはトランザクションインデックスに入らない。

別の見方をすると、話が変わる。ブロック0は「最初に掘られたブロック」ではない。ネットワークの最初の状態であり、定数から立ち上げるために組み立てたものであって、ネットワークから届いた、掘ったという知らせではない。この見方では、これまで「見落としの証拠」とされてきた5つのことが、どれも、設計どおりの振る舞いになる：

今のCoreのコメントも、この見方で読み直せば、古い変わった振る舞いへの言い訳ではない。「もともとデータベースになかった」は、ありのままを書いたものである。ブロック0は、トランザクションとして起きたことが一度もないので、その出力も、トランザクションとして索引に入らない。

オッカムの剃刀は、最初の状態と見る読み方のほうを支える。たまたまとする見方では、めったにない場合の処理までおおむね丁寧に作られたソフトに、見落としが一か所だけあった、と考えなければならない。最初の状態と見る読み方では、何も仮定しなくてよい。見えている振る舞いは、どれも、ブロック0を何として扱うかという一つの選択から出てくる。

6.3 §4とのつながり（二つの「ない」）

§6.2の、最初の状態と見る読み方は、§4の、問いが成り立つかどうかの層の読み方と、じかにつながる。ブロック0を、定数から導く最初の状態として扱い、P2Pの層を通って届くブロックとは見なさない。この一つの設計の判断から、互いに矛盾しない二つの「ない」が、同時に生まれる：

Block 0 = 定数からの立ち上げ（わざとの設計、読み方 B）
  ├── 自動で組み立てる：ネットワークから見える出どころがない
  │     → チェーンの上で、作った人が一人に決まらない（§4 — 作った人がいない）
  └── 最初の状態で、トランザクションではない
        → コインベースの出力が UTXO セットに入らない（§6 — 受け取る人がいない）

ブロック0は、作る側でも受け取る側でも、仕組みの上で、誰のものでもない。暗号で特定できる作った人も、暗号で特定できる受け取る人もいない。読み方Bでは、これは二つの別々の偶然ではなく、筋の通った一つの設計のねらいから出てきた、二つの結果である。ブロック0は、作る側でも受け取る側でも、特定の誰かのものにならない形で、世に送り出されたのである。

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

ブロック0の後に1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNaに送られたトランザクション（2026年10月の時点で、約8万の出力で、合計約57.5 BTC。一部のエクスプローラーが示す「100 BTC超」は、ブロック0自身の50 BTCも数えている）は、最初の状態として除かれるものではなく、普通の出力である。秘密鍵を持っている人なら使える。これらも、一度も動いていない。秘密鍵が実際にあるとしても、それを誰も使っていないことを、弱いながら示している。

6.5 秘密鍵の持ち主 — 切り離して考えるべき別の問題

このページのほかの節とは別の問題である。ブロック0のコインベースの出力のアドレスの秘密鍵を、誰かが持っているのか？

混ざりやすいので、問題を分けておく：

鍵を誰が持っているかについて、技術の上で分かること：

• コインベースの出力の公開鍵は、コードに書き込まれた定数である。それに対応する秘密鍵は、必ずどこかにある（いつか誰かが作った）
• 誰が作ったか（サトシとみられる）は、状況証拠しかない
• 今、誰が持っているかは分からない。正しい署名が、実際に示されたことはない
• 50 BTCはUTXOセットに入っていない（§6.1）ので、鍵を持っていても、そのコインは動かせない。一方で、好きなメッセージに署名することは、技術の上ではできる。ただし、実際にしてみせた人はいない

のちにサトシのものとされた鍵との関係：ブロック0のコインベースのアドレスは、ソースコードに書き込まれた定数である。ブロック1から先の初期のブロックのコインベースのアドレスは、サトシのウォレットが、ブロックごとに新しい鍵の組を作ったものである。したがってブロック0の鍵は、Patoshiパターンの約110万BTCを持つ数千のアドレスには含まれない。ブロック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は、一人の、あるいは何人かの、特定の誰かのものとして、世に置かれたのではない。余分な仮定をしなくてすむのは、この見方である。