Gavin Andresen

Software pflegt sich nicht von selbst, wenn sich der Gründer eines Projekts zurückzieht. Jemand muss Fehlerkorrekturen, Tests und neue Veröffentlichungen koordinieren. Gavin Andresen übernahm diese Verantwortung in Bitcoins Anfangsjahren nach Satoshi. So beschreibt es auch das MIT-Profil zu einer Veranstaltung am 17. November 2015, das bereits Wladimir van der Laan als leitenden Betreuer nennt. Das ist eine Rolle in der Softwareentwicklung, kein Eigentum am Netzwerk. Eine historische Biografie belegt auch keinen heutigen Zugriff auf das Repository, den gemeinsamen Speicherort des Quellcodes. [1]

Ein Neuling kann digitales Geld verstehen, ohne selbst Münzen zum Empfangen und Versenden zu haben. Andresen begegnete dieser Hürde mit Bitcoin Faucet. Am 11. Juni 2010 kündigte er den Dienst mit einem Anfangsbestand von 1.100 BTC und fünf Münzen zum Ausprobieren an. Besucher mussten weder auf einen Mining-Erfolg warten noch einen Verkäufer suchen. Der Faucet verteilte vorhandene Mittel; er erzeugte keine neuen Bitcoin und keine Blockbelohnung. Er sollte den Einstieg erleichtern, nicht die Regeln der Geldschöpfung ändern. [2]

In einer Antwort vom 11. Juni 2010 präzisierte Andresen die Grenze: fünf Münzen je IP-Adresse, nicht täglich. Eine IP-Adresse kennzeichnet eine Verbindung im Computernetz. Sie ist weder eine Bitcoin-Wallet-Adresse noch eine verlässliche Liste einzelner Personen. Der Schutz des Dienstes war somit keine Identitätsprüfung. Ein CAPTCHA, eine Aufgabe zur Unterscheidung von Menschen und automatisierten Programmen, wurde damals als mögliche weitere Maßnahme diskutiert. Diesen Anfangszustand sollte man von späteren Änderungen trennen und nicht nach dem Bild heutiger Dienste umdeuten. [2]

Ein weiterer Beitrag löste ein anderes praktisches Problem. Ein Empfänger möchte vielleicht mehrere Unterschriften verlangen, bevor Geld ausgegeben werden darf. Muss der Sender dafür jedes Mal die vollständige Regel bearbeiten? BIP 16 aus dem Jahr 2012 beschreibt Pay to Script Hash: Die Zahlung verweist auf einen Hash, einen kurzen digitalen Fingerabdruck des Skripts mit den Bedingungen. Ein BIP ist ein nummerierter Verbesserungsvorschlag für Bitcoin. Das eigentliche Skript, hier redeemScript genannt, liefert erst die Person, die das Geld ausgibt. Die Bedingungen bleiben bestehen; geändert werden Zeitpunkt und Zuständigkeit ihrer Vorlage. [3]

Stellen Sie sich eine Kasse vor, die nur mit Zustimmung mehrerer Menschen geöffnet werden darf. Das Vorzeigen der Regeln gibt das Geld nicht frei. Ebenso verlangt BIP 16 aus dem Jahr 2012, den Hash des vorgelegten redeemScript zu prüfen und anschließend dessen Bedingungen auszuführen. Das Skript zu kennen ersetzt keine nötigen Signaturen. Hinzu kommt eine technische Grenze von 520 Byte für dieses eingefügte Skript; Byte ist eine Maßeinheit für Daten. Entscheidend sind zwei getrennte Prüfungen: Ist die richtige Regel vorgelegt, und ist vorhanden, was sie verlangt? [3]

Im Jahr 2015 legte Andresen BIP 101 vor, um die maximale Blockgröße schrittweise anzuheben. Das Dokument bezeichnet die Änderung als Hard Fork: Ältere Regeln würden bestimmte neu erlaubte Blöcke ablehnen. Das Register führt den Vorschlag als Closed, also abgeschlossen. BIP 16 steht dagegen auf Deployed, also eingesetzt. Eine BIP-Nummer oder ein bekannter Autor belegt somit keine Aktivierung. Beim Lesen eines Vorschlags muss man auch prüfen, ob seine Regeln tatsächlich übernommen wurden. [4] [3]

Warum war die Vergrößerung umstritten? Ein größerer Block kann mehr Transaktionen aufnehmen, aber seine Daten müssen versendet, empfangen und geprüft werden. BIP 101 aus dem Jahr 2015 behandelt deshalb auch Übertragungskosten und das Risiko, dass höhere Anforderungen große Betreiber begünstigen. Eine langsame Internetverbindung schafft andere Bedingungen als die Anbindung eines großen Mining-Unternehmens. Die Erwartungen des Autors an den technischen Fortschritt sind ein Argument für den Vorschlag, kein Messergebnis für jede künftige Lage. Es geht um das Verhältnis zwischen Kapazität und der Möglichkeit, das Netzwerk selbstständig zu überprüfen. [4]

Bitcoin.org erklärt, dass Entwickler Nutzern keine Regeländerung aufzwingen können: Menschen wählen die Software, die sie betreiben. Für das Zusammenspiel müssen ihre Regeln miteinander vereinbar bleiben. Andresen konnte Vorschläge und Code schreiben sowie andere überzeugen, aber Bitcoin nicht einseitig für alle umgestalten. Seine Arbeit lässt sich deshalb am besten anhand einzelner Beiträge beurteilen: Was ermöglichte ein Dienst, was tat der Code, und was übernahm das Netzwerk? Frühere Verdienste machen nicht automatisch jede spätere Aussage richtig. [5]