Bitcoin Magazine: Open Source vs. Source-Available: Was der Coldcard-Fehler über Anreize für Bitcoin-Software verrät

Closed Source und Open Source spalten die Bitcoin- und die breitere Krypto-Branche seit mehr als einem Jahrzehnt. Bitcoin-Befürworter argumentieren seit Langem, dass die Finanzinfrastruktur der Welt öffentlich entwickelt werden sollte, und sagen, Transparenz und Prüfbarkeit seien nicht verhandelbar, wenn echtes Geld auf dem Spiel steht. Die Anwendungs- und Legacy-Ebenen des Finanzwesens sehen das oft anders.

Der jüngste Coldcard-Hack, bei dem es sich um eine beliebte Hardware-Wallet zur Selbstverwahrung handelte und Nutzer mehr als 100 Millionen US-Dollar in Bitcoin, also mehr als 1.500 BTC, verloren, warf Fragen darüber auf, was „Open Source“ eigentlich bedeutet. Er deutete auch darauf hin, dass viele Menschen, darunter auch einige ernsthafte Bitcoin-Anhänger, die Philosophie freier/Open-Source-Software und die Bedingungen ihres Scheiterns nur unzureichend verstehen.

Die Prinzipien und die Terminologie

Die Sprache rund um Open Source kann verwirrend sein. Free and Open Source Software (FOSS) und Free/Libre and Open Source Software (FLOSS) beschreiben Software, die formalen Definitionen von Nutzerfreiheit entspricht.

Die Free Software Foundation (FSF) definiert freie Software anhand von vier wesentlichen Freiheiten:

Freiheit 0: Die Freiheit, das Programm wie gewünscht und für jeden Zweck auszuführen.

Freiheit 1: Die Freiheit, zu studieren, wie das Programm funktioniert, und es zu ändern, damit es die eigene Arbeit wie gewünscht erledigt. Der Zugriff auf den Quellcode ist dafür eine Voraussetzung.

Freiheit 2: Die Freiheit, Kopien weiterzugeben, um anderen zu helfen.

Freiheit 3: Die Freiheit, Kopien der eigenen geänderten Versionen an andere zu verteilen. Der Zugriff auf den Quellcode ist dafür eine Voraussetzung.

Die FSF betont, dass sich „free“ auf Freiheit und nicht auf Preis bezieht, in dem bekannten Satz von FOSS-Befürwortern: „‚free‘ as in ‚free speech,‘ not as in ‚free beer.‘“

Die Open Source Definition der Open Source Initiative ergänzt zehn praktische Kriterien. Dazu gehören die freie Weitergabe ohne Lizenzgebühren, die Verfügbarkeit des Quellcodes in der bevorzugten Form zur Bearbeitung, das Recht, abgeleitete Werke zu erstellen und zu verbreiten, sowie keine Diskriminierung von Personen, Gruppen oder Tätigkeitsfeldern – einschließlich kommerzieller Nutzung. Eine Lizenz muss alle zehn Kriterien erfüllen, um nach dem OSI-Standard als Open Source zu gelten.

„Source available“ oder „source viewable“ ist etwas anderes. Code kann öffentlich lesbar sein, während die Lizenz weiterhin das Recht einschränkt, ihn zu verkaufen. Coldcards Firmware wird beispielsweise unter MIT-Bedingungen plus der Commons Clause veröffentlicht. Die Klausel entzieht ausdrücklich das Recht, die Software zu „Sell“ – definiert als Bereitstellung an Dritte gegen Gebühr oder eine andere Gegenleistung in einem Produkt oder Dienst, dessen Wert ganz oder überwiegend aus der Software selbst abgeleitet wird. Anders gesagt: Coldcards Firmware konnte nicht kommerziell verwendet werden.

Die FAQ der Commons Clause stellt den Unterschied klar: „Is this ‘Open Source’? No.“ Dort heißt es, die Anwendung der Klausel bedeute, dass die Software viele Elemente der Open Source Definition erfülle, aber nicht alle, und daher nicht als Open Source bezeichnet werden sollte.

Diese Unterscheidungen sind wichtig. Die Veröffentlichung von Quellcode schafft erst die Möglichkeit zur Prüfung. Die vollständige Gewährung der in der Free Software Definition oder der Open Source Definition festgelegten Rechte ist das, was Software zu FOSS oder FLOSS macht. Doch das Abzeichen allein ist nicht der Punkt. Kritiker argumentieren, dass kommerzielle Freiheit in FOSS Anreize für Dritte freisetzt, Code zu testen und zu prüfen, die sonst möglicherweise nicht vorhanden wären.

Die vier Freiheiten bilden den philosophischen Kern von Open Source, beruhen in der Praxis aber auf einer wirtschaftlichen Annahme: dass genügend motivierte Menschen den Code tatsächlich prüfen. Wenn diese Annahme scheitert, entsteht ein klassisches Problem der Allmende, bei dem eine gemeinsam genutzte Ressource vernachlässigt wird, weil Einzelne in ihrem kurzfristigen Eigeninteresse statt im langfristigen Interesse der Gruppe handeln.

Jede Person hat einen Anreiz, mehr zu nehmen oder weniger beizutragen, als nachhaltig wäre, und die Ressource verschlechtert sich dadurch. Ob die Anreize übereinstimmen, hängt von der Situation ab.

Ein Bitcoin-Entwickler formulierte das Problem unverblümt: „Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech.“

Open Source schafft also nicht von sich aus Sicherheit. Es schafft die Möglichkeit zur Verifikation. Ob diese Verifikation stattfindet, hängt von Anreizen, Können und Aufmerksamkeit ab. Historisches FOSS gilt als etwas, das mit der Zeit widerstandsfähiger wird, wenn Schwachstellen entdeckt, offengelegt und behoben werden, wodurch solide Grundlagen entstehen, auf denen andere aufbauen können. Der Linux-Kernel ist ein gutes Beispiel für solch gehärtetes FOSS; er treibt den Großteil der Server, Cloud-Infrastruktur, Android-Geräte und Embedded-Systeme der Welt an und ist damit eines der am weitesten verbreiteten Softwarewerke der Geschichte.

Open Source am Beispiel von Bitcoin Core

Bitcoin Core, die Referenzimplementierung von Bitcoin, ist ein weiteres groß angelegtes Beispiel dafür, wie Open Source in der Praxis funktioniert. Die Software, die hinter der meisten Bitcoin-bezogenen Infrastruktur läuft, wird unter der MIT-Lizenz veröffentlicht. Ihr Entwicklungsprozess ist bewusst öffentlich.

Jeder kann einen Pull Request öffnen. Code-Review ist der primäre Filter und der empfohlene Einstiegspunkt für neue Mitwirkende. Reviewer verwenden eine formale Terminologie: Concept ACK, also Anerkennung und Zustimmung zum Ziel; Approach ACK, also Zustimmung zum Ziel und zur Methode; ACK mit einem bestimmten Commit-Hash, also getestet und zur Zusammenführung freigegeben; oder NACK, also Ablehnung, die mit technischer Begründung einhergehen sollte.

Maintainer bewerten vor dem Mergen den Konsens unter den Mitwirkenden und die technischen Vorzüge einer Änderung. Konsenskritische Änderungen unterliegen einer noch höheren Hürde und erfordern in der Regel einen Bitcoin Improvement Proposal sowie umfangreiche mehrjährige Diskussionen auf der bitcoin-dev-Mailingliste und in IRC.

Es gibt keine privilegierte Kaste von „Bitcoin Core developers“. Vertrauen wird über Zeit durch nachgewiesene Kompetenz erworben. Maintainer existieren aus praktischen Gründen – Code prüfen und mergen, Releases verwalten und grundlegende Moderation – doch die erzeugte Arbeit ist reiner Open-Source-Code, den jeder prüfen, bauen, forken oder ausführen kann. Entwickler, deren Code-Commits in Bitcoin Core zusammengeführt werden, werden allgemein als Bitcoin Core Contributors bezeichnet.

Calle, ein langjähriger Open-Source-Bitcoin-Entwickler, fasste die Lage kürzlich so zusammen: „People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code.“

Die Finanzierung dieser Arbeit erfolgt größtenteils über Nonprofit- und Förderstrukturen wie Brink, OpenSats, Spiral und andere und nicht über eine traditionelle Produkt-Roadmap eines Unternehmens. Technische Diskussionen und Debatten finden öffentlich auf der bitcoin-dev-Mailingliste und im IRC-Kanal #bitcoin-core-dev auf Libera Chat statt, wo Vorschläge vor und während des Pull-Request-Prozesses geprüft werden. GitHub-Issues und Pull Requests enthalten oft Kommentarverläufe, die sich über ein Jahrzehnt erstrecken. Das Ergebnis ist eine Entwicklungskultur, die auf Korrektheit und Prüfbarkeit statt auf Geschwindigkeit oder kommerzielle Feature-Geschwindigkeit optimiert ist.

Die Ökonomie von Open Source

Die meisten Nutzer von Open-Source- oder Source-Available-Software lesen den Code nie selbst. Sie verlassen sich darauf, dass andere ihn prüfen. Im Fall von Coldcard blieb eine kritische Entropie-Schwachstelle in öffentlich verfügbarer Firmware etwa fünf Jahre lang bestehen, bevor sie ausgenutzt und damit entdeckt wurde.

Der Fehler gelangte während einer umfassenden Neuimplementierung im Jahr 2021 in die Codebasis, bei der auch der verbliebene von der GPL abgeleitete Code aus Trezor entfernt wurde, der ersten Hardware-Wallet und heute der zweitgrößten in der Self-Custody-Branche. Die Bibliothek im Zentrum des Entropie-Fehlers, die trezor-crypto ersetzte, heißt libngu und erhielt nur minimale externe Prüfung, mit lediglich 7 Stars und weniger als 20 Forks in mehr als fünf Jahren produktiver Nutzung. Zum Vergleich: Die Bibliothek trezor-crypto hat 512 Stars und 212 Forks, während das modernere trezor-firmware 793 Forks und 1.8k Stars aufweist. Allein Source Availability führte also nicht zu der entscheidenden Prüfung, weil anderen gewinnorientierten, gut finanzierten Unternehmen die Nutzung untersagt war – so würden Kritiker argumentieren.

Praktisch bedeutet das, dass Lizenzentscheidungen mehr sind als eine juristische Fußnote: Sie beeinflussen, wer an der Prüfung teilnehmen kann, wer einen Anreiz dazu hat und wie schnell Schwachstellen in Software bemerkt werden, die reale Gelder absichert. In Bitcoin sind die Einsätze höher als in den meisten anderen Softwarebereichen. Ein kritischer Fehler kann direkt in liquide Mittel auf dem offenen Markt umgewandelt werden. Während die erste Hälfte der gestohlenen Coldcard-Gelder noch in einigen wenigen Adressen gehalten wird und der Hacker eines Tages gefasst werden könnte, gingen nachfolgende Nachahmungstäter vorsichtiger vor, und einige haben laut Galaxy Research mehr Bitcoin gestohlen und erfolgreich gewaschen. Bitcoins Zensurresistenz und unveränderliche Transaktionsfähigkeit schaffen sowohl einen starken Anreiz für Angreifer als auch einen darwinistischen Filter: Langfristig überleben tendenziell nur Projekte, die kontinuierlich kompetente Prüfung anziehen, sowie Nutzer und Unternehmen, die ernsthafte Vorsichtsmaßnahmen treffen.

Lizenzentscheidungen prägen diese Anreize, sagen FOSS-Befürworter, die Coinkites Lizenzpolitik seit Jahren kritisieren. Reine Open-Source-Lizenzen maximieren den Pool potenzieller Prüfer und Forks. Eingeschränkte „source available“-Lizenzen können kommerzielles Trittbrettfahren reduzieren, aber auch den Kreis derjenigen verkleinern, die sowohl das rechtliche Recht als auch den wirtschaftlichen Anreiz haben, sich tiefgehend zu engagieren. In diesem Sinn fällt die Last der Codeprüfung wieder auf das Unternehmen unter einer restriktiven Lizenz zurück, was es in gewisser Weise näher an Closed Source als an Open Source rückt.

Wie KI Open- und Closed-Source-Entwicklung verändert

Künstliche Intelligenz verändert inzwischen auch das Gleichgewicht zwischen FOSS und Closed Source.

Nach dem Coldcard-Vorfall nutzte eine freiwillige Initiative namens Bitcoin Red Team – angeführt von Entwicklern wie Calle und Rob Hamilton von AnchorWatch und unterstützt von OpenSats – Frontier-KI-Modelle, um Hunderte Open-Source-Bitcoin-Repositorien zu durchsuchen. In einer intensiven Phase reichte das Team Tausende von Befunden ein, darunter Dutzende als kritisch oder hoch eingestuft, über Hunderte von Projekten hinweg. Vor einer breiteren Veröffentlichung wurden den Maintainer verantwortungsvolle Offenlegungen gemacht. Der Versuch zeigte, dass systematische KI-gestützte Prüfung Probleme in einem Ausmaß und Tempo aufdecken kann, das für rein menschliche Teams bisher unpraktikabel war.

Dabei stellte das Red Team fest, dass chinesische Open-Weight-Modelle weitaus zuverlässiger waren als geschlossene amerikanische Modelle, die selbst mit Cyber-Berechtigungen und oberster Zugriffsstufe Red-Team-Anfragen nicht beantworteten – ein Trend, den die amerikanischen Entwickler beklagten.

Gleichzeitig hat die Flut KI-generierten Codes einen neuen Denial-of-Service-Druck auf FOSS-Maintainer erzeugt. Das Prüfen von KI-Ausgaben dauert oft länger als deren Erzeugung. Einige Open-Source-Projekte außerhalb von Bitcoin haben Issue-Tracker eingeschränkt oder strenge Anti-KI-Beitragsregeln eingeführt, um überhaupt funktionsfähig zu bleiben.

Auf der Closed-Source-Seite erodiert der traditionelle Vorteil von Security through Obscurity. Moderne KI-Modelle können Code lesen, de-obfuskieren, Endpunkte testen und mit hoher Geschwindigkeit über Code nachdenken. Der praktische Unterschied zwischen Open und Closed Source beschränkt sich inzwischen größtenteils auf Backend-Code, der nie online geteilt wird. Closed-Source-Code steht damit letztlich nur noch auf der Qualität professioneller Audits, der Geschwindigkeit der Patch-Auslieferung und der Anreizstruktur, die kompetente Personen mit Zugriff zum Hinschauen motiviert.

Bitcoin und die breitere Krypto-Branche setzen freie und Open-Source-Software ungewöhnlich stark unter Druck. Die Kombination aus realem monetärem Risiko, adversen ökonomischen Anreizen und Analyse im KI-Maßstab zwingt Softwaremodelle zur Weiterentwicklung. Eine Rückkehr zu analogen, vor-digitalen Systemen ist für eine Infrastruktur, die die moderne Gesellschaft trägt, kaum eine Option. Wahrscheinlich werden nur die am gründlichsten geprüften Projekte den Belastungen durch KI-gestützte Angreifer und das Gewicht einer digital-first Finanzwelt standhalten.

Dieser Beitrag „Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives“ erschien zuerst auf Bitcoin Magazine und wurde von Juan Galt verfasst.