Mesa de laboratorio en penumbra: un monedero físico abierto, un aparato metálico con un indicador en ámbar y un montón de sobres lacrados en rojo, iluminados por una lámpara; al fondo, matraces y un microscopio.
Ilustración propia generada con IA.

Dashjr publica nueve avisos sobre el generador de COLDCARD: qué se le escapó a cada revisión y 45,9 BTC que sí se han movido

Equipo NodeWitness 14 min de lectura

El 9 de noviembre, Luke Dashjr sacó a la luz nueve observaciones sobre el generador de números aleatorios de COLDCARD y negó que solo una inteligencia artificial pudiera haber encontrado problemas en ese código. El debate llega meses después de las revisiones que no vieron el fallo de las semillas. En la cadena, 45,9 bitcoin que no se habían movido desde julio salieron el 28 de octubre de una de las direcciones confirmadas del robo.

Luke Dashjr publicó el 9 de noviembre a las 17:54 (hora de Madrid) un hilo con nueve observaciones sobre el generador de números aleatorios de COLDCARD [1]. Dice que ya se las había comunicado a Coinkite en privado y que no tiene ni idea de si la empresa las ha corregido. Aclara, además, que no afirma que todas puedan usarse para atacar un dispositivo, ni siquiera que sean fallos con seguridad [1].

El motivo de hacerlo público, escribe, es que oye a NVK «pretendiendo que los humanos no pudieron encontrar el defecto de Coldcard» [1]. En el segundo mensaje del hilo va más lejos: «la afirmación de que solo una “IA genial” podría encontrar problemas con el generador de números aleatorios es una mentira descarada» [2]. Y precisa el alcance: es lo que vio de un vistazo, no una auditoría a fondo [2].

Esa frase responde a un mensaje de NVK, cofundador de Coinkite, publicado una hora antes, a las 16:50 (Madrid). Tras citar al menos quince revisiones o investigaciones externas, dos revisiones de pago —una del Mk4 en 2022 y, según él, otra del modelo Q en 2024— y 85 hallazgos candidatos de una revisión con el OpenAI Cybersecurity Harness de Rob Ham, concluyó: «La incómoda verdad es que hizo falta un modelo de IA nuevo para encontrar lo que los humanos no pudieron» [3]. El día anterior había escrito que «hizo falta kimi-k3 una semana» [4].

El fallo de las semillas, y cómo migrar si te afecta, ya lo contamos en nuestro análisis del error de entropía. Lo nuevo de hoy es otra capa: qué pudo ver cada revisión, qué quedó fuera, y qué ha ocurrido con los fondos robados desde nuestra última pieza sobre la tercera oleada.

Lo que Dashjr apunta, punto por punto

Los nueve avisos no describen el error de 2021 que dejó semillas débiles. Apuntan al código del generador que quedó en uso despues del parche de finales de julio [1][5]. En resumen, y en su propia formulación [5]:

  1. Un TODO en la inicialización pregunta si hay que descartar la primera muestra del chip STM32; al menos algunos modelos parecen exigirlo.
  2. El driver no comprueba los bits de error de semilla (SEIS) ni de reloj (CEIS).
  3. El manual del STM32 pide algún posprocesado, no especificado, para usos criptográficos.
  4. La función random_buffer detecta salidas repetidas; las llamadas directas a rng_get, no.
  5. Si salta esa comprobación, es que rng_get_or_fault no vio el error, así que esa rutina no puede darse por segura hasta demostrar que la otra es redundante.
  6. Aunque el STM32 devolviera un resultado determinista, cabría esperar que la aleatoriedad de los elementos seguros bastara para mantener 256 bits; se pregunta por qué no fue así.
  7. Al no haberse usado antes, el código habilitado en el parche es, en la práctica, un generador nuevo y debería probarse como tal.
  8. El arreglo impide compilar el generador antiguo solo en tiempo de construcción; echa en falta una aserción en tiempo de ejecución.
  9. Si rng_get se llama desde un contexto que no maneja bien las excepciones de Python y el generador agota el tiempo de espera, mp_raise_OSError podría provocar un comportamiento indefinido, un cuelgue o, en el arranque, el riesgo de dejar inservible un dispositivo lento.

Qué se le escapó a cada revisión

El 20 de agosto, Coinkite publicó el firmware 5.6.1 para Mk4 y Mk5, y el 1.5.1Q para el modelo Q [6][7]. La versión estándar recomendada hoy es la 5.6.3 y la 1.5.3Q, del 30 de septiembre [8][9]. Instalarlas no repara una semilla antigua.

La revisión de pago del Mk4, en 2022. El historial público de divulgaciones de Coinkite recoge una auditoría profesional, del 1 al 14 de marzo de 2022, a cargo de Lazy Ninja: miró la derivación del PIN, los límites de intentos, el cortafuegos del microcontrolador y la generación de números aleatorios, antes del primer firmware público del Mk4 [10]. Una de las recomendaciones que sí se adoptó fue sembrar el generador con entropía autenticada de los dos elementos seguros, ya en la 5.0.0 [10]. El fallo de las semillas, sin embargo, no era un diseño débil a propósito: era un error de enlace por el que rng_get() acababa resolviendo al generador de software Yasmarang, y no a la ruta de hardware [11][12]. Coinkite ha escrito que el flag de desactivación «parecía correcto» y que el defecto vivía en el límite entre dos submódulos, no en la lógica de bitcoin que suelen revisar las auditorías [11]. Esa revisión de 2022, centrada en el Mk4 y anterior a su lanzamiento, no lo detuvo. El error estaba ya en el código desde marzo de 2021 [11][12].

La revisión del modelo Q en 2024. NVK la cita como la segunda revisión de pago anterior al incidente [3]. En la cronología pública de Coinkite, actualizada el 20 de agosto de 2026, no aparece una auditoría profesional del Q en 2024: la única entrada clasificada como tal sigue siendo la del Mk4 en 2022 [10]. Hasta que Coinkite la documente, la dejamos atribuida a NVK, no como un hecho contrastado en ese registro.

La revisión con IA de mayo y junio de 2026. El mismo historial describe una revisión empresarial con IA, del 1 de mayo al 26 de junio, que produjo 85 hallazgos candidatos: 8 altos, 37 medios, 20 bajos y 20 informativos [10]. Coinkite dice que los revisó a mano, que cerró el trabajo el 26 de junio y que de ahí salieron varios arreglos, entre ellos un camino en Delta Mode [10]. NVK añade que esa revisión, que identifica como el OpenAI Cybersecurity Harness de Rob Ham, no incluyó el defecto de generación de semillas [3]. Encaja con lo que Coinkite escribió el 4 de agosto: la revisión asistida por IA de las semanas anteriores al ataque no lo detectó [11].

Las pruebas con modelos posteriores al robo. En ese mismo texto de agosto, Coinkite afirma que, ya ocurrido el incidente, probó el código con Kimi K3, Claude Fable y Codex 5.6, y que ninguno de los tres lo encontró [11]. Esa frase no encaja del todo con lo que NVK ha dicho en noviembre: que hizo falta kimi-k3 una semana, y que hizo falta un modelo nuevo para ver lo que los humanos no vieron [3][4]. Recogemos las dos versiones; no las reconciliamos.

Los avisos de Dashjr y el firmware de agosto. Varios de los puntos del hilo sí tienen respuesta en la 5.6.1. El changelog y el comunicado de Coinkite documentan la detección de los flags de error de semilla del STM32 (SEIS y SECS), reintentos limitados, el descarte de las 12 palabras siguientes tras un error recuperable, y una prueba de arranque que comprueba que rng_get() entra en la ruta de hardware y detiene el dispositivo si no es así [6][7]. Tambien se pasó a muestrear SE1 y SE2 de forma directa en cada semilla nueva, no solo al arrancar [7].

Otras observaciones siguen abiertas en el código público consultado el 10 de noviembre. La comprobación de salidas repetidas continúa en random_buffer, no en cada llamada directa a rng_get [13]. Los flags de error de reloj (CEIS/CECS) se ignoran de forma deliberada: un comentario en el fuente cita el manual RM0432 y las erratas de ST, según los cuales un error de reloj no invalida los números generados cuando el dato está listo; un reloj muerto, dice el mismo comentario, acaba fallando por tiempo de espera [13]. Dashjr pidió una aserción en tiempo de ejecución; Coinkite puso una prueba en el arranque [6][7][13]. Y él mismo advierte de que no hizo una auditoría completa [2].

Dónde están hoy los fondos que sí podemos ver

Las cifras totales del caso nunca han sido una sola. TRM Labs habló de 1.816 BTC a principios de agosto; Galaxy Research, el 7 de septiembre, situaba su total publicado en torno a 1.806 BTC si se contaba una bóveda aún sin confirmar, y decía que el 82 % seguía en las direcciones originales de los atacantes [14][15]. Esas cuentas, con su método y su fecha, están en nuestra cobertura de la escalada y en la pieza de la tercera oleada.

Hoy no pretendemos rehacer ese total. Lo que sí hemos hecho es volver a leer, a la altura de nuestro nodo, las cinco direcciones que los rastreadores públicos dan por confirmadas [16][17]. El 10 de noviembre a las 13:06 (hora de Madrid), nuestro nodo estaba sincronizado en el bloque 975.299 [18]. A esa misma altura de la cadena:

  • bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r sigue con 562,02148293 BTC y no ha gastado nunca [16][19].
  • bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 sigue con 398,47576957 BTC y no ha gastado nunca [16][19].
  • bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q sigue con 89,62329890 BTC y no ha gastado nunca [16][19].
  • bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0, el colector que reenvió los 562 BTC el 30 de julio, mantiene 32,45061090 BTC; no hay gastos nuevos [16][17][19].
  • bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75, que el 31 de julio recibió 45,90251994 BTC y que en octubre aún no había gastado, casi se vació el 28 de octubre [16][19].

Esa última salida es lo que no estaba en nuestra pieza del 20 de octubre, que citaba el rastreador de Bitquery a 19 de octubre: último movimiento el 2 de octubre, y la dirección mayor, de 562,02 BTC, sin tocar [15][16]. El 28 de octubre a las 22:57 (hora de Madrid), en el bloque 973.601, esa dirección gastó 45,90251994 BTC en la transacción 4882d3f6eb054e78b81e45b1d6e7edbcc962c15750523da90e93b9948ed91a76: 154 entradas, 196 salidas, una comisión de 36.734 sats [20]. Solo una de las entradas sale de esa dirección; el resto, y una larga lista de importes repetidos, encajan con un CoinJoin. Quedaron 0,00003000 BTC de polvo, sin barrer [19].

Dos horas y media después, a la 01:32 del 29 de octubre (Madrid), el mayor destino de esa operación —40,73690951 BTC en bc1qu2cdpatut3fglsvtzastsft8ajk6pya0u6scu6— volvió a gastarse por completo en el bloque 973.617, en otra transacción de 222 entradas y 267 salidas [21].

En las cinco direcciones confirmadas quedan 1.082,57119230 BTC. Casi todo ese saldo sigue en las tres mayores, que no se han tocado. No es el total robado, ni una actualización del 82 % de Galaxy: es lo que se ve, hoy, en ese grupo concreto de direcciones [18][19].

Lo que no cambia si tienes una COLDCARD

Ni el hilo de Dashjr ni este movimiento de 45,9 BTC cambian el diagnóstico de tu semilla. Eso depende del modelo y del firmware con el que se creó, no de lo que hagan los atacantes con lo ya robado, ni de si el firmware actual cierra o no cada uno de los nueve puntos. Si está en el rango afectado, el plan sigue siendo el de nuestro análisis del fallo: semilla nueva, firmware actual verificado, prueba con poco y después el resto.

La demanda colectiva presentada en Ontario, que todavía no está certificada, tampoco sustituye esa migración. Qué alega y qué conviene guardar está en nuestra pieza sobre la demanda.

Fuentes

Tipo de fuente entre corchetes. Horas en UTC cuando la fuente las da así; en el cuerpo, convertidas a hora de Madrid (UTC+1). Consultadas el 10 de noviembre de 2026.

  1. Luke Dashjr, mensaje en X, 16:54:36 UTC del 9 de noviembre de 2026 (17:54 Madrid). Aviso privado previo a Coinkite; no sabe si está corregido; no afirma que todos los puntos sean fallos explotables. (Primaria, autor del hilo)
  2. Luke Dashjr, mensaje en X, 16:54:36 UTC del 9 de noviembre de 2026. «the claim that only a "genius AI" could find issues with the RNG is a blatant lie»; alcance de un vistazo, no una auditoría a fondo. (Primaria, autor del hilo)
  3. NVK, mensaje en X, 15:50:42 UTC del 9 de noviembre de 2026 (16:50 Madrid). Texto largo: quince revisiones, dos de pago (Mk4 2022 y una del Q en 2024), 85 hallazgos del OpenAI Cybersecurity Harness de Rob Ham, y «It took a new Ai model to find what humans couldn't». (Primaria, cofundador de Coinkite)
  4. NVK, mensaje en X, 16:39:21 UTC del 8 de noviembre de 2026 (17:39 Madrid). «It took kimi-k3 1 week». (Primaria, cofundador de Coinkite)
  5. Luke Dashjr, hilo en X, mensajes 1 a 9, 16:54 UTC del 9 de noviembre de 2026. Los nueve puntos, incluido el archivo de rng_init en GitHub. (Primaria, autor del hilo)
  6. Coinkite, COLDCARD Security Update: Seed Generation, Transaction Integrity, and Data Isolation, 20 de agosto de 2026. Firmware 5.6.1 y 1.5.1Q; comprobación de error de semilla, descarte de 12 palabras, prueba de arranque; el aviso no repara semillas antiguas. (Primaria, empresa)
  7. Coinkite, History-Mk.md, sección 5.6.1, 20 de agosto de 2026. Changelog: SEIS/SECS, prueba de rng_get(), muestreo directo de SE1 y SE2, Hash_DRBG. (Primaria, repositorio de firmware)
  8. Coinkite, Current COLDCARD Security Status, verificado el 1 de octubre de 2026; consultado el 10 de noviembre. Versión estándar 5.6.3 / 1.5.3Q. (Primaria, empresa)
  9. Coinkite, COLDCARD Firmware 5.6.3 & 1.5.3Q: Codex32 and Shamir Backups y ChangeLog.md, 30 de septiembre de 2026. (Primaria, empresa)
  10. Coinkite, Security Disclosure History, actualizado el 20 de agosto de 2026; consultado el 10 de noviembre. Auditoría de Lazy Ninja (marzo de 2022); revisión con IA del 1 de mayo al 26 de junio de 2026 (85 hallazgos); el incidente del 30 de julio atribuido a la investigación pública; sin auditoría profesional del Q en 2024 en esa cronología. (Primaria, empresa)
  11. Coinkite, Adding to the Public Record on Our Ongoing Investigation, 4 de agosto de 2026 (modificado el 30 de agosto). Error de enlace Yasmarang; la revisión con IA previa no lo detectó; Kimi K3, Claude Fable y Codex 5.6 tampoco, según ese texto. (Primaria, empresa)
  12. Coinkite, aviso y contexto técnico del fallo de entropía, 30–31 de julio de 2026, y technical backgrounder. (Primaria, empresa)
  13. Repositorio de firmware de COLDCARD, stm32/COLDCARD_MK4/rng.c en la rama master, consultado el 10 de noviembre de 2026. Descarte de palabras de calentamiento en rng_selftest; flags de reloj ignorados a propósito; comprobación de repetición solo en random_buffer. (Primaria, código)
  14. TRM Labs, cifra de 1.816 BTC recogida en nuestra cobertura de la escalada, 6 de agosto de 2026. (Secundaria, citada en pieza propia; la cifra original es de TRM)
  15. Galaxy Research / CoinDesk, 7 de septiembre de 2026, y Bitquery a 19 de octubre, según nuestra pieza de la tercera oleada. ~1.806 BTC, 82 % sin mover el 7 de septiembre; último movimiento el 2 de octubre en la consulta de octubre. (Secundaria vía pieza propia)
  16. Bitquery, Coldcard Hack Tracker Live, instantánea pública del 28 de octubre de 2026, 08:30 UTC, bloque 973.522: las cinco direcciones confirmadas y 45,90254994 BTC aún sin gastar en bc1qtfrwa…. (Secundaria, rastreador; la página no respondió el 10 de noviembre; la instantánea se usa solo para identificar direcciones y el estado anterior)
  17. PublicAML, Coldcard hack: where the stolen bitcoin is now. Recorrido de las oleadas del 30 y 31 de julio y del colector bc1qnk4zh…. (Secundaria, rastreador público)
  18. NodeWitness, /api/node/status, 10 de noviembre de 2026, 13:06 hora de Madrid: nodo primario sincronizado, bloque 975.299. (Primaria, nodo propio)
  19. Consulta propia de saldos y gastos de las cinco direcciones confirmadas, y del destino de 40,73690951 BTC, a la altura del bloque 975.299, el 10 de noviembre de 2026. (Primaria, lectura on-chain)
  20. Transacción 4882d3f6eb054e78…8ed91a76, bloque 973.601, 21:57 UTC del 28 de octubre de 2026 (22:57 Madrid): 45,90251994 BTC desde bc1qtfrwa…; 154 entradas, 196 salidas, comisión 36.734 sats. (Primaria, cadena)
  21. Transacción 24f3619f057885be…3fc8b144, bloque 973.617, 00:32 UTC del 29 de octubre de 2026 (01:32 Madrid): gasto íntegro de 40,73690951 BTC desde bc1qu2cdp…; 222 entradas, 267 salidas. (Primaria, cadena)
  22. The Defiant, Luke Dashjr Publishes Nine Coldcard RNG Concerns, 9 de noviembre de 2026. (Secundaria, prensa)
  23. CriptoNoticias, ¿La IA descubrió los fallos de Coldcard? Luke Dashjr cuestiona esa versión, Cristina Cedeño, 9 de noviembre de 2026. (Secundaria, prensa)

Más en Privacidad y autocustodia

Ver los 34 artículos de Privacidad y autocustodia →

Última actualización: 10 de noviembre de 2026