Jeff Garzik は jgarzik というアカウント名で知られる開発者です。ビットコインのソフトウェアや、具体的な変更・手順を記した文書である BIP に取り組みました。その貢献はビットコインの発展の仕方を示しています。作者はコードを書いてルールを提案できますが、ネットワーク全体に採用を命令することはできません。
Jeff Garzik は GitHub で jgarzik という名前を使っています。個々のリポジトリ、つまりコードと変更履歴を公開する場所から、その仕事をたどれます。誰か一人に「ビットコインを動かしている人」という曖昧な役割を与えるよりも、具体的な理解につながります。プログラムなら何をするものか、どの版なのか、提案なら何を変えようとしたのかが大切です。開発者のプロフィールだけで、ほかの人が使うソフトウェアの版が決まるわけではありません。 [1]
Garzik の cpuminer の紹介文書 README は、これを CPU、つまりコンピューターのプロセッサーでビットコインを採掘するプログラムと説明しています。マルチスレッド対応により、同時に動く複数の処理の流れへ計算を分けられます。Litecoin と Bitcoin 向けの pooler/cpuminer は、このプログラムから派生したことを明記しています。既存のコードを引き継いで別に開発することを、プロジェクトの fork と呼びます。それだけでビットコインのネットワークが分裂するわけではなく、後から加わった機能が原版にもあったとは限りません。 [2] [3]
別の例が Picocoin です。C 言語のライブラリ libccoin が含まれ、その機能をビットコインアプリの開発に利用できます。ただし README は、関連する HD ウォレットと brd ノードを WIP、つまり開発途中としています。HD ウォレットは共通の出発点から一連の鍵を導出し、ノードはビットコインネットワークとの通信を担います。リポジトリは 2024 年 2 月 15 日にアーカイブされました。歴史を学ぶ資料にはなりますが、コードの公開だけでは、完成し、保守され、自分の貯蓄を預けられる安全な製品だとは判断できません。 [4]
あるノードが、接続先の知っている未承認取引を調べたいとします。Garzik の BIP 35 はそのための仕組みです。mempool メッセージで一覧を求め、inv 応答で取引の識別子であるハッシュを受け取り、getdata で取引データ自体を要求できます。Mempool は承認前の取引が入る各ノードの「待合室」であり、世界共通の一つの一覧ではありません。Bitcoin Core の文書にある getrawmempool コマンドも、特定のノードの内容を返します。そこで取引が見つかっても、ブロックに承認済みという意味にはなりません。 [5] [8]
ブロックサイズは取引を入れられる量と、送信や検証に必要な資源に関わります。Garzik、Tom Harding、Dagur Valberg Johannsson は BIP 100 で、マイナーがブロックに記す投票に応じて上限を調整することを提案しました。2016 ブロックごとに再計算し、ブロック内で 75% の支持を求め、各回の変更幅も制限する仕組みです。人数で数える投票ではありません。登録表の状態は Closed、つまり終了であり、文書の説明だけではネットワーク全体の採用を証明できません。 [6]
当初の 1 MB 上限を今も確認している普通のノードを考えてください。それより大きいブロックが届けば、採掘したマイナーが上限引き上げを支持していても、そのノードは拒否します。BIP 100 はまさにこの分裂を警告しています。ブロック内の投票は新しいソフトが解釈するデータであって、古いプログラムを書き換える命令ではありません。旧ルールが拒否するブロックを許可する変更は Hard Fork です。この fork は GitHub で単に派生プロジェクトを作ることとは別の意味です。 [6]
Garzik の BIP 102 は別の方法を提案しました。上限を一度だけ 2 MB に引き上げるものです。有効化には、定められた時刻の条件と、直近 1000 ブロック中 95% の支持表明の両方が必要でした。それを満たしても古い検証プログラムが自動で更新されるわけではなく、大きいブロックを拒否し続けます。この提案も Closed です。提案された変更の記録であり、今日のビットコインのブロックサイズのルールを判断するための説明ではありません。 [7]
BIP は内容と状態を併せて読むことが大切です。BIP 35 は、ノード間のサービスや通信を扱う Peer Services の層で Deployed、導入済みとされています。BIP 100 と BIP 102 は、どのブロックを有効と認めるかに関わるため、Consensus (hard fork) の層で Closed とされています。同じ作者が両分野に取り組んでも、結果は異なり得ます。ネットワークメッセージの導入成功は、その作者のルール変更案がすべて採用されたことを意味しません。 [5] [6] [7]
理解を深めるには、この項目とあわせて次もお読みください Cynthia Lummis, Mike Hearn, ブロックサイズ戦争. 次の項目からも参照されています Mike Hearn.