Bitcoin Magazine: Open source versus source-available: wat het falen van Coldcard onthult over prikkels voor Bitcoin-software

Gesloten source en open source verdelen de Bitcoin- en bredere cryptosector al meer dan tien jaar. Voorstanders van Bitcoin hebben lange tijd betoogd dat de financiële infrastructuur van de wereld in het openbaar moet worden gebouwd, omdat transparantie en controleerbaarheid niet onderhandelbaar zijn wanneer er echt geld op het spel staat. De app- en legacy-lagen van de financiële sector zijn het daar vaak niet mee eens.

De recente Coldcard-hack, waarbij gebruikers van een populaire hardwarewallet voor zelfbeheer meer dan $100 miljoen aan bitcoin verloren, of meer dan 1,500 BTC, riep vragen op over wat “open source” eigenlijk betekent. Het suggereerde ook dat veel mensen, waaronder serieuze bitcoiners, onvoldoende op de hoogte zijn van de open-source softwarefilosofie en de omstandigheden waaronder die faalt.

De principes en terminologie

De taal rond open source kan verwarrend zijn. Free and Open Source Software (FOSS) en Free/Libre and Open Source Software (FLOSS) beschrijven software die voldoet aan formele definities van gebruikersvrijheid.

De Free Software Foundation (FSF) definieert vrije software aan de hand van vier essentiële vrijheden:

Vrijheid 0: De vrijheid om het programma uit te voeren zoals u wilt, voor welk doel dan ook.

Vrijheid 1: De vrijheid om te bestuderen hoe het programma werkt en het te wijzigen zodat het doet wat u wilt. Toegang tot de broncode is hiervoor een voorwaarde.

Vrijheid 2: De vrijheid om kopieën te herdistribueren zodat u anderen kunt helpen.

Vrijheid 3: De vrijheid om kopieën van uw gewijzigde versies aan anderen te verspreiden. Toegang tot de broncode is hiervoor een voorwaarde.

De FSF benadrukt dat “free” verwijst naar vrijheid, niet naar prijs, in de bekende formulering van FOSS-voorstanders: “‘free’ als in ‘free speech’, niet als in ‘free beer.’”

De Open Source Definition van de Open Source Initiative voegt tien praktische criteria toe. Daaronder vallen vrije herdistributie zonder royalty’s, beschikbaarheid van de broncode in de voorkeursvorm voor aanpassing, het recht om afgeleide werken te maken en te verspreiden, en geen discriminatie op basis van personen, groepen of werkterreinen — inclusief commercieel gebruik. Een licentie moet aan alle tien criteria voldoen om als open source te kwalificeren onder de OSI-norm.

“Source available” of “source viewable” is iets anders. Code kan publiek leesbaar zijn terwijl de licentie het recht om die te verkopen beperkt. De firmware van Coldcard wordt bijvoorbeeld vrijgegeven onder MIT-voorwaarden plus de Commons Clause. Die clausule verwijdert specifiek het recht om de software te “Sell” — gedefinieerd als het aan derden verstrekken tegen betaling of andere tegenprestatie in een product of dienst waarvan de waarde geheel of grotendeels uit de software zelf is afgeleid. Met andere woorden, de firmware van Coldcard kon niet commercieel worden gebruikt.

De FAQ van de Commons Clause zegt het verschil expliciet: “Is this ‘Open Source’? No.” Daarin staat dat toepassing van de clausule betekent dat de software aan veel elementen van de Open Source Definition voldoet, maar niet aan alle, en daarom niet open source genoemd zou moeten worden.

Deze onderscheidingen zijn belangrijk. Het publiceren van broncode schept de mogelijkheid tot inspectie. Het verlenen van het volledige pakket rechten dat in de Free Software Definition of de Open Source Definition is vastgelegd, is wat software FOSS of FLOSS maakt. Maar het etiket zelf is niet het punt. Critici stellen dat commerciële vrijheid in FOSS derde partijen prikkels geeft om code te testen en te beoordelen die anders misschien niet zouden bestaan.

De vier vrijheden vormen de filosofische kern van open source, maar in de praktijk rusten zij op een economische veronderstelling: dat genoeg gemotiveerde mensen de code daadwerkelijk zullen bekijken. Wanneer die veronderstelling faalt, ontstaat iets dat lijkt op een tragedy of the commons, waarbij een gedeelde hulpbron wordt verwaarloosd omdat individuen handelen vanuit hun eigen kortetermijnbelang in plaats van het langetermijnbelang van de groep.

Iedereen heeft een prikkel om meer te nemen, of minder bij te dragen, dan houdbaar is, en de hulpbron verslechtert daardoor. Of de prikkels op elkaar aansluiten, hangt van de situatie af.

Een Bitcoin-ontwikkelaar formuleerde het probleem scherp: “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 creëert op zichzelf geen veiligheid. Het creëert de mogelijkheid tot verificatie. Of die verificatie plaatsvindt, hangt af van prikkels, vaardigheid en aandacht. Historische FOSS wordt vaak geacht na verloop van tijd harder te worden doordat kwetsbaarheden worden ontdekt, openbaar gemaakt en gepatcht, waardoor stevige fundamenten ontstaan waarop anderen verder bouwen. De Linux-kernel is een goed voorbeeld van zulke geharde FOSS; zij drijft het overgrote deel van de servers, cloudinfrastructuur, Android-apparaten en embedded systemen ter wereld aan, waardoor het een van de meest breed ingezette softwarepakketten in de geschiedenis is.

Open source zoals gedemonstreerd door Bitcoin Core

Bitcoin Core, de referentie-implementatie van Bitcoin, is een ander grootschalig voorbeeld van open source dat in de praktijk werkt. De software, die achter de meeste Bitcoin-gerelateerde infrastructuur draait, wordt uitgebracht onder de MIT-licentie. Het ontwikkelproces is bewust openbaar.

Iedereen kan een pull request openen. Code review is de primaire filter en het aanbevolen startpunt voor nieuwe bijdragers. Reviewers gebruiken een formele woordenschat: Concept ACK, wat instemming met het doel betekent; Approach ACK, wat instemming met het doel en de methode betekent; ACK met een specifieke commit hash, wat betekent dat het getest en goedgekeurd is voor samenvoeging; of NACK, wat onenigheid betekent, vergezeld van technische onderbouwing.

Beheerders wegen de consensus onder bijdragers en de technische merites van een wijziging af voordat zij die samenvoegen. Wijzigingen die consensuskritiek zijn, krijgen een hogere drempel en vereisen meestal een Bitcoin Improvement Proposal, samen met uitgebreide discussies van meerdere jaren op de bitcoin-dev mailinglijst en IRC.

Er is geen bevoorrechte kaste van “Bitcoin Core developers.” Vertrouwen wordt verdiend door in de loop van de tijd aangetoonde competentie. Beheerders zijn er om praktische redenen: code auditen en samenvoegen, releases beheren en basismoderatie. Maar het werk dat wordt geproduceerd is pure open-source code die iedereen kan inspecteren, bouwen, forken of draaien. Ontwikkelaars van wie commits in Bitcoin Core worden samengevoegd, worden in grote lijnen Bitcoin Core Contributors genoemd.

Calle, al lange tijd open-source Bitcoin-ontwikkelaar, vatte de situatie onlangs samen: “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.”

Financiering voor dit werk komt grotendeels uit non-profit- en subsidieconstructies zoals Brink, OpenSats, Spiral en anderen, in plaats van uit een traditionele product-roadmap van een bedrijf. Technische discussie en debat vinden openbaar plaats op de bitcoin-dev mailinglijst en in het #bitcoin-core-dev IRC-kanaal op Libera Chat, waar voorstellen vóór en tijdens het pull-request-proces worden gescreend. GitHub-issues en pull requests bevatten vaak commentaarhistorieën die tien jaar teruggaan. Het resultaat is een ontwikkelcultuur die is geoptimaliseerd voor correctheid en controleerbaarheid, niet voor snelheid of commerciële feature-velocity.

De economie van open source

De meeste gebruikers van open-source- of source-available software lezen de code zelf nooit. Zij vertrouwen op de aanname dat anderen die bekijken. In het geval van Coldcard bleef een kritieke fout in de entropie ongeveer vijf jaar lang aanwezig in publiek beschikbare firmware voordat zij werd uitgebuit en dus ontdekt.

De bug kwam in de codebase terecht tijdens een grote herschrijving in 2021, waarbij ook de resterende op GPL gebaseerde code uit Trezor werd verwijderd, de eerste hardwarewallet en inmiddels de op een na grootste in de zelfbewaringssector. De bibliotheek die centraal stond in het entropiefalen, en die trezor-crypto verving, heet libngu en kreeg minimale externe controle, met slechts 7 stars en minder dan 20 forks in meer dan 5 jaar gebruik in productie. Vergelijk dat met de 512 stars en 212 forks van de trezor-crypto-bibliotheek, of de 793 forks en 1.8k stars van de modernere trezor-firmware. Alleen source availability leverde niet de review op die ertoe deed, omdat andere winstgerichte, goed gefinancierde bedrijven er niet van mochten profiteren, althans volgens critici.

In de praktijk maken licentiekeuzes dus meer uit dan een juridische voetnoot: ze beïnvloeden wie kan deelnemen aan review, wie er een reden toe heeft en hoe snel gebreken worden opgemerkt in software die echt geld beveiligt. De inzet is hoger in Bitcoin dan in de meeste softwaredomeinen. Een kritieke fout kan direct worden omgezet in liquide middelen op de open markt. Hoewel de eerste helft van de gestolen Coldcard-tegoeden nog steeds op een handvol adressen wordt aangehouden en de hacker mogelijk ooit wordt gepakt, waren daaropvolgende copycat-hackers voorzichtiger, en sommigen hebben meer bitcoin gestolen en succesvol witgewassen, volgens Galaxy Research. Bitcoin’s censuurresistentie en onveranderlijke transactie-afwikkeling creëren zowel een sterke prikkel voor aanvallers als een Darwinistische filter: alleen projecten die voortdurend competente review aantrekken, en gebruikers en bedrijven die serieuze voorzorgsmaatregelen nemen, overleven doorgaans op de lange termijn.

Volgens FOSS-voorstanders die al jaren kritiek hadden op de licentie-keuzes van Coinkite, vormen licentiekeuzes die prikkels. Zuivere open-source-licenties maximaliseren de pool van potentiële reviewers en forks. Beperkte “source available”-licenties kunnen commercieel meeliften verminderen, maar kunnen ook de kring verkleinen van mensen die zowel het juridische recht als de economische motivatie hebben om diepgaande aandacht te investeren. In die zin valt de last van code review terug op het bedrijf onder een beperkende licentie, waardoor het in zekere zin dichter bij gesloten source komt dan bij open source.

Hoe AI open- en closed-sourceontwikkeling verandert

Kunstmatige intelligentie verandert inmiddels ook de balans tussen FOSS en closed source.

Na het Coldcard-incident gebruikte een vrijwillig initiatief dat bekendstaat als de Bitcoin Red Team — geleid door ontwikkelaars waaronder Calle en Rob Hamilton van AnchorWatch, en ondersteund door OpenSats — frontier AI-modellen om honderden open-source Bitcoin-repositories te scannen. In één intensieve periode diende het team duizenden bevindingen in, waaronder tientallen die als kritiek of hoog ernstig werden geclassificeerd, verspreid over honderden projecten. Verantwoorde meldingen werden aan maintainers gedaan vóór bredere publicatie. Het experiment toonde aan dat systematische AI-ondersteunde review problemen aan het licht kan brengen op een schaal en snelheid die voor puur menselijke teams eerder onpraktisch waren.

Op dit vlak vond de Red Team Chinese open-weightmodellen veel betrouwbaarder dan closed-source Amerikaanse modellen, die zelfs met cyberrechten en topniveau-toegang weigerden te antwoorden op vragen van de Red Team, een trend waar Amerikaanse ontwikkelaars hun frustratie over uitten.

Tegelijkertijd heeft de vloed aan door AI gegenereerde code een nieuwe denial-of-service-druk op FOSS-beheerders gecreëerd. Het beoordelen van AI-output kost vaak meer tijd dan het genereren ervan. Sommige open-sourceprojecten buiten Bitcoin hebben issue trackers beperkt of strikte anti-AI-bijdrageregels ingevoerd, simpelweg om functioneel te blijven.

Aan de closed-sourcekant erodeert het traditionele voordeel van security through obscurity. Moderne AI-modellen kunnen code lezen, de-obfusceren, endpoints onderzoeken en razendsnel over code redeneren. Het praktische verschil tussen open en closed source beperkt zich nu vooral tot backendcode die nooit online wordt gedeeld. Closed-sourcecode steunt daardoor op de kwaliteit van professionele audits, de snelheid van patch-uitrol en de prikkelstructuur die competente mensen met toegang betrokken houdt.

Bitcoin en de bredere cryptosector leggen ongebruikelijke druk op vrije en open-source software. De combinatie van reële monetaire waarde die op het spel staat, vijandige economische prikkels en AI-schaalanalyse dwingt softwaremodellen om te evolueren. Terugkeren naar analoge, pre-digitale systemen is nauwelijks een optie voor infrastructuur die de moderne samenleving draagt. Alleen de meest ge-audite projecten zullen waarschijnlijk de druk van AI-ondersteunde hackers en het gewicht van digitaal-eerst financiën overleven.

Dit artikel, “Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives,” verscheen oorspronkelijk op Bitcoin Magazine en is geschreven door Juan Galt.