Bitcoin Magazine: Open Source vs. Source-Available: What the Coldcard Failure Reveals About Bitcoin Software Incentives

Il software closed source e open source divide da oltre un decennio il settore Bitcoin e, più in generale, quello crypto. I sostenitori di Bitcoin hanno a lungo sostenuto che l'infrastruttura finanziaria del mondo debba essere costruita in pubblico, affermando che trasparenza e verificabilità non sono negoziabili quando sono in gioco soldi reali. I livelli applicativi e legacy della finanza spesso non sono d'accordo.

Il recente hack di Coldcard, un popolare hardware wallet per self-custody in cui gli utenti hanno perso oltre $100 million di bitcoin, cioè più di 1,500 BTC, ha sollevato dubbi su cosa significhi davvero “open source”. Ha anche suggerito che molte persone, compresi alcuni bitcoiners esperti, siano poco informate sulla filosofia del software open source e sulle condizioni in cui essa fallisce.

I principi e la terminologia

Il linguaggio intorno all'open source può essere confuso. Free and Open Source Software (FOSS) e Free/Libre and Open Source Software (FLOSS) descrivono software che soddisfa definizioni formali di libertà dell'utente.

La Free Software Foundation (FSF) definisce il software libero attraverso quattro libertà essenziali:

Freedom 0: La libertà di eseguire il programma come si desidera, per qualsiasi scopo.

Freedom 1: La libertà di studiare come funziona il programma e modificarlo in modo che faccia ciò che si desidera. L'accesso al codice sorgente è una condizione preliminare per questo.

Freedom 2: La libertà di ridistribuire copie per poter aiutare gli altri.

Freedom 3: La libertà di distribuire copie delle proprie versioni modificate ad altri. L'accesso al codice sorgente è una condizione preliminare per questo.

La FSF sottolinea che “free” si riferisce alla libertà, non al prezzo, nella nota formula usata dai sostenitori del FOSS: “‘free’ as in ‘free speech,’ not as in ‘free beer.’”

La Open Source Definition della Open Source Initiative aggiunge dieci criteri pratici. Tra questi figurano la ridistribuzione gratuita senza royalty, la disponibilità del codice sorgente nella forma preferita per la modifica, il diritto di creare e distribuire opere derivate e l'assenza di discriminazioni contro persone, gruppi o ambiti di attività, incluso l'uso commerciale. Una licenza deve soddisfare tutti e dieci i criteri per qualificarsi come open source secondo lo standard OSI.

“Source available” o “source viewable” è diverso. Il codice può essere leggibile pubblicamente mentre la licenza limita il diritto di venderlo. Il firmware di Coldcard, ad esempio, è rilasciato con termini MIT più la Commons Clause. La clausola rimuove specificamente il diritto di “Sell” il software — definito come fornirlo a terzi a pagamento o con altra contropartita in un prodotto o servizio il cui valore derivi interamente o sostanzialmente dal software stesso. In altre parole, il firmware di Coldcard non poteva essere utilizzato commercialmente.

L'FAQ della Commons Clause afferma esplicitamente la differenza: “Is this ‘Open Source’? No.” Specifica che l'applicazione della clausola fa sì che il software soddisfi molti elementi della Open Source Definition ma non tutti, e quindi non dovrebbe essere chiamato Open Source.

Queste distinzioni contano. Pubblicare il codice sorgente crea la possibilità di ispezione. Concedere l'intero insieme di diritti definito dalla Free Software Definition o dalla Open Source Definition è ciò che rende il software FOSS o FLOSS. Ma il riconoscimento formale non è il punto centrale. Secondo i critici, la libertà commerciale nel FOSS sblocca incentivi di terze parti a testare e revisionare il codice che altrimenti potrebbero non esistere.

Le quattro libertà costituiscono il nucleo filosofico dell'open source, ma nella pratica dipendono da un presupposto economico: che un numero sufficiente di persone motivate esamini davvero il codice. Quando questo presupposto fallisce, il risultato somiglia a una tragedia dei beni comuni, in cui una risorsa condivisa viene trascurata perché i singoli agiscono nel proprio interesse di breve termine invece che nell'interesse collettivo di lungo periodo.

Ogni persona ha l'incentivo a prendere più di quanto sia sostenibile, o a contribuire meno del necessario, e la risorsa si deteriora di conseguenza. Se gli incentivi si allineano dipende dalla situazione.

Un sviluppatore Bitcoin ha formulato il problema in modo netto: “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.”

Di conseguenza, l'open source non crea sicurezza da solo. Crea la possibilità di verifica. Se tale verifica avvenga dipende da incentivi, competenze e attenzione. Si dice spesso che il FOSS storico si rafforzi nel tempo man mano che le vulnerabilità vengono scoperte, divulgate e corrette, creando basi solide su cui altri possono costruire. Il kernel Linux è un esempio importante di FOSS ormai consolidato; alimenta la grande maggioranza dei server del mondo, l'infrastruttura cloud, i dispositivi Android e i sistemi embedded, diventando uno dei software più distribuiti della storia.

L'open source dimostrato da Bitcoin Core

Bitcoin Core, l'implementazione di riferimento di Bitcoin, è un altro esempio su larga scala di open source che funziona nella pratica. Il software, che opera dietro la maggior parte dell'infrastruttura legata a Bitcoin, è rilasciato con licenza MIT. Il suo processo di sviluppo è pubblicamente accessibile per progettazione.

Chiunque può aprire una pull request. La code review è il filtro principale e il punto di ingresso raccomandato per i nuovi contributori. I revisori usano un vocabolario formale: Concept ACK, cioè riconoscimento e accordo con l'obiettivo; Approach ACK, cioè accordo con l'obiettivo e il metodo; ACK con uno specifico commit hash, cioè testato e approvato per il merge; oppure NACK, cioè disaccordo accompagnato da motivazione tecnica.

I maintainers valutano il consenso tra i contributori e il merito tecnico di una modifica prima di integrarla. Le modifiche critiche per il consenso affrontano una soglia ancora più alta e di solito richiedono una Bitcoin Improvement Proposal, oltre a discussioni approfondite che possono durare anni nella mailing list bitcoin-dev e su IRC.

Non esiste una casta privilegiata di “Bitcoin Core developers”. La fiducia si guadagna nel tempo attraverso competenza dimostrata. I maintainers esistono per ragioni pratiche — revisione e merge del codice, gestione delle release e moderazione di base — ma il lavoro prodotto è puro codice open source che chiunque può ispezionare, compilare, forkare o eseguire. Gli sviluppatori i cui commit vengono integrati in Bitcoin Core sono in genere chiamati Bitcoin Core Contributors.

Calle, storico sviluppatore Bitcoin open source, ha riassunto di recente la situazione: “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.”

Il finanziamento di questo lavoro proviene in larga parte da strutture non profit e di grant come Brink, OpenSats, Spiral e altre, piuttosto che da una tradizionale roadmap di prodotto aziendale. Le discussioni tecniche si svolgono pubblicamente nella mailing list bitcoin-dev e nel canale IRC #bitcoin-core-dev su Libera Chat, dove le proposte vengono esaminate prima e durante il processo di pull request. Issue e pull request su GitHub spesso contengono storici di commenti che risalgono a dieci anni fa. Il risultato è una cultura di sviluppo ottimizzata per correttezza e verificabilità, non per velocità o per la rapidità di rilascio di funzionalità commerciali.

L'economia dell'open source

La maggior parte degli utenti di software open source o source available non legge mai il codice direttamente. Si affida all'assunzione che altri lo stiano esaminando. Nel caso di Coldcard, una grave falla nell'entropia è rimasta nel firmware pubblico per circa cinque anni prima di essere sfruttata e quindi scoperta.

Il bug è entrato nel codice durante una grande riscrittura nel 2021 che ha anche rimosso il codice residuo derivato da GPL da Trezor, il primo hardware wallet e ora il secondo più grande nel settore della self-custody. La libreria al centro del problema dell'entropia, che ha sostituito trezor-crypto, si chiama libngu e ha ricevuto un controllo esterno minimo, con solo 7 stelle e meno di 20 fork in oltre 5 anni di utilizzo in produzione. Confronto con le 512 stelle della libreria trezor-crypto e i suoi 212 fork, oppure con i 793 fork e le 1.8k stelle del più recente trezor-firmware. La sola disponibilità del sorgente non ha prodotto la revisione che contava, perché altre aziende profit, ben finanziate, erano limitate nell'usarlo, o così sostengono i critici.

In pratica, ciò rende le scelte di licenza più di una nota legale: influenzano chi può partecipare alla revisione, chi ha un motivo per farlo e quanto rapidamente possano emergere le falle in un software che protegge fondi reali. Le poste in gioco sono più alte in Bitcoin che nella maggior parte dei domini software. Una falla critica può essere convertita direttamente in fondi liquidi sul mercato aperto. Mentre la prima metà dei fondi Coldcard rubati è ancora detenuta in pochi indirizzi e l'hacker potrebbe un giorno essere catturato, gli imitatori che sono seguiti sono stati più prudenti e alcuni hanno rubato più bitcoin e lo hanno riciclato con successo, secondo Galaxy Research. La resistenza alla censura e la transazionalità immutabile di Bitcoin creano sia un forte incentivo per gli attaccanti sia un filtro darwiniano: tendono a sopravvivere nel lungo periodo solo i progetti che attirano costantemente revisioni competenti, e gli utenti e le aziende che adottano precauzioni serie.

Secondo i sostenitori del FOSS che per anni hanno criticato le scelte di licenza di Coinkite, le decisioni di licensing modellano questi incentivi. Le licenze open source pure massimizzano il bacino di potenziali revisori e fork. Le licenze “source available” ristrette possono ridurre il free-riding commerciale, ma possono anche restringere la cerchia di persone che hanno sia il diritto legale sia il motivo economico per investire attenzione approfondita. In questo senso, l'onere della code review ricade di nuovo sull'azienda che opera sotto una licenza restrittiva, collocandola in un certo senso più vicino al closed source che all'open source.

Come l'AI cambia lo sviluppo open e closed source

L'intelligenza artificiale sta ora modificando anche l'equilibrio tra FOSS e closed source.

Dopo l'incidente Coldcard, un'iniziativa volontaria nota come Bitcoin Red Team — guidata da sviluppatori tra cui Calle e Rob Hamilton di AnchorWatch, e supportata da OpenSats — ha utilizzato modelli AI di frontiera per analizzare centinaia di repository Bitcoin open source. In un periodo intenso, il team ha inoltrato migliaia di risultati, tra cui decine classificati come critici o ad alta gravità, in centinaia di progetti. Le disclosure responsabili sono state inviate ai maintainer prima della pubblicazione più ampia. L'esercizio ha dimostrato che una revisione sistematica assistita dall'AI può far emergere problemi su scala e velocità prima impraticabili per team esclusivamente umani.

Su questo fronte, il Red Team ha riscontrato che i modelli cinesi open-weight erano molto più affidabili dei modelli americani closed-source, che, pur con permessi cyber e accesso di primo livello, si rifiutavano di rispondere alle richieste del Red Team, una tendenza che gli sviluppatori americani hanno lamentato.

Allo stesso tempo, il flusso di codice generato dall'AI ha creato una nuova pressione di denial-of-service sui maintainer FOSS. Revisionare l'output dell'AI spesso richiede più tempo di quanto ne serva per generarlo. Alcuni progetti open source al di fuori di Bitcoin hanno limitato i tracker delle issue o imposto regole rigorose anti-IA sui contributi semplicemente per restare operativi.

Sul fronte closed source, il vantaggio tradizionale della sicurezza attraverso l'oscurità si sta erodendo. I modelli AI moderni possono leggere, de-offuscare, sondare endpoint e ragionare sul codice ad alta velocità. La differenza pratica tra open e closed source è ormai perlopiù confinata al codice backend che non viene mai condiviso online. Di conseguenza, il codice closed source dipende dalla qualità degli audit professionali, dalla rapidità di distribuzione delle patch e dalla struttura di incentivi che mantiene vigili le persone competenti con accesso.

Bitcoin e l'intero settore crypto stanno esercitando pressioni insolite sul software libero e open source. La combinazione di valore monetario reale a rischio, economia avversaria e analisi su scala AI sta costringendo i modelli software a evolversi. Tornare a sistemi analogici pre-digitali è difficilmente un'opzione per infrastrutture che sostengono la società moderna. È probabile che sopravvivano solo i progetti più sottoposti ad audit, di fronte alla pressione degli hacker assistiti dall'AI e al peso della finanza digital-first.

Questo articolo, "Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives", è apparso per la prima volta su Bitcoin Magazine ed è scritto da Juan Galt.