Wer kontrolliert die Entwicklung von Bitcoin? Was ist, wenn jemand beschließt, seine Regeln stillschweigend zu ändern? Wie stellt man sicher, dass niemand Bitcoin kaputt macht?
Immer wieder stellt sich die Frage, wer den Code im Bitcoin Core Repository auf GitHub kontrolliert. Dieses Argument wird oft als Beweis für einen zentralen Kontrollpunkt über das Bitcoin-Protokoll angeführt. Ich bin davon überzeugt, dass die Frage selbst irreführend ist, da sie die unmittelbar bevorstehende Existenz autoritärer Macht impliziert und dieses Modell nicht auf Bitcoin anwendbar ist. Für den Durchschnittsmenschen ist es natürlich nicht offensichtlich, warum das so ist; Daher besteht der Zweck dieses Artikels darin, zu erklären, wie Bitcoin Core funktioniert und auf einer höheren Ebene, wie sich das Bitcoin-Protokoll selbst weiterentwickelt.
Geschichte von Bitcoin Core
Bitcoin Core ist der Hauptort für die Entwicklung des Bitcoin-Protokolls und kein Verwaltungs- und Kontrollorgan. Wenn es aus irgendeinem Grund aufhört zu existieren, wird ein neues entstehen. Die Wahl einer bestimmten Plattform (derzeit ein Repository auf Github) ist eher eine Frage der Bequemlichkeit als der Definition oder Authentizität des Projekts. Tatsächlich haben wir bereits mehr als einmal gesehen, wie sich die Bitcoin-Entwicklung von Plattform zu Plattform verlagerte und sogar ihren Namen änderte.
Anfang 2009 war der Quellcode von Bitcoin eine einfache .rar-Datei, die auf SourceForge gehostet wurde. Die ersten Entwickler tauschten Patches einfach per E-Mail mit Satoshi aus.
Am 30. Oktober 2009 erstellte Sirius (Marty Malmi) auf SourceForge ein Repository für die Bitcoin-Entwicklung
Im Jahr 2011 wechselte das Projekt von SourceForge zu GitHub
Im Jahr 2014 wurde das Projekt in Bitcoin Core umbenannt.
Vertraue niemandem
Obwohl einige Entwickler im Github-Repository den Status „Mantainer“ haben und befugt sind, Code zum Hauptzweig hinzuzufügen, ist es wahrscheinlicher, dass sie das Repository verwalten, anstatt es zu kontrollieren.
Wenn jemand Code zum Master-Zweig hinzufügen könnte, würde das Projekt schnell im Chaos versinken. Bitcoin Core folgt den Grundsätzen der geringsten Privilegien: Jede einem Einzelnen gewährte Macht kann bei Missbrauch leicht widerrufen werden.
Core veröffentlicht öffentlich eine wichtige Liste mit PGP-Schlüsseln, die zum Signieren von Merge-Commits verwendet werden können. Aber die Moral ist eher, dass man Github nicht trauen kann! Selbst das Bitcoin Core-Team kennt nicht alle Personen, die Änderungen am Repository vornehmen können – unter den Github-Mitarbeitern dürften sich ein Dutzend davon befinden.
Aus Sicherheitsgründen ist Github nicht vertrauenswürdig. Jeder GitHub-Mitarbeiter kann seine offizielle Position ausnutzen und ohne Wissen der Verantwortlichen Code in das Repository einfügen. Es ist jedoch unwahrscheinlich, dass ein solcher Angreifer auch an den PGP-Schlüssel eines diensthabenden Bitcoin Core-Entwicklers gelangen könnte.
Bitcoin Core reduziert die Frage der Codezuverlässigkeit nicht auf die Sicherheit von GitHub-Konten, sondern verwendet ein kontinuierliches Integrationssystem, das die PGP-Schlüssel vertrauenswürdiger Personen überprüft, die jede Codezusammenführung signieren müssen.
Merge-Commit – Zusammenführen von neuem Code mit dem, was sich bereits im Repository befindet
Obwohl jeder weiß, wem diese Schlüssel gehören, ist es dennoch unsicher, davon auszugehen, dass dies immer der Fall sein wird – der Schlüssel kann gestohlen werden, und wir werden nicht in der Lage sein, etwas darüber herauszufinden, bis sein Besitzer andere diensthabende Personen benachrichtigt. Code-Merging-Keys garantieren daher auch keinen perfekten Schutz; Sie erschweren es einem Angreifer lediglich, beliebigen Code hinzuzufügen.
Schlüssel zum Königreich
Zum Zeitpunkt des Verfassens dieses Artikels sind die vertrauenswürdigen PGP-Fingerabdrücke:
71A3B16735405025D447E8F274810B012346C9A6
133EAC179436F14A5CF1B794860FEB804E669320
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D
Diese Schlüssel gehören den folgenden Entwicklern:
Vladimir van der Laan [email protected]_
Pieter Wuille [email protected]
Jonas Schnelli [email protected]
Marco Falke [email protected]
Samuel Dobson [email protected]
Bedeutet das, dass wir diesen fünf Mitgliedern des Bitcoin Core-Teams vertrauen? Nicht wirklich. Schlüssel sind kein Identitätsnachweis – theoretisch könnten sie in die Hände anderer Personen gelangen. Was können Sie wirklich überprüfen, indem Sie das Skript „Verify-Commits“ in Python ausführen? Das Skript „Verify-Commits“ ist eine Code-Authentifizierungsprüfung, die jeder Entwickler ausführen kann.
Bei der Ausführung überprüft das Skript die PGP-Signatur bei jeder Codezusammenführung, beginnend mit der Nummer 82bcf405… im Dezember 2015 – insgesamt mehr als 3400 Zusammenführungen zum Zeitpunkt des Schreibens dieses Artikels. Wenn das Skript erfolgreich abgeschlossen wird, bedeutet dies, dass jede Codezeile, die seitdem hinzugefügt oder geändert wurde, den Bitcoin Core-Entwicklungsprozess durchlaufen hat und von einem der Inhaber des zugehörigen Schlüssels signiert wurde. Obwohl dies keine schlüssige Garantie dafür bietet, dass niemand Schadcode eingeben kann (die diensthabende Person könnte dem Projekt Schaden zufügen oder ihre Schlüssel könnten gestohlen werden), reduziert es die Wahrscheinlichkeit eines Angriffs erheblich. Wer sind eigentlich die Betreuer und wie sind sie zu ihren Rollen gekommen? Wir werden etwas später darüber sprechen.
Mehrstufige Sicherheit
Die Integrität des Bitcoin Core-Codes sollte nicht nur von einigen wenigen kryptografischen Schlüsseln abhängen, daher gibt es viele andere Prüfungen. Um einen ernsthaften Schutz zu gewährleisten, wurden viele Sicherheitsstufen geschaffen:
Sicherheit für Pull-Requests
Pull-Request – eine Anfrage zum Zusammenführen von neuem Code mit dem, was sich bereits im Repository befindet
Absolut jeder kann frei Änderungen vorschlagen, die den Projektcode verbessern, indem er seinen Pull-Request im Bitcoin/Bitcoin-Repository öffnet.
Entwickler überprüfen Pull-Requests, um sicherzustellen, dass sie nicht böswillig sind. Jeder kann Pull-Requests frei einsehen und seine Meinung dazu äußern – es gibt keine Prüfungs- oder Prüfungsanforderungen für die Teilnahme an Bitcoin Core. Wenn eine Pull-Request bis zu dem Punkt überlebt, an dem es keinen vernünftigen Grund mehr gibt, sie nicht zum Hauptzweig hinzuzufügen, führt der Verwalter eine Zusammenführung durch.
Die diensthabenden Bitcoin Core-Entwickler haben ein Skript installiert, das verhindert, dass Code-Merges versehentlich im Repository ausgeführt werden, wenn sie noch nicht signiert wurden.
Manchmal werden solche Fusionen mithilfe von OpenTimestamps datiert.
Das Travis Continuous Integration-System führt regelmäßig ein Skript aus, um die Authentizität des Entwicklungsverlaufs und die Signaturen aller Upstream-Merges zu überprüfen: Sie müssen einem der vertrauenswürdigen PGP-Schlüssel entsprechen.
Jeder kann ein Skript ausführen, um die PGP-Signaturen aller Zusammenführungen nach Dezember 2015 zu überprüfen.
Freigabesicherheit
Von Zeit zu Zeit führen mehrere Entwickler unabhängig voneinander reproduzierbare Gitian-Build-Systeme aus, um sicherzustellen, dass es sich bei der Ausgabe um identische ausführbare Dateien handelt. Wenn es jemandem gelingt, einen Build zu erstellen, der nicht mit den Builds anderer Entwickler übereinstimmt, ist dies ein Zeichen dafür, dass darin eine nicht reproduzierbare Komponente festgestellt wurde – dann verzögert sich die Veröffentlichung. In diesem Fall ermitteln die Entwickler die Ursache der Diskrepanz, beheben sie und stellen dann einen anderen Release Candidate zusammen. Sobald ein deterministischer Build erfolgreich abgeschlossen wurde, signieren Entwickler das Ergebnis und stellen so sicher, dass die resultierenden ausführbaren Dateien und die zu ihrer Erstellung verwendeten Tools sauber sind und aus derselben Quelle erstellt wurden. Mit dieser Methode können Sie den Prozess der Erstellung und Verteilung ausführbarer Dateien sichern. Jeder Benutzer mit den entsprechenden Fähigkeiten kann sein eigenes Build-System ausführen.
Sobald Gitian-Builds erfolgreich abgeschlossen und von den Assemblern signiert wurden, signiert einer der Bitcoin Core-Betreuer eine Nachricht mit dem sha256-Hash jedes Builds mit seinem PGP-Schlüssel. Wenn Sie vorgefertigte ausführbare Dateien ausführen möchten, können Sie sich nach dem Herunterladen deren Hash ansehen und dann prüfen, ob dieser Hash in der von den Mitarbeitern signierten Nachricht enthalten ist. Eine Anleitung hierzu finden Sie hier.
Der Code für alle oben genannten Aktionen ist offen und für jedermann zugänglich – jeder mit ausreichenden Fähigkeiten und Lust kann ihn persönlich überprüfen.
Nachdem alle oben genannten Qualitäts- und Authentizitätsprüfungen bestanden wurden, landet der Code in Bitcoin Core und wird schließlich veröffentlicht, aber niemand zwingt ihn auf Bitcoin-Knoten. Jeder Bitcoin-Knotenbetreiber trifft eine bewusste Entscheidung, seinen installierten Code zu aktualisieren.
Es ist kein Zufall, dass Bitcoin Core nicht über eine automatische Aktualisierungsfunktion verfügt, da diese möglicherweise dazu verwendet werden könnte, Benutzer zu Codes zu zwingen, denen sie nicht zugestimmt haben.
Trotz aller in Bitcoin Core eingesetzten technischen Sicherheitsmaßnahmen ist keine davon perfekt und jede davon kann theoretisch gehackt werden. Die letzte Verteidigungslinie für Bitcoin Core-Code ist dieselbe wie für jedes andere Open-Source-Projekt: ständige Wachsamkeit. Je mehr Augen auf den Bitcoin Core-Code gerichtet sind, desto unwahrscheinlicher ist es, dass bösartiger oder anfälliger Code veröffentlicht wird.
Kostenloser Wettbewerb
BitMEX hat einen hervorragenden Artikel über das Bitcoin-Software-Ökosystem geschrieben. Es gibt mehr als ein Dutzend verschiedene Implementierungen, die mit dem Bitcoin-Netzwerk kompatibel sind, und noch mehr Implementierungen „konkurrierender“ Netzwerke. Das ist die Freiheit, die Open-Source-Software bietet: Jeder, der mit dem Bitcoin Core-Projekt unzufrieden ist, kann ein eigenes starten. Dies kann entweder durch einen Neuanfang oder durch eine Abspaltung der Kernsoftware erfolgen.
Zum Zeitpunkt des Verfassens dieses Artikels laufen auf 96 % der verfügbaren Bitcoin-Knoten eine Version von Bitcoin Core. Aber warum? Wie kann Bitcoin Core ein Netzwerk dominieren, in dem jeder jede andere Software nutzen kann? Schließlich sind die RPC-APIs anderer Softwareimplementierungen mit Bitcoin Core kompatibel oder diesem zumindest sehr ähnlich.
Ich glaube, der Grund dafür ist, dass sich die gesamte Entwicklung auf Bitcoin Core konzentriert. Es wurde unvergleichlich mehr Zeit und Talent investiert als in jedes andere Projekt – was bedeutet, dass der Bitcoin Core-Code der effizienteste, zuverlässigste und sicherste ist. Knotenbetreiber möchten die bestmögliche Software ausführen, insbesondere wenn es um den Umgang mit Geld geht. Es gibt noch eine andere Erklärung: Das Erreichen eines Konsenses mit anderen Knoten ist eine kritische Aufgabe für solche Software. Gleichzeitig verfügt das Bitcoin-Protokoll jedoch über keine formale Spezifikation (da niemand das Recht hat, eine solche zu schreiben), sodass dies am sichersten ist Verwenden Sie den Code der gängigsten Softwareimplementierung, da diese die größte Chance auf Kompatibilität mit dem Rest des Netzwerks hat. In diesem Sinne erhält der Code die meiste Aufmerksamkeit, der einer Spezifikation am nächsten kommt.
Wer sind die Core-Entwickler?
Für Leute, die mit der Beteiligung an der Entwicklung von Bitcoin Core nicht vertraut sind, mag es von außen scheinen, dass Core eine Art homogene Organisation ist. Das stimmt überhaupt nicht! Die Hauptautoren streiten oft miteinander, und selbst die fleißigsten von ihnen haben eine Menge Code geschrieben, der es nie zur Veröffentlichung geschafft hat. Wenn Sie die Richtlinien und Regeln für die Teilnehmer lesen, werden Sie feststellen, dass diese recht vage sind – der Prozess lässt sich am besten als „grober Konsens“ beschreiben.
Die Verantwortlichen bewerten, ob der Patch den allgemeinen Grundsätzen des Projekts entspricht; erfüllt Mindestqualitätsstandards; und berücksichtigen Sie die allgemeine Meinung anderer Teilnehmer.
Wer sind die Teilnehmer von Bitcoin Core? Hierbei handelt es sich um Teilnehmer, die durch ihren Beitrag zum Projekt über einen langen Zeitraum hinweg ausreichend Sozialkapital angesammelt haben. Wenn diensthabende Mitarbeiter einen kompetenten Mitwirkenden bemerken, der seine Zuverlässigkeit und Motivation in einem bestimmten Bereich unter Beweis gestellt hat, können sie beschließen, seinem Konto erweiterte Rechte auf Github zu gewähren. Der Chief Duty Officer wiederum überwacht alle Aspekte des Projekts und ist für die Koordinierung der Veröffentlichungen verantwortlich. Diese Rolle wurde von folgenden Personen freiwillig einander übertragen:
Satoshi Nakamoto: 03.01.09 – 23.02.11
Gavin Andresen: 23.02.11 – 07.04.14
Vladimir van der Laan: 07.04.14 – heute
Die Aufgabe eines Entwicklers auf Abruf ist eher die Wartung des Repositorys als die Autorität darüber, da der Entwickler auf Abruf eigentlich nicht das Recht hat, Entscheidungen zu treffen, die der allgemeinen Meinung der Teilnehmer oder Benutzer widersprechen. Es ist jedoch eine ziemlich herausfordernde und ermüdende Rolle; Dies ist größtenteils auf die zusätzliche Aufmerksamkeit des Ökosystems als Ganzes zurückzuführen. Beispielsweise hat Gregory Maxwell 2017 aus persönlichen Gründen seine Position als Dienstoffizier aufgegeben; höchstwahrscheinlich aufgrund des öffentlichen Drucks, der während der Bitcoin-Skalierungskontroverse auf ihn ausgeübt wurde. Vladimir van der Laan hat einen nachdenklichen Beitrag über die Herausforderungen als Kern-Bereitschaftsarbeiter geschrieben und darüber, warum so viele Menschen verärgert sind
Ihre Entscheidung, Gavin Andresens Konto der Verwaltungsprivilegien zu entziehen, war richtig.
Das Gleiche machten sie mit Jeff Garzik, indem sie ihn aus dem GitHub-Repository entfernten – was ihn und viele andere verärgerte –, aber zu diesem Zeitpunkt hatte er bereits seit zwei Jahren nicht mehr an dem Projekt teilgenommen. Die Gewährung von Administratorrechten an sein Konto stellte eine potenzielle Bedrohung für die Sicherheit des Projekts dar und verstieß gegen das Prinzip der geringsten Privilegien, auf das sich Vladimir in seinem Beitrag bezieht.
Wenn man Core von außen betrachtet, scheint es, dass es sich um eine geschlossene, von Technokraten geschaffene Welt handelt, in die ein Neuling nur äußerst schwer hineinkommt. Aber wenn man mit den Teilnehmern spricht, wird man verstehen, dass dem nicht so ist. Obwohl im Laufe der Jahre nur ein Dutzend Personen Zugriff hatten, um den Code zu ändern, haben Hunderte von Entwicklern zu dem Projekt beigetragen – mich eingeschlossen. Obwohl ich mich nicht als Bitcoin Core-Entwickler betrachte, bin ich technisch gesehen einer. Niemand kann Sie davon abhalten, Ihren Beitrag zu leisten!
Im Jahr 2011, als ich noch ein High-School-Schüler war, der nicht verstand, was ein Pointer ist, hat die @bitcoincoreorg-Entwickler-Community (insbesondere Leute wie Greg Maxwell, @pwuille usw.) mit mir zusammengearbeitet, um meine beschissenen Patches lohnenswert zu machen und sie zu einem großartigen Ergebnis zu machen Umgebung zum Lernen.
– Matt Corallo (@TheBlueMatt) 18. November 2018
Im Jahr 2016 organisierte @TheBlueMatt eine Residenz bei @ChaincodeLabs. Ich hatte alles über Bitcoin gelesen, was ich in die Finger bekommen konnte, hatte mich aber nicht getraut, eine PR einzureichen. Matt, Alex und Suhas haben sich außerordentlich großzügig die Zeit genommen, uns etwas über Bitcoin und die Art und Weise, wie man einen Beitrag leisten kann, beizubringen.
– John Newbery (@jfnewbery) 18. November 2018
Als ich anfing, meinen bescheidenen Beitrag zu @bitcoincoreorg zu leisten, freute ich mich, dass @MarcoFalke @pwuille @orionwl @LukeDashjr und @jfnewbery an der Diskussion meiner Pull-Anfragen beteiligt waren. So ein freundliches Projekt!
– Jeff Rade (@jeffrade) 19. November 2018
Für die Menschen scheint es äußerst schwierig zu sein, zu verstehen, dass die Bitcoin-Entwicklung nicht von der Struktur des Bitcoin Core-Repositorys auf Github abhängt. Obwohl Bitcoin Core eine gewisse Struktur aufweist (zentrale Kommunikationskanäle werden zur Koordination verwendet), wird das Projekt selbst von keinem der Teilnehmer kontrolliert – auch nicht von denen, die über besondere Privilegien im Github-Repository verfügen. Während die Verantwortlichen technisch gesehen das Repository beschlagnahmen, abweichende Entwickler zensieren und vielleicht sogar den Namen „Bitcoin Core“ beibehalten könnten, würde dies nur bedeuten, dass die Entwicklung des Projekts von Bitcoin Core an einen anderen Ort verlagert würde. Wenn Entwickler mit den Aktionen der diensthabenden Personen nicht mehr einverstanden sind, kopieren sie einfach den Code und verschieben ihre Arbeit in ein anderes Repository, in dem die bisherigen diensthabenden Bitcoin Core-Personen keine Administratorrechte haben.
Selbst wenn ohne die Machtergreifung einige zweifelhafte Änderungen in den Bitcoin-Core-Code gelangt wären, hätte es Entwickler gegeben, die einen Klon des Repositorys erstellt, den umstrittenen Punkt aus dem Code entfernt und diese Version für jedermann verfügbar gemacht hätten. Dies ist im Wesentlichen das, was Amaury Sachet getan hat, als er Bitcoin Core gespalten und Segregated Witness aus dem Code entfernt hat, um Bitcoin ABC zu erstellen. Es gibt auch Fälle, in denen Core Änderungen ablehnt, die einige Leute wünschen. In diesem Fall können Entwickler das Repository forken und diese Änderungen hinzufügen. Das ist oft passiert, zum Beispiel:
Mike Hearn hat Core geforkt und Bitcoin XT erstellt
Andrew Stone hat Core gespalten und Bitcoin Unlimited geschaffen
Jeff Garzik hat Core geforkt und BTC1 erstellt
Das Forken des Codes ist sehr einfach. Es ist schwierig, den Fokus der Bitcoin-Entwicklung zu verlagern: Man muss die Teilnehmer davon überzeugen, dass es für sie besser wäre, an einem anderen Projekt teilzunehmen.
Ich bin keinem Menschen und keinem Entwicklerteam bei Bitcoin treu. Meine Absicht ist es, den Kodex auszuführen, der meiner Meinung nach meine finanzielle Souveränität am besten schützt.
– Jameson Lopp (@lopp) 18. März 2017
Ich schwöre niemandem, keinem Entwicklungsteam Treue. Mein Ziel ist es, den Code auszuführen, von dem ich glaube, dass er meine finanzielle Souveränität am besten schützt._
Manche Leute sind der Meinung – und es ist schwer, sie davon zu überzeugen –, dass Bitcoin Core-Benutzer jeglichen Codeänderungen folgen, ohne hinzusehen. Dies kann zu einer sich selbst verstärkenden Überzeugung werden: Da Benutzer nicht am Entwicklungsprozess beteiligt sind, sind sie sich ihrer Fähigkeiten nicht bewusst und geben so einen Teil ihrer Macht an Entwickler ab. Allerdings zeigten die Benutzer ihre wahre Macht während der UASF-Bewegung (User Activated Soft Fork – vom Benutzer aktivierter Fork/Gabelung im Codeverlauf) im Jahr 2017. Ein unbekannter Entwickler veröffentlichte unter dem Pseudonym shaolinfry BIP148, das Miner zwingen würde, die Segregated Witness-Funktion um den 1. August herum zu aktivieren.
BIP oder Bitcoin Improvement Proposal – ein Vorschlag zur Verbesserung von Bitcoin
Allerdings erwies sich BIP148 als zu kontrovers und wurde nicht in Bitcoin Core aufgenommen, weshalb Shaolinfry Core abspaltete und seine Version unter dem Namen Bitcoin UASF veröffentlichte. Diese Softwareimplementierung erlangte unerwartete Popularität und erzeugte wahrscheinlich genug Druck, um Miner davon zu überzeugen, BIP91 zu akzeptieren und damit den Fork zu aktivieren, bevor BIP148 ablief.
Die besten Bitcoin Core-Teilnehmer sind meiner Meinung nach diejenigen, die sich an das Prinzip des „extremen Eigentums“ halten. Ein typisches Beispiel: Obwohl John Newbery nicht der Autor des Codes war, der den Konsensfehler enthielt, übernahm er dennoch die Verantwortung für dessen Aufnahme in die Veröffentlichung – da er ihn bei der Überprüfung nicht finden konnte – und dafür, dass er den Fehler später nicht finden konnte. als ich verschiedene Testmöglichkeiten verordnete:
Ich bin für den Fehler CVE-2018-17144 verantwortlich. https://t.co/BrPVivM296
– John Newbery (@jfnewbery) 24. September 2018
Wir sind alle Satoshi.
Teilnahme an Bitcoin Core
Der Einstieg in Core mag entmutigend erscheinen, aber es gibt online zahlreiche Ressourcen, die neuen Entwicklern helfen. Richtlinien und Regeln für Teilnehmer finden Sie hier. Vielleicht ist es jedoch besser, mit einer sanften Einführung von Jimmy Song zu beginnen.
Der Core-Entwickler Eric Lombroso hat außerdem einen Artikel darüber geschrieben, wie Änderungen im Core-Repository auftreten.
Alex B. hat einen hervorragenden Artikel über die Designphilosophie von Bitcoin geschrieben. Ich rate jedem, der sich ernsthaft an dem Projekt beteiligen möchte, es zu lesen.
Ich denke, es wäre nützlich, ein konkretes Beispiel zu nennen: Während ich diesen Artikel schrieb, stieß ich auf Schwierigkeiten, als ich versuchte, das Skript „verify-commits.py“ auf meinem Computer auszuführen, um die Integrität des Zusammenführungsverlaufs auf Github zu überprüfen. Um zukünftige Entwickler vor ähnlichen Problemen zu bewahren, habe ich einen Pull-Request geöffnet, in dem ich einige Verbesserungen an der Dokumentation vorschlug. Wie Sie dem Pull-Request-Verlauf entnehmen können, haben vier verschiedene Entwickler ihre Ideen zur Verbesserung meiner Anfrage geäußert. Die Vorschläge reichten von der Änderung des Wiki-Markups bis zur Einführung eines neuen Parameters, der im Skript „verify-commits.py“ verwendet werden könnte. Ich stimmte allen Vorschlägen zu, also habe ich sie in meinen Code aufgenommen und die Pull-Anfrage aktualisiert. Danach entschieden die Entwickler, die den Code überprüften, dass der Pull-Request alle Anforderungen erfüllte, und der diensthabende Mitarbeiter Marco Falke fügte ein Tag hinzu, das darauf hinwies, dass der Code in der Version 0.18 enthalten sein würde. Einige Tage später fügte der diensthabende Beamte Samuel Dobson den Code zu Core hinzu, ohne dass andere Entwickler Widerstand leisteten.
Wer kontrolliert Bitcoin?
Wie ich im Laufe der Jahre schon oft gesagt habe, ist es fast unmöglich, Bitcoin als System vollständig zu verstehen. Das Definieren des Bitcoin-Protokolls ist wie das Definieren einer Sprache. Sprachen entwickeln sich organisch: Wörter erhalten ihre Bedeutung im Laufe der Zeit selbst, anstatt sie aus Wörterbüchern zu entnehmen. So wie Wörterbücher eine Sprache beschreiben, anstatt sie zu definieren, beschreiben Softwareimplementierungen von Bitcoin die Bitcoin-Sprache mithilfe von Code. Niemand ist verpflichtet, der Definition eines bestimmten Wortes im Wörterbuch zuzustimmen, genauso wie niemand verpflichtet ist, dem Code in einer bestimmten Bitcoin-Softwareimplementierung zuzustimmen, indem er diese ausführt.
Sprachen werden nicht von der Demokratie regiert, und Bitcoin regiert sie auch nicht. Trotzdem hört man immer wieder, dass Leute über etwas „abstimmen“ können, aber in Wirklichkeit gibt es keinen Mechanismus, der die Minderheit dazu zwingen würde, die Änderungen zu akzeptieren, für die die Mehrheit gestimmt hat. Bitcoin ist Anarchie: ohne Herrscher, aber nicht ohne Regeln. Regeln werden von einzelnen Teilnehmern im Netzwerk definiert und durchgesetzt.
Obwohl Änderungen am Bitcoin-Protokoll selbst normalerweise durch sogenannte Bitcoin Improvement Proposals vorgenommen werden, ist auch dies nur eine empfohlene und gängigste Praxis, und niemand wird gezwungen, sie zu befolgen. Dabei handelt es sich lediglich um eine formellere Möglichkeit, die von den Teilnehmern vorgeschlagenen Änderungen zu prüfen: Sie werden zunächst einem Peer-Review unterzogen und müssen dann die Zustimmung aller einholen.
So schwierig es auch sein mag, dies zu erklären oder zu verstehen, ist dies ein wichtiger Aspekt der „Antifragilität“ von Bitcoin: Wenn es einen einzigen Kontrollpunkt gäbe, wäre dies die größte Schwachstelle, die von den Strukturen, die Bitcoin bedroht, angegriffen werden könnte. Letztendlich ist jeder Knotenbetreiber sein eigener Chef in dem Sinne, dass er persönlich dafür sorgt, dass niemand im Netzwerk gegen die Regeln verstößt, die er für wahr hält. Dieses Sicherheitsmodell ist die Grundlage für die Bitcoin-Governance, die von unten nach oben aufgebaut ist.
Niemand kontrolliert Bitcoin.
Niemand kontrolliert die Entwicklung von Bitcoin.
Quellen: 21ideas.org, blog.lopp.net