Bitcoin Magazin
Open Source vs. Source-Available: Was der Coldcard-Ausfall über Bitcoin-Softwareanreize lehrt
Geschlossener versus Open Source-Code hat die Bitcoin- und die breitere Krypto-Industrie seit über einem Jahrzehnt gespalten. Bitcoin-Befürworter argumentieren seit langem, dass die finanzielle Infrastruktur der Welt öffentlich aufgebaut werden sollte. Transparenz und Überprüfbarkeit sind, so sagen sie, nicht verhandelbar, wenn echtes Geld auf dem Spiel steht. Doch die App- und Legacy-Schichten der Finanzen sind oft anderer Meinung.
Doch der kürzliche Coldcard-Hack, eine beliebte Hardware-Wallet zur Selbstverwahrung, bei dem Nutzer über 100 Millionen Dollar in Bitcoin (mehr als 1.500 BTC) verloren haben, wirft Zweifel darauf auf, was "Open Source" tatsächlich bedeutet. Es offenbarte, dass vielleicht die meisten Menschen, selbst viele Hardcore-Bitcoiner, schlecht über die Philosophie der Open Source-Softwareentwicklung informiert sind und wann sie scheitert.
Die Prinzipien und Terminologie
Die Sprache rund um Open Source kann kompliziert sein. Freie und Open Source-Software (FOSS) und Freie/Libre und Open Source-Software (FLOSS) beziehen sich auf Software, die formalen Definitionen von Benutzerfreiheit entspricht.
Die Free Software Foundation (FSF) definiert freie Software durch vier wesentliche Freiheiten:
- Freiheit 0: Die Freiheit, das Programm nach Belieben für jeden Zweck auszuführen.
- Freiheit 1: Die Freiheit, zu studieren, wie das Programm funktioniert, und es so zu ändern, dass es Ihre Berechnungen nach Wunsch ausführt (Zugang zum Quellcode ist eine Voraussetzung dafür).
- Freiheit 2: Die Freiheit, Kopien weiterzugeben, damit Sie anderen helfen können.
- Freiheit 3: Die Freiheit, Kopien Ihrer modifizierten Versionen an andere zu verteilen (Zugang zum Quellcode ist eine Voraussetzung dafür).
Die FSF betont, dass „frei“ sich auf Freiheit und nicht auf Preis bezieht, in einem häufig zitierten Satz von FOSS-Befürwortern: „‚frei‘ wie in ‚freier Rede‘, nicht wie in ‚freibier‘.“
Die Open Source Initiative’s Open Source Definition fügt zehn praktische Kriterien hinzu. Dazu gehören kostenlose Weiterverbreitung ohne Lizenzgebühren, Verfügbarkeit des Quellcodes in der bevorzugten Form zur Modifikation, das Recht, abgeleitete Werke zu erstellen und zu verteilen, und keine Diskriminierung gegen Personen, Gruppen oder Tätigkeitsfelder — einschließlich kommerzieller Nutzung. Eine Lizenz muss alle zehn Kriterien erfüllen, um als Open Source gemäß dem OSI-Standard zu gelten.
„Quellcode verfügbar“ oder „Quellcode einsehbar“ ist etwas anderes. Der Code kann öffentlich lesbar sein, während die Lizenz das Recht einschränkt, ihn zu verkaufen. Das Firmware von Coldcard wird beispielsweise unter MIT-Bedingungen plus der Commons-Klausel veröffentlicht. Die Klausel entfernt speziell das Recht, die Software zu „verkaufen“ — definiert als Bereitstellung an Dritte gegen Gebühr oder andere Gegenleistungen in einem Produkt oder einer Dienstleistung, deren Wert vollständig oder überwiegend aus der Software selbst stammt. Mit anderen Worten, die Firmware von Coldcard könnte nicht kommerziell genutzt werden.
Die eigene FAQ der Commons-Klausel beschreibt den Unterschied ausdrücklich: „Ist das ‚Open Source‘? Nein.“ Sie weist darauf hin, dass die Anwendung der Klausel bedeutet, dass die Software viele Elemente der Open Source-Definition erfüllt, aber nicht alle, und daher nicht als Open Source bezeichnet werden sollte.
Diese Unterscheidungen sind wichtig. Die Veröffentlichung des Quellcodes schafft die Möglichkeit der Überprüfung. Die Gewährung des vollständigen Satzes von Rechten, die durch die Definition von Freier Software oder die Open Source-Definition definiert sind, macht Software zu FOSS oder FLOSS. Aber das Tragen des Genehmigungsabzeichens, die Möglichkeit, eine FOSS- oder FLOSS-Flagge zu schwenken, ist nicht der Punkt. Die kommerzielle Freiheit in FOSS eröffnet Anreize für Dritte, Code zu testen und zu überprüfen, die sonst möglicherweise nicht vorhanden wären, argumentieren Kritiker.
Die vier Freiheiten bilden den philosophischen Kern von Open Source. In der Praxis beruhen sie auf einer wirtschaftlichen Annahme: dass genügend motivierte Menschen tatsächlich den Code überprüfen werden. Wenn diese Annahme fehlschlägt, produziert das System eine klassische Tragödie der Allmende, eine Situation, in der eine gemeinsame Ressource übernutzt oder vernachlässigt wird, weil individuelle Nutzer in ihrem eigenen kurzfristigen Eigeninteresse handeln, anstatt im langfristigen Interesse der Gruppe.
Jede Person hat einen Anreiz, mehr (oder weniger beizutragen), als nachhaltig ist, und die Ressource verschlechtert sich als Folge davon. Dies geschieht, wenn es eine Fehlanpassung zwischen dem kurzfristigen Eigeninteresse des Einzelnen und dem langfristigen Interesse der Gruppe gibt. Manchmal besteht eine Übereinstimmung; manchmal besteht sie nicht.
Ein Bitcoin-Entwickler brachte das Problem deutlich auf den Punkt: „Die Verwendung von Mocks und Stubs von Open-Source-Code in Tests ist unverantwortlich und kurzsichtig. Open-Source-Code gilt als sicher, weil ihn jeder überprüfen kann. Wenn Sie nicht bereit sind, das Minimum an Tests für die Funktionen durchzuführen, von denen Sie tatsächlich abhängen, verhalten Sie sich wie ein Parasit.“
Infolgedessen schafft Open Source nicht von sich aus Sicherheit. Es schafft die Möglichkeit zur Überprüfung. Ob diese Überprüfung erfolgt, hängt von Anreizen, Fähigkeiten und Aufmerksamkeit ab. Historisch wird angenommen, dass FOSS im Laufe der Zeit robuster wird, da Schwachstellen entdeckt, offengelegt und gepatcht werden, wodurch solide Grundlagen geschaffen werden, auf denen andere aufbauen. Der Linux-Kernel ist ein großartiges Beispiel für solches gehärtetes FOSS; er treibt die überwiegende Mehrheit der Server, Cloud-Infrastruktur, Android-Geräte und eingebetteten Systeme der Welt an und ist damit eines der am weitesten verbreiteten Softwareprodukte in der Geschichte.
Open Source, wie es durch Bitcoin Core demonstriert wird
Bitcoin Core, die Referenzimplementierung von Bitcoin, ist ein weiteres vorausschauendes Beispiel für das Funktionieren von reinem Open Source im echten Leben. Die Software, die hinter den meisten Bitcoin-bezogenen Infrastrukturen läuft, wird unter der MIT-Lizenz veröffentlicht. Ihr Entwicklungsprozess ist absichtlich weitgehend öffentlich.
Jeder kann einen Pull-Request öffnen. Die Code-Überprüfung ist der primäre Filter und der empfohlene Einstiegspunkt für neue Mitwirkende. Prüfer verwenden eine formale Sprache—Concept ACK (Anerkennung und Zustimmung zum Ziel), Approach ACK (Zustimmung zum Ziel und zur Methode), ACK mit einem spezifischen Commit-Hash (getestet und zur Zusammenführung genehmigt) oder NACK (Nicht-Zustimmung, die mit technischen Gründen untermauert werden sollte).
Pflegepersonen wägen den Konsens unter den Mitwirkenden und die technischen Vorzüge einer Änderung ab, bevor sie zusammengeführt wird. Konsenskritische Änderungen stehen vor einer noch höheren Hürde und erfordern in der Regel einen Bitcoin Improvement Proposal sowie umfangreiche mehrjährige Diskussionen in der bitcoin-dev Mailingliste und im IRC.
Es gibt keine privilegierte Kaste von „Bitcoin Core Entwicklern.“ Vertrauen wird durch nachgewiesene Kompetenz über die Zeit verdient. Pflegepersonen existieren aus praktischen Gründen—Überprüfung und Zusammenführung von Code, Verwaltung von Releases und grundlegende Moderation—aber die produzierte Arbeit ist reiner Open-Source-Code, den jeder inspizieren, erstellen, forken oder ausführen kann. Entwickler, die Code-‘Commits’ in Bitcoin Core zusammengeführt bekommen, werden allgemein als Bitcoin Core Contributors bezeichnet.
Calle, ein langjähriger Open-Source Bitcoin-Entwickler, fasste die Realität kürzlich zusammen: „Menschen, die denken, dass Core eine Art intransparente Institution ist, die im Schatten operiert, sind entweder zu faul oder zu dumm, um selbst einen Blick darauf zu werfen. Buchstäblich alles, was sie tun, ist öffentlich, jeder kann sich einbringen, und das Ergebnis ihrer Arbeit ist reiner Open Source-Code.“
Die Finanzierung dieser Arbeit erfolgt hauptsächlich über gemeinnützige und Förderstrukturen wie Brink, OpenSats, Spiral und andere, anstatt über einen traditionellen Produktfahrplan eines Unternehmens. Technische Diskussionen und Debatten finden öffentlich auf der bitcoin-dev Mailingliste und im #bitcoin-core-dev IRC-Kanal auf Libera Chat statt, wo Vorschläge vor und während des Pull-Request-Prozesses geprüft werden. GitHub-Issues und Pull-Requests haben oft Kommentarverläufe, die bis zu einem Jahrzehnt zurückreichen. Das Ergebnis ist eine Entwicklungskultur, die auf Korrektheit und Prüfbarkeit optimiert ist, anstatt auf Geschwindigkeit oder kommerzielle Funktionsgeschwindigkeit.
Die Wirtschaftlichkeit von Open Source
Die meisten Nutzer von Open-Source- oder quelloffener Software lesen den Code selbst nie. Sie verlassen sich auf die Annahme, dass andere ihn überprüfen. Im Fall von Coldcard blieb ein kritischer Entropiefehler etwa fünf Jahre lang in der öffentlich verfügbaren Firmware, bevor er ausgenutzt und somit entdeckt wurde.
Der Fehler trat während eines umfangreichen Umbaus im Jahr 2021 in den Code ein, der auch den verbleibenden GPL-abgeleiteten Code von Trezor entfernte, der ersten Hardware-Wallet und jetzt der zweitgrößten in der Selbstverwahrungsbranche. Die Bibliothek im Zentrum des Entropie-Fehlers, die trezor-crypto ersetzt hat, heißt libngu und hatte minimale externe Überprüfung, mit nur 7 Sternen und weniger als 20 Forks in über 5 Jahren Nutzung in der Produktion. Vergleichen Sie das mit den 512 Sternen, die die trezor-crypto-Bibliothek hat, sowie 212 Forks, oder den 793 Forks und 1,8k Sternen der moderneren trezor-firmware. Allein die Verfügbarkeit der Quelle führte nicht zu der Überprüfung, die wichtig war, da andere gewinnorientierte, gut finanzierte Unternehmen daran gehindert wurden, sie zu nutzen, oder so würden Kritiker argumentieren.
Die Einsätze sind im Bitcoin höher als in den meisten Softwarebereichen. Ein kritischer Fehler kann direkt in liquide Mittel auf dem offenen Markt umgewandelt werden. Während die erste Hälfte der gestohlenen Coldcard-Mittel immer noch in einer Handvoll Adressen gehalten wird und der Hacker eines Tages gefasst werden könnte, waren die nachfolgenden Copycat-Hacker vorsichtiger, und einige haben mehr Bitcoin gestohlen und erfolgreich gewaschen, so Galaxy Research. Die Zensurresistenz und die unveränderliche Transaktionsfähigkeit von Bitcoin schaffen sowohl einen starken Anreiz für Angreifer als auch einen darwinistischen Filter; nur Projekte, die kontinuierlich kompetente Überprüfungen anziehen, und Benutzer und Unternehmen, die ernsthafte Vorsichtsmaßnahmen treffen, neigen dazu, langfristig zu überleben.
Lizenzierungsentscheidungen gestalten diese Anreize laut FOSS-Befürwortern, die Coinkites Lizenzentscheidungen seit Jahren kritisieren. Reine Open-Source-Lizenzen maximieren den Pool potenzieller Prüfer und Forks. Eingeschränkte „source available“-Lizenzen können kommerzielles Free-Riding reduzieren, aber auch den Kreis der Personen verringern, die sowohl das rechtliche Recht als auch das wirtschaftliche Motiv haben, tiefgehende Aufmerksamkeit zu investieren. Leider fällt die Last der Code-Überprüfung auf das Unternehmen unter einer restriktiven Lizenz zurück, was es in gewissem Sinne näher an Closed Source als an Open Source bringt.
Wie KI die Entwicklung von Open- und Closed Source verändert
Künstliche Intelligenz verändert jetzt auch das Gleichgewicht zwischen FOSS und Closed Source.
Nach dem Coldcard-Vorfall nutzte ein freiwilliges Projekt, bekannt als das Bitcoin Red Team – geleitet von Entwicklern wie Calle und Rob Hamilton von AnchorWatch und unterstützt von OpenSats – moderne KI-Modelle, um Hunderte von Open-Source-Bitcoin-Repositories zu scannen. In einer intensiven Phase reichte das Team Tausende von Ergebnissen ein, darunter Dutzende, die als kritisch oder hochgradig eingestuft wurden, über Hunderte von Projekten hinweg. Verantwortungsvolle Offenlegungen wurden an die Maintainer vor einer breiteren Veröffentlichung gemacht. Die Übung zeigte, dass eine systematische KI-unterstützte Überprüfung Probleme in einem Maßstab und einer Geschwindigkeit aufdecken kann, die für rein menschliche Teams zuvor unpraktisch waren.
In diesem Zusammenhang ist es erwähnenswert, dass das Red Team chinesische Open-Weight-Modelle als weitaus zuverlässiger empfand als geschlossene amerikanische Modelle, die selbst mit Cyber-Berechtigungen und erstklassigem Zugang sich weigerten, die Anfragen des Red Teams zu beantworten, ein Trend, den die amerikanischen Entwickler bedauern.
Gleichzeitig hat die Flut von KI-generiertem Code einen neuen Denial-of-Service-Druck auf FOSS-Wartende erzeugt. Die Überprüfung von KI-Ausgaben dauert oft länger als deren Erstellung. Einige Open-Source-Projekte außerhalb von Bitcoin haben die Issue-Tracker eingeschränkt oder strenge Anti-KI-Beitragsregeln eingeführt, um einfach funktionsfähig zu bleiben.
Quelle: BitcoinMagazine
