Jeff Garzik ist ein Entwickler, der unter dem Kontonamen jgarzik bekannt ist. Er arbeitete an Bitcoin-Software und an BIPs, Dokumenten für konkrete Änderungen oder Verfahren. Seine Beiträge veranschaulichen, wie sich Bitcoin weiterentwickelt: Jemand kann Code schreiben und eine Regel vorschlagen, aber nicht dem gesamten Netzwerk ihre Annahme befehlen.
Auf GitHub verwendet Jeff Garzik den Namen jgarzik. Seine Arbeit lässt sich in einzelnen Repositories nachvollziehen, öffentlichen Ablagen für Code und dessen Entwicklungsgeschichte. Das hilft mehr, als einer Person pauschal die Rolle zuzuschreiben, „Bitcoin zu steuern“. Bei einem Programm geht es darum, was es tut und welche Version vorliegt; bei einem Vorschlag darum, was er ändern sollte. Ein Entwicklerprofil bestimmt nicht von sich aus, welche Softwareversion andere Menschen ausführen. [1]
Die README, die Einführung zu Garziks cpuminer, beschreibt ihn als Bitcoin-Mining-Programm für die CPU, also den Prozessor des Computers. Mehrere Threads, also gleichzeitig ausführbare Programmabläufe, können sich die Rechenarbeit teilen. Das Projekt pooler/cpuminer für Litecoin und Bitcoin nennt diesen Ursprung ausdrücklich. Bestehenden Code zu übernehmen und eigenständig weiterzuentwickeln heißt, einen Fork des Projekts anzulegen. Dadurch spaltet sich nicht automatisch das Bitcoin-Netzwerk. Auch müssen Funktionen einer späteren Ableitung nicht bereits in Garziks Original enthalten gewesen sein. [2] [3]
Picocoin ist ein weiteres Beispiel. Es enthält libccoin, eine Bibliothek in der Programmiersprache C, deren Funktionen Entwickler für Bitcoin-Anwendungen nutzen können. Die README kennzeichnet die zugehörige HD-Wallet und den Knoten brd jedoch als WIP, also noch in Arbeit. Eine HD-Wallet leitet eine Familie von Schlüsseln aus einer gemeinsamen Grundlage ab; der Knoten soll mit dem Bitcoin-Netzwerk kommunizieren. Das Repository wurde am 15. Februar 2024 archiviert. Es ist eine nützliche historische Quelle, doch verfügbarer Code allein belegt kein fertiges, gepflegtes und sicheres Produkt für die eigenen Ersparnisse. [4]
Stellen wir uns einen Knoten vor, der wissen möchte, welche unbestätigten Transaktionen sein Gegenüber kennt. Garziks BIP 35 behandelt diese Aufgabe: Eine mempool-Nachricht fordert eine Liste an, die Antwort inv enthält Transaktionskennungen, ihre Hashes, und getdata kann anschließend die eigentlichen Daten anfordern. Ein Mempool ist ein örtlicher „Warteraum“ vor der Bestätigung, keine gemeinsame Liste der ganzen Welt. Auch getrawmempool in der Bitcoin-Core-Dokumentation liefert den Inhalt eines bestimmten Knotens. Eine dort gefundene Transaktion ist damit noch nicht in einem Block bestätigt. [5] [8]
Die Blockgröße betrifft sowohl den Platz für Transaktionen als auch den Aufwand für Übertragung und Prüfung. Garzik, Tom Harding und Dagur Valberg Johannsson schlugen in BIP 100 vor, die Grenze anhand von Stimmen anzupassen, die Miner in Blöcken festhalten. Alle 2016 Blöcke sollte neu gerechnet werden, mit 75% Unterstützung in den Blöcken und begrenzten Anpassungsschritten. Es ging also nicht um eine Abstimmung nach Personenzahl. Das Register führt den Vorschlag als Closed, also geschlossen; die Beschreibung beweist nicht, dass das gesamte Bitcoin-Netzwerk den Mechanismus übernommen hat. [6]
Betrachten wir einen gewöhnlichen Knoten, der weiterhin die ursprüngliche Grenze von 1 MB prüft. Er lehnt einen größeren Block ab, selbst wenn dessen Miner eine höhere Grenze unterstützt. Vor genau dieser Trennung warnt BIP 100. Eine Stimme im Block ist eine Information, die neue Software auswerten kann, kein Befehl zum Umschreiben eines alten Programms. Eine Änderung, die nach alten Regeln ungültige Blöcke zulässt, ist ein Hard Fork. Das bedeutet etwas anderes als die bloße Weiterentwicklung eines abgezweigten Projekts auf GitHub. [6]
Garziks BIP 102 schlug einen anderen Weg vor: die Grenze einmalig auf 2 MB zu erhöhen. Zur Aktivierung sollten zugleich eine Zeitbedingung und signalisierte Unterstützung in 95% der letzten 1000 Blöcke erfüllt sein. Das würde ältere prüfende Programme nicht automatisch anpassen; sie würden größere Blöcke weiterhin ablehnen. Auch dieser Vorschlag trägt den Status Closed. Er dokumentiert eine vorgeschlagene Änderung und erklärt nicht die heute geltenden Bitcoin-Regeln zur Blockgröße. [7]
Bei jedem BIP zählen Inhalt und Status. BIP 35 ist als Deployed, also eingeführt, in der Schicht Peer Services verzeichnet. Diese betrifft Dienste und Kommunikation zwischen Knoten. BIP 100 und BIP 102 stehen dagegen als Closed unter Consensus (hard fork), weil es darum geht, welche Blöcke Knoten als gültig anerkennen. Derselbe Autor kann in beiden Bereichen mit unterschiedlichen Ergebnissen arbeiten. Eine erfolgreich eingeführte Netzwerknachricht bedeutet nicht, dass auch alle seine vorgeschlagenen Regeländerungen eingeführt wurden. [5] [6] [7]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Cynthia Lummis, Mike Hearn, Blocksize War. Auf diesen Eintrag verweisen außerdem Mike Hearn.