Bitcoin Magazine: Código abierto vs. código disponible bajo licencia: lo que el fallo de Coldcard revela sobre los incentivos del software de Bitcoin

El código cerrado y el código abierto han dividido a la industria de Bitcoin y del ecosistema cripto en general durante más de una década. Los defensores de Bitcoin han sostenido durante mucho tiempo que la infraestructura financiera del mundo debe construirse en público, afirmando que la transparencia y la auditabilidad no son negociables cuando hay dinero real en juego. Las capas de aplicaciones y las capas heredadas de las finanzas suelen discrepar.

El reciente hackeo de Coldcard, que involucró a un popular hardware wallet de autocustodia en el que los usuarios perdieron más de $100 millones en bitcoin, o más de 1,500 BTC, planteó dudas sobre lo que realmente significa “código abierto”. También sugirió que muchas personas, incluidos algunos bitcoiners serios, están mal informadas sobre la filosofía del software de código abierto y las condiciones bajo las cuales falla.

Los principios y la terminología

El lenguaje en torno al código abierto puede ser confuso. Free and Open Source Software (FOSS) y Free/Libre and Open Source Software (FLOSS) describen software que cumple definiciones formales de libertad del usuario.

La Free Software Foundation (FSF) define el software libre mediante cuatro libertades esenciales:

Libertad 0: La libertad de ejecutar el programa como quieras, para cualquier propósito.

Libertad 1: La libertad de estudiar cómo funciona el programa y modificarlo para que haga tu computación como quieras. El acceso al código fuente es un requisito previo para esto.

Libertad 2: La libertad de redistribuir copias para ayudar a otros.

Libertad 3: La libertad de distribuir copias de tus versiones modificadas a otros. El acceso al código fuente es un requisito previo para esto.

La FSF enfatiza que “free” se refiere a libertad, no a precio, en la conocida frase usada por los defensores de FOSS: “‘free’ as in ‘free speech,’ not as in ‘free beer.’”

La Open Source Definition de la Open Source Initiative añade diez criterios prácticos. Entre ellos se incluyen la redistribución gratuita sin regalías, la disponibilidad del código fuente en la forma preferida para su modificación, el derecho a crear y distribuir obras derivadas, y la ausencia de discriminación contra personas, grupos o ámbitos de actividad, incluido el uso comercial. Una licencia debe cumplir los diez criterios para calificar como código abierto según el estándar de la OSI.

“Source available” o “source viewable” es diferente. El código puede ser legible públicamente mientras la licencia restringe el derecho a venderlo. El firmware de Coldcard, por ejemplo, se publica bajo términos MIT más la Commons Clause. La cláusula elimina específicamente el derecho a “Sell” el software —definido como proporcionarlo a terceros por una tarifa u otra contraprestación en un producto o servicio cuyo valor deriva total o sustancialmente del propio software. En otras palabras, el firmware de Coldcard no podía utilizarse comercialmente.

La propia FAQ de Commons Clause establece la diferencia de forma explícita: “Is this ‘Open Source’? No.” Señala que aplicar la cláusula hace que el software cumpla muchos elementos de la Open Source Definition, pero no todos, y por lo tanto no debería llamarse código abierto.

Estas distinciones importan. Publicar el código fuente crea la posibilidad de inspección. Otorgar el conjunto completo de derechos definido por la Free Software Definition o la Open Source Definition es lo que convierte al software en FOSS o FLOSS. Pero contar con la etiqueta no es el punto. Los críticos argumentan que la libertad comercial en FOSS desbloquea incentivos de terceros para probar y revisar código que, de otro modo, no existirían.

Las cuatro libertades forman el núcleo filosófico del código abierto, pero en la práctica dependen de un supuesto económico: que suficientes personas motivadas realmente examinarán el código. Cuando ese supuesto falla, el resultado se asemeja a una tragedia de los comunes, en la que un recurso compartido se descuida porque los individuos actúan según su propio interés de corto plazo, en lugar del interés de largo plazo del grupo.

Cada persona tiene un incentivo para tomar más, o contribuir menos, de lo que es sostenible, y como resultado el recurso se degrada. Que los incentivos se alineen o no depende de la situación.

Un desarrollador de Bitcoin lo expresó sin rodeos: “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.”

Por lo tanto, el código abierto no crea seguridad por sí mismo. Crea la posibilidad de verificación. Que esa verificación ocurra depende de los incentivos, la habilidad y la atención. Se suele decir que el FOSS histórico se endurece con el tiempo a medida que se descubren, divulgan y parchean vulnerabilidades, creando bases sólidas sobre las que otros construyen. El kernel de Linux es un gran ejemplo de FOSS endurecido; impulsa la gran mayoría de los servidores del mundo, la infraestructura en la nube, los dispositivos Android y los sistemas embebidos, lo que lo convierte en una de las piezas de software más desplegadas de la historia.

El código abierto demostrado por Bitcoin Core

Bitcoin Core, la implementación de referencia de Bitcoin, es otro ejemplo a gran escala de cómo el código abierto funciona en la práctica. El software, que opera detrás de la mayor parte de la infraestructura relacionada con Bitcoin, se publica bajo la licencia MIT. Su proceso de desarrollo es público por diseño.

Cualquiera puede abrir un pull request. La revisión de código es el filtro principal y el punto de entrada recomendado para los nuevos colaboradores. Los revisores usan un vocabulario formal: Concept ACK, que significa reconocimiento y acuerdo con el objetivo; Approach ACK, que significa acuerdo con el objetivo y el método; ACK con un hash de commit específico, que significa que fue probado y aprobado para su fusión; o NACK, que significa desacuerdo acompañado de razonamiento técnico.

Los mantenedores evalúan el consenso entre los colaboradores y los méritos técnicos de un cambio antes de fusionarlo. Los cambios críticos para el consenso enfrentan una barrera aún mayor y por lo general requieren un Bitcoin Improvement Proposal, además de extensas discusiones de varios años en la lista de correo bitcoin-dev y en IRC.

No existe una casta privilegiada de “Bitcoin Core developers”. La confianza se gana mediante competencia demostrada a lo largo del tiempo. Los mantenedores existen por razones prácticas: auditar y fusionar código, gestionar versiones y realizar moderación básica. Pero el trabajo producido es código de código abierto puro que cualquiera puede inspeccionar, compilar, bifurcar o ejecutar. A los desarrolladores cuyos commits logran fusionarse en Bitcoin Core se les llama, en términos generales, Bitcoin Core Contributors.

Calle, un desarrollador veterano de Bitcoin de código abierto, resumió la situación recientemente: “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.”

La financiación de este trabajo proviene en gran parte de estructuras sin fines de lucro y de subvenciones como Brink, OpenSats, Spiral y otras, en lugar de una hoja de ruta tradicional de producto de una empresa. La discusión técnica y el debate tienen lugar públicamente en la lista de correo bitcoin-dev y en el canal de IRC #bitcoin-core-dev en Libera Chat, donde las propuestas son examinadas antes y durante el proceso de pull request. Los issues y pull requests de GitHub suelen incluir historiales de comentarios que se remontan a una década. El resultado es una cultura de desarrollo optimizada para la corrección y la auditabilidad, más que para la velocidad o la rapidez comercial de nuevas funciones.

La economía del código abierto

La mayoría de los usuarios de software de código abierto o source available nunca leen el código por sí mismos. Confían en la suposición de que otros lo están examinando. En el caso de Coldcard, una falla crítica de entropía permaneció en el firmware disponible públicamente durante aproximadamente cinco años antes de ser explotada y, por tanto, descubierta.

El error entró en la base de código durante una importante reescritura en 2021 que también eliminó el código restante derivado de GPL de Trezor, la primera hardware wallet y ahora la segunda más grande en la industria de la autocustodia. La biblioteca en el centro del fallo de entropía, que reemplazó a trezor-crypto, se llama libngu y tuvo un escrutinio externo mínimo, con solo 7 stars y menos de 20 forks en más de 5 años de uso en producción. Compárese con las 512 stars y 212 forks de la biblioteca trezor-crypto, o con los 793 forks y 1.8k stars de la más moderna trezor-firmware. La mera disponibilidad del código fuente no produjo la revisión que importaba, porque otras empresas con fines de lucro y bien financiadas estaban restringidas para usarlo, o eso sostendrían los críticos.

En la práctica, eso hace que las decisiones de licencia sean más que una nota legal al pie: influyen en quién puede participar en la revisión, quién tiene razones para hacerlo y con qué rapidez pueden detectarse fallas en software que asegura fondos reales. Los riesgos son mayores en Bitcoin que en la mayoría de los ámbitos del software. Una falla crítica puede convertirse directamente en fondos líquidos en el mercado abierto. Aunque la primera mitad de los fondos robados de Coldcard todavía se mantiene en unas pocas direcciones y el hacker podría ser capturado algún día, los atacantes que lo imitaron fueron más cuidadosos, y algunos han robado más bitcoin y lo han lavado con éxito, según Galaxy Research. La resistencia a la censura de Bitcoin y su capacidad de transacción inmutable crean tanto un poderoso incentivo para los atacantes como un filtro darwiniano: solo los proyectos que atraen revisión competente de forma continua, y los usuarios y empresas que toman precauciones serias, tienden a sobrevivir a largo plazo.

Las decisiones de licencia moldean esos incentivos, según los defensores de FOSS que criticaron durante años las decisiones de licencia de Coinkite. Las licencias de código abierto puro maximizan el grupo de posibles revisores y bifurcaciones. Las licencias restringidas de “source available” pueden reducir el free-riding comercial, pero también pueden reducir el círculo de personas que tienen tanto el derecho legal como el motivo económico para dedicar atención profunda. En ese sentido, la carga de revisar el código vuelve a recaer sobre la empresa bajo una licencia restrictiva, acercándola más al código cerrado que al abierto.

Cómo la IA cambia el desarrollo de código abierto y código cerrado

La inteligencia artificial también está cambiando el equilibrio entre FOSS y el código cerrado.

Después del incidente de Coldcard, un esfuerzo voluntario conocido como Bitcoin Red Team —liderado por desarrolladores entre los que se incluyen Calle y Rob Hamilton de AnchorWatch, y con el apoyo de OpenSats— utilizó modelos de IA de frontera para examinar cientos de repositorios de Bitcoin de código abierto. En un período intensivo, el equipo presentó miles de hallazgos, incluidos decenas clasificados como críticos o de alta severidad, en cientos de proyectos. Se realizaron divulgaciones responsables a los mantenedores antes de una publicación más amplia. El ejercicio demostró que la revisión sistemática asistida por IA puede sacar a la luz problemas a una escala y velocidad que antes eran poco prácticas para equipos puramente humanos.

En este frente, vale la pena señalar que el Red Team encontró que los modelos chinos de peso abierto eran mucho más fiables que los modelos estadounidenses de código cerrado, que, incluso con permisos de ciberseguridad y acceso de primera línea, se negaron a responder a las consultas del Red Team, una tendencia que los desarrolladores estadounidenses lamentaron.

Al mismo tiempo, la avalancha de código generado por IA ha creado una nueva presión de denegación de servicio sobre los mantenedores de FOSS. Revisar la salida de la IA suele llevar más tiempo que generarla. Algunos proyectos de código abierto fuera de Bitcoin han restringido los issue trackers o impuesto reglas estrictas contra contribuciones de IA simplemente para seguir siendo funcionales.

En el lado del código cerrado, la ventaja tradicional de la seguridad por oscuridad se está erosionando. Los modelos modernos de IA pueden leer, desofuscar, sondear endpoints y razonar sobre código a gran velocidad. La diferencia práctica entre código abierto y cerrado ahora se limita en gran medida al código de backend que nunca se comparte en línea. Como resultado, el código cerrado depende de la calidad de las auditorías profesionales, de la velocidad de despliegue de parches y de la estructura de incentivos que mantiene atentos a los expertos con acceso.

Bitcoin y la industria cripto en general están ejerciendo presiones poco comunes sobre el software libre y de código abierto. La combinación de valor monetario real en riesgo, economía adversarial y análisis a escala de IA está forzando a evolucionar los modelos de software. Volver a sistemas analógicos pre-digitales difícilmente es una opción para una infraestructura que sostiene la sociedad moderna. Solo los proyectos más auditados probablemente sobrevivan a las presiones de los hackers asistidos por IA y al peso de las finanzas centradas en lo digital.

Esta publicación, “Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives”, apareció por primera vez en Bitcoin Magazine y fue लिखritten by Juan Galt.