Coldcard: la caja fuerte que fabricaba llaves predecibles

5 de agosto de 2026 · 68 min de lectura

Durante años, la respuesta estándar a «¿cómo guardo mis bitcoin de forma segura?» fue siempre la misma: sácalos del exchange y ponlos en una billetera fría, un dispositivo dedicado que guarda las llaves fuera de internet. El consejo tiene hasta lema propio, repetido en foros y conferencias desde que Andreas Antonopoulos lo puso en circulación hacia 2016: not your keys, not your coins. Si las llaves no las tienes tú, las monedas no son tuyas: son la promesa de que alguien te las devolverá cuando se las pidas. Eso lo recomendaba todo el mundo, y sigue siendo un buen consejo.

Lo que no recomendaba todo el mundo era una marca concreta, porque hay muchas y muy distintas. Las dos grandes, con más del setenta por ciento del mercado entre ambas, son Ledger y Trezor. Detrás hay un ecosistema entero: BitBox, Blockstream Jade, Foundation Passport, Keystone, Tangem, SeedSigner para quien prefiere montársela él, Bitkey de Block, y varias más.

Y luego estaba la recomendación de otro grupo: los que se leían el firmware, desconfiaban de las aplicaciones bonitas y querían un dispositivo que hiciera una sola cosa. Ese grupo, pequeño pero muy influyente, apuntaba casi siempre en la misma dirección: una cajita negra fabricada en Canadá llamada Coldcard. No era la más vendida ni de lejos. Era la que recomendaba quien más sabía, que es una cosa distinta y, para lo que viene después, más importante.

El 30 de julio de 2026, entre la 01:10 y la 01:51 UTC, alguien vació 1.196 direcciones de bitcoin. Cuarenta y un minutos, repartidos en nueve bloques. 1.082,65 BTC, unos 70 millones de dólares al cambio de aquel día.

Si seguiste el caso esos días, quizá recuerdes una cifra menor para esa misma madrugada: unos 594 BTC. Fue el primer recuento público, del director de AnchorWatch, y era lo que se veía a simple vista en tres bloques seguidos. Galaxy Research llegó a los 1.082,65 al encontrar una huella común en las transacciones, que le permitió atribuir al mismo episodio direcciones que antes parecían sueltas. El primer cálculo no estaba mal: solo veía una parte.

Seis días después, el recuento de Galaxy Research iba por unos 1.816 BTC sacados de más de 5.200 direcciones, alrededor de 116 millones de dólares. Las cifras que verás en cada medio bailan entre los 100 y los 130 millones, y no es que ninguno se equivoque: el ataque sigue vivo mientras escribo esto, y cada recuento es una foto de un momento distinto.

No es el mayor robo de la historia de bitcoin. No se acerca: en Mt. Gox desaparecieron unos 850.000 BTC. Pero sí es el primero de su tipo, y por eso importa tanto. Hasta ahora, los grandes robos habían sido siempre a un tercero: un exchange, un custodio, una empresa que guardaba el dinero de mucha gente en el mismo sitio. Esta vez falló el dispositivo que se compra precisamente para no depender de ningún tercero.

Conviene decir, eso sí, que el fallo en sí no es nuevo, aunque casi nadie lo sepa. En diciembre de 2020 alguien vació el pool de minería chino LuBian de 127.426 BTC, y lo hizo por exactamente el mismo motivo: sus claves se generaban con 32 bits de entropía, así que bastaba con probarlas todas. Nadie se enteró hasta que Arkham lo destapó en 2025, cinco años después. En número de bitcoin no llega a Mt. Gox, como vas a ver enseguida; en dinero del día en que ocurrió sí lo supera, y por mucho. Y no es el único precedente: en 2023, el fallo conocido como Milk Sad dejó las semillas de una herramienta muy usada entre desarrolladores confinadas también a 32 bits, por sembrar su generador con el reloj del sistema. Lo nuevo de Coldcard no es la clase de fallo: es dónde estaba.

Cifras en BTC del momento de cada robo, y la escala es lineal: la barra de Coldcard mide de verdad lo que se ve. De Mt. Gox se recuperaron después unos 200.000 y el recuento de Coldcard todavía sube. En número de bitcoin el mayor es Mt. Gox; en dinero del día en que ocurrió, LuBian, con 3.500 millones de dólares de 2020 frente a los 450 millones que valían los de Mt. Gox en 2014.

Jonathan Goodman, un empresario canadiense, perdió 18,25 bitcoin, alrededor de 1,6 millones de dólares canadienses. Su Coldcard estaba en la caja de seguridad de un banco. Lo escribió así: «quizá lo más duro de todo esto es que yo lo hice todo bien. Nunca compartí mi frase semilla con nadie. Mis dispositivos nunca tocaron internet».

Tenía razón en las tres cosas. Y daba exactamente igual, porque el fallo estaba por encima de todo lo que él podía controlar.

Falló en el único punto donde no podía permitirse fallar.

Si prefieres verlo antes de leerlo, resumí lo esencial en seis minutos. El artículo va mucho más a fondo, pero el vídeo cubre lo que hay que saber si tienes una Coldcard ahora mismo.

Tu billetera no se crea: ya existía

Empecemos por lo que casi nadie explica, porque cambia la forma de entender todo lo demás.

Cuando estrenas una billetera de bitcoin no estás creando nada. No hay ningún alta, ningún registro, ningún servidor que apunte que esa dirección es tuya. Las direcciones no son cuentas que alguien abra: son el resultado de aplicar una fórmula a un número. Tu dispositivo no inventa una dirección, calcula una y se calla el número del que salió.

Conviene ser exacto aquí, porque es un matiz bonito. El conjunto de claves privadas posibles no lo inventó Bitcoin: es un rango de números definido por una curva matemática, la secp256k1, que se estandarizó en el año 2000, ocho años antes de que existiera Bitcoin. Ese espacio ya estaba ahí. Lo que sí ha ido cambiando con los años es el formato de las direcciones (las que empiezan por 1, por 3, por bc1…), que se fueron añadiendo con actualizaciones del protocolo. Pero en ningún caso se crea nada al generar una billetera: para cada formato, todas sus direcciones quedan determinadas por la matemática en el mismo instante en que se define el formato. Nadie las da de alta. Se calculan.

Cuántas son: 1,46 × 10⁴⁸. Un número de cuarenta y nueve cifras. En toda la historia de Bitcoin se han llegado a usar unos 1.500 millones de direcciones, y de esas solo unos 58 millones tienen algún saldo hoy. Ponlo en proporción: por cada dirección con bitcoin dentro hay 2,5 × 10⁴⁰ vacías, que es un 25 seguido de treinta y nueve ceros.

La rejilla es simbólica: la proporción real, una entre 2,5 × 10⁴⁰, no se puede dibujar en una pantalla.

Esa es la razón de que no exista ningún registro de cuentas, ningún funcionario comprobando que no se repitan, ningún trámite para darte de alta. No hace falta. El mapa ya está dibujado entero, y es tan grande que casi ningún punto de él ha sido pisado jamás por nadie.

Y por eso el fallo de Coldcard es tan grave como es. El dispositivo no tenía que inventar nada: tenía que elegir un punto al azar de ese mapa gigantesco. Lo que ocurrió es que, sin que nadie se diera cuenta, llevaba cinco años eligiendo siempre dentro de la misma esquina diminuta.

El dibujo no está a escala, y no puede estarlo. El mapa entero son 2¹⁶⁰ puntos y la esquina de Coldcard eran 2⁴⁰: unas 10³⁶ veces más pequeña que el cuadrado rojo que la representa. Los puntos sueltos son las direcciones usadas en toda la historia de Bitcoin, unos 1.500 millones.

Los bitcoins no se mueven: se firman

Se omite la comisión de minería, que es la pequeña diferencia entre lo que entra y lo que sale y se descuenta del cambio.

Segunda idea que conviene tener clara, porque explica por qué el robo fue técnicamente impecable.

No existen monedas de bitcoin. No hay ningún objeto digital que viaje de un sitio a otro. Lo que hay es un registro público con una lista de salidas sin gastar: apuntes que dicen «esta cantidad está bloqueada de forma que solo puede desbloquearla quien tenga la llave correspondiente a tal clave pública».

Cuando haces una transferencia no se mueve nada. Se escribe un apunte nuevo que dice: «estas salidas quedan gastadas, y a cambio se crean estas otras, bloqueadas a nombre de otro». Y se adjunta una firma. Es más parecido a un registro de la propiedad (donde se tacha una línea y se escribe otra debajo) que a un camión blindado. Nada viaja.

Lo que la red comprueba tampoco es lo que la gente imagina. No comprueba quién eres, ni si el dinero es tuyo, ni si estás siendo coaccionado. Comprueba una sola cosa: que la firma adjunta encaja matemáticamente con la clave pública que bloqueaba esa salida. Si encaja, la transacción es válida. Punto.

Ahí está la clave de todo lo que pasó el 30 de julio. El atacante no forzó nada. No rompió la criptografía, no explotó la red, no falsificó una firma. Presentó firmas perfectamente correctas, porque tenía las llaves correctas. Desde el punto de vista de Bitcoin, aquello no fue un robo: fue gente moviendo su propio dinero. El protocolo no tiene ningún concepto de «dueño legítimo» más allá de «quien puede firmar».

Y de aquí sale la frase que resume por qué una hardware wallet importa tanto: tus bitcoins nunca estuvieron dentro del dispositivo. Lo que estaba dentro era la capacidad de firmar. Si esa capacidad la tiene alguien más, la tiene igual de legítimamente que tú.

El ladrón no va detrás de tus palabras

Casi todo el mundo se imagina el ataque como alguien probando palabras: «abandon, ability, able…» hasta dar con las doce tuyas. No funciona así en absoluto, y entender por qué aclara todo lo demás.

Las palabras no son el secreto. Son la etiqueta del secreto. La cadena real, definida en el estándar BIP-39, va así:

1. Se genera un número aleatorio. El estándar admite varios tamaños: con 128 bits salen doce palabras y con 256, veinticuatro, y Coldcard ofrece las dos. Ese número, y solo ese, es el secreto. Fíjate en que el estándar no dice quién lo genera, y ese detalle acabaría siendo el centro de todo: puede generarlo el propio dispositivo, o puedes aportarlo tú tirando un dado. En las Coldcard afectadas lo generaba el dispositivo.
2. Le calcula una pequeña suma de verificación, parte el resultado en grupos de once bits, y cada grupo elige una palabra de una lista de 2.048. De ahí salen las palabras. No añaden nada: son ese mismo número en otra codificación, igual que el hexadecimal o el base64. Si escribieras ese mismo número en hexadecimal obtendrías exactamente la misma billetera. Las palabras existen porque una persona copia mal 32 caracteres hexadecimales y copia bien doce palabras que además llevan verificación.
3. Las palabras, junto con la passphrase si la hay, pasan por una función lenta a propósito (PBKDF2, 2.048 vueltas de HMAC-SHA512) y producen una semilla de 512 bits.
4. De esa semilla salen, por derivación, todas tus claves privadas.
5. De cada clave privada sale una clave pública, y de cada clave pública salen varias direcciones: una por cada formato que existe, las que empiezan por 1, por 3, por bc1q y por bc1p. No son billeteras distintas, es la misma llave escrita de varias maneras, y por eso un atacante las comprueba todas.

Fíjate en lo que tienen en común esos cinco pasos: cada uno se calcula del anterior sin ninguna incógnita. Los dos últimos, además, no se pueden deshacer, y por motivos distintos: de la clave privada a la pública no hay vuelta por el problema del logaritmo discreto en curva elíptica, y de la clave pública a la dirección no la hay en los formatos que pasan por dos funciones hash (SHA-256 y luego RIPEMD-160), que son la mayoría. La excepción son las direcciones de taproot, las bc1p, que llevan dentro la propia clave pública a la vista: ahí no hay ningún hash que deshacer. Los dos primeros sí son reversibles: el número y las palabras son literalmente lo mismo escrito de dos formas. Y lo que de verdad importa es esto: quien tiene el número del paso uno lo tiene absolutamente todo, sin preguntarle nada a nadie.

Por eso el atacante nunca tuvo que adivinar una sola palabra. Lo que hizo fue reproducir en su computadora los números del paso uno que aquel generador defectuoso era capaz de producir, que eran pocos, y de cada número calcular sus palabras, que es una operación de un solo paso y sin ninguna incógnita. De cada uno derivó direcciones y las comparó con el registro público de Bitcoin. Cuando una coincidía con una que tenía saldo, ya tenía la clave privada correspondiente y podía firmar.

Las cifras son las de las Coldcard Mk2 y Mk3, con 40 bits de entropía: 2⁴⁰ son unos 1,1 billones de números, y recorrerlos todos a mil millones por segundo lleva unos dieciocho minutos. En las Mk4, Mk5 y Q, con 72 bits, la lista es mucho mayor y el ataque ya no es de aficionado.

Hay un detalle más que conviene entender, porque vuelve más adelante. En los formatos con hash, que son los que importan aquí, la dirección es un hash de la clave pública, no la clave pública. Y un hash no se puede deshacer. Mientras no gastes desde esa dirección, el mundo ve la dirección pero no ve la clave pública que hay detrás. En el momento en que gastas, la firma lleva la clave pública dentro y esta queda registrada para siempre.

Eso significa que una dirección sin estrenar está algo más protegida que una que ya ha gastado. En este ataque daba igual, porque el atacante generaba candidatos desde el principio de la cadena y podía calcular tanto las claves públicas como las direcciones. Pero recuerda el detalle: es la pieza que hace peligrosa a la multifirma.

Una semilla no es una clave: es la raíz de muchas

Aquí hay algo que confunde a casi todo el mundo, y con razón, porque los nombres no ayudan. Semilla, clave privada y dirección suenan a lo mismo y no lo son. Y sobre todo: no van de una en una.

Una billetera no tiene una clave privada. Tiene una cantidad que a efectos prácticos es infinita. Lo que sí es único es la semilla, y de ella salen todas las demás por un procedimiento definido en el estándar BIP-32: se aplica una función a la semilla y se obtiene una clave hija, y a esa se le aplica otra vez y se obtiene otra, y así en forma de árbol. De ahí el nombre técnico, billeteras deterministas jerárquicas.

Determinista significa que el árbol siempre sale igual. Con la misma semilla obtienes exactamente las mismas claves, en el mismo orden, en cualquier programa y en cualquier dispositivo. Por eso apuntar doce palabras basta para recuperarlo todo: no estás guardando tus claves, estás guardando la instrucción para volver a fabricarlas.

¿Y para qué quiere nadie miles de direcciones? Por privacidad, y es más importante de lo que parece. Si cobraras siempre en la misma dirección, cualquiera que te hubiera pagado una vez podría mirar el registro público y ver tu saldo completo, cada pago que recibes y cuándo. Usar una dirección nueva cada vez rompe esa cadena. No es paranoia: es la diferencia entre que tu jefe vea tu nómina y que vea tu patrimonio entero.

Ordenado, entonces: una semilla → un árbol de claves privadas → una clave pública por cada una → y de cada clave pública, una dirección por cada formato. Y volviendo a lo de antes, la semilla sale del número aleatorio. Todo el edificio se apoya en ese número, y todo lo demás es cálculo.

Qué abre cada pieza si te la roban

Con la cadena entera delante ya se puede responder a algo que casi nunca se explica bien: no todas las piezas valen lo mismo para quien te las roba. Y una de ellas se comporta justo al revés de lo que la gente cree.

El número o las doce palabras. Son lo mismo, así que abren lo mismo: la semilla, el árbol entero y todas las direcciones. Es lo que les pasó a las víctimas de Coldcard, con el matiz de que ahí nadie robó ningún papel: el número se reconstruyó.

La semilla. Aquí está la asimetría interesante. La semilla son los 512 bits que salen del paso anterior, y para cuando existe, la passphrase ya está dentro de ella. Quien te saque esos bytes del chip abre tu billetera real y firma perfectamente, sin saber tus palabras y sin poder reconstruirlas. Dicho de otro modo: la passphrase te protege del robo de las palabras, no del robo de la semilla. Retén esto, porque más adelante importa: en el caso de Coldcard el atacante reconstruyó el número, que está antes de ese cruce, y por eso ahí la passphrase sí cambió las cosas.

La clave pública extendida, la xpub. Con ella se ve todo y no se puede gastar nada. Es vigilancia, no robo: cada dirección tuya pasada y futura, cada movimiento y tu saldo exacto, para siempre. Mucha gente la comparte sin pensarlo, con un servicio de facturación o con su contable, porque «no se puede robar con ella». Es cierto, y sigue siendo tu patrimonio entero convertido en información.

Una clave privada suelta. Es la pieza mejor aislada de todo el sistema: si te la roban, abre su dirección y ninguna más. Ni la de al lado ni la de arriba. Le falta el chain code, la otra mitad que hace falta para derivar, y sin él no se sube ni se baja por el árbol.

Y la passphrase sola: nada. Sin las palabras no genera ningún árbol. Por eso tiene sentido guardarlas en sitios distintos: son dos factores de verdad, no dos copias de lo mismo.

Qué es la entropía, y por qué se llama así

La palabra la inventó Rudolf Clausius en 1865, y la eligió con cuidado. La construyó sobre el griego ἐντροπία, que viene a significar transformación o giro, y la moldeó a propósito para que sonara parecida a energía, porque quería que ambas se leyeran como magnitudes de la misma familia.

No nació como una idea filosófica sobre el caos, sino resolviendo un problema de ingeniería muy concreto: por qué ninguna máquina de vapor real alcanzaba el rendimiento que la teoría prometía. Siempre se perdía algo por el camino, y ese algo no se podía recuperar.

Casi un siglo después, en 1948, Claude Shannon se llevó la misma matemática a un sitio inesperado: los canales de comunicación. En su versión, la entropía ya no mide calor perdido, mide incertidumbre. Cuánta sorpresa hay en un mensaje. Cuánto no puedes predecir.

Esa es la que nos importa aquí, y por eso «bits de entropía» no es una forma pedante de decir «bits». Es una medida de cuánta ignorancia tiene sobre tu llave quien quiere adivinarla. En física mide el desorden que no puedes deshacer; en criptografía, la ignorancia que no puedes reducir.

Y por eso el fallo se describe como «pérdida de entropía» en vez de como «contraseña débil». No es que las palabras de Coldcard fueran malas palabras. Es que el atacante tenía mucha menos ignorancia de la que el diseño daba por supuesta.

Una computadora no sabe hacer nada al azar

Esta es la parte que hace que el fallo sea casi inevitable en cuanto te descuidas, y merece explicarse despacio.

Un procesador es una máquina determinista. Le das las mismas entradas y te da las mismas salidas, siempre, sin excepción. Esa propiedad es justo lo que queremos de una computadora. Y es exactamente lo contrario de lo que necesita la criptografía.

Cuando pides un número «aleatorio» a un lenguaje de programación, lo que recibes casi siempre es un generador pseudoaleatorio: una función matemática que, partiendo de un valor inicial, escupe una secuencia que parece desordenada. Parece, pero no lo es: si conoces ese valor inicial, conoces la secuencia entera, del primer número al último. Es una baraja que se mezcla siempre igual si la cortas por el mismo sitio. (A ese valor inicial también se le llama semilla, por cierto, y no tiene nada que ver con la semilla de tu billetera. Mala suerte con los nombres.)

Para conseguir azar de verdad hay que salir del mundo digital y medir algo del mundo físico, algo que ni el fabricante pueda predecir. Los dispositivos serios llevan para eso un generador de hardware. En el microcontrolador que monta la Coldcard, un STM32, funciona así según la propia documentación de ST: hay varios osciladores en anillo, circuitos que oscilan libremente, y se aprovecha que ninguno oscila exactamente al ritmo esperado. Ese temblor diminuto e irrepetible se llama jitter, y nace del ruido térmico de los electrones. Las salidas se muestrean, se combinan y se procesan hasta obtener números impredecibles incluso para quien fabricó el chip.

Otros dispositivos usan otras fuentes del mismo tipo: ruido eléctrico, avalanchas en un diodo, hasta desintegraciones radiactivas. Todas comparten la idea. La aleatoriedad no se calcula, se cosecha.

Y ahora ya se entiende lo que pasó de verdad. La Coldcard tenía su generador de hardware. Estaba montado, funcionaba y estaba en el firmware. Lo que ocurrió es que, por un error de integración, la función que creaba las semillas dejó de preguntarle a él y empezó a preguntarle al generador por software de reserva. Al oscilador nadie lo desconectó. Simplemente dejaron de llamarlo.

Por qué nadie va probando direcciones al azar

Aquí llega la pregunta obvia: si todas las direcciones están ahí y el registro es público, con 58 millones de ellas con saldo, ¿por qué no hay gente probando llaves a lo bestia hasta acertar?

La respuesta no es que sea difícil. Es que no sale a cuenta ni de lejos, y se puede calcular.

Una tarjeta gráfica actual deriva del orden de mil millones de claves por segundo consumiendo unos 300 vatios. Con esa referencia, y con la electricidad a 0,15 dólares el kilovatio hora, recorrer un espacio entero cuesta esto:

Espacio	Coste de recorrerlo entero
40 bits (Coldcard Mk2 y Mk3)	1,4 centavos de electricidad. Menos que cargar el celular.
72 bits (Coldcard Mk4, Mk5 y Q)	Unos 59 millones de dólares. Caro, pero al alcance de un Estado.
128 bits (lo que debería haber sido)	Capturar toda la energía que emite el Sol, en todas las direcciones, durante tres días enteros.
160 bits (todas las direcciones que existen)	Toda la emisión del Sol durante 36 millones de años.

Y no es un cálculo teórico de salón: hay un experimento público midiendo exactamente esta frontera desde 2015. Alguien depositó bitcoin en 256 direcciones cuyas claves están confinadas a rangos cada vez mayores (una de 1 bit, otra de 2, y así) y las dejó a la vista de todo el mundo con el premio dentro. Es el marcador oficial de hasta dónde llega la fuerza bruta real.

El reto número 66, con 6,6 BTC dentro (unos 400.000 dólares), cayó en septiembre de 2024. El 67 aguantó hasta febrero de 2025. Y hablamos de gente coordinándose en pools de GPU, con el premio visible y el rango acotado de antemano.

Coloca ahí las Coldcard y se entiende todo de golpe. Los 40 bits de las Mk3 son 67 millones de veces más fáciles que ese reto 66 que costó años tumbar. Y los 72 bits de los modelos nuevos son solo 64 veces más duros que él: por encima de la frontera, sí, pero a la vista de ella. Por eso Coinkite pide migrar también esos.

Hay además un detalle que suele sorprender: la enorme potencia de minado de Bitcoin no sirve para esto. Los ASIC de los mineros solo saben hacer una cosa, SHA-256, y buscar claves requiere aritmética de curva elíptica, que es otra operación completamente distinta. El hardware que sostiene la red es literalmente incapaz de atacarla.

Por qué 72 bits no está a mitad de camino de 128

Traduzcámoslo también a tiempo, que se siente distinto que el dinero. Al mismo ritmo de mil millones de intentos por segundo:

• 40 bits: dieciocho minutos.
• 72 bits: unos 150.000 años.
• 128 bits: unos 780.000 millones de veces la edad del universo.

Para verlo desde el otro lado: con los 128 bits que tocaban, cada persona del planeta podría crear 2.600 millones de billeteras y todavía sería improbable que dos coincidieran. Con 40, como veremos ahora mismo, la cosa cambia por completo.

Esa es la trampa mental de la entropía: la escala no es lineal, es exponencial. Tener un tercio de los bits no significa ser un tercio de seguro. Significa la diferencia entre gastar 1,4 centavos de electricidad y necesitar tres días de toda la energía que emite el Sol.

El robo silencioso que quizá ya había ocurrido

Aquí hay una posibilidad que no he visto mencionada en ninguna parte y que, cuanto más la miro, más me inquieta. Es especulación, y la marco como tal desde el principio. Pero los números la sostienen.

Si el espacio de semillas se había reducido a 40 bits, no hacía falta ningún atacante para que ocurriera algo raro. Bastaba con que dos Coldcard distintas eligieran por casualidad la misma. Es la paradoja del cumpleaños de toda la vida: en una clase de veintitrés personas es más probable que no que dos cumplan años el mismo día, aunque el año tenga 365.

Y hay un detalle técnico que lo hace posible en vez de imposible. El generador defectuoso se inicializaba con la parte baja del identificador único del chip, entre otras cosas. Podría pensarse que eso separa a cada dispositivo del resto, pero el análisis técnico apunta a lo contrario: distintos chips pueden compartir esa parte baja del identificador. La separación no estaba garantizada.

Los números, con el espacio de 40 bits de las Mk2 y Mk3: si se generaron 100.000 semillas, la probabilidad de que dos coincidieran es del 0,45 %. Con 250.000, del 2,8 %. Con medio millón, del 10,7 %. Y a partir de 1,2 millones de semillas, la coincidencia es más probable que su ausencia.

Coinkite no publica cifras de ventas, así que no puedo cerrar el cálculo. Lo que sí sabemos del mercado: Ledger lleva más de ocho millones de dispositivos vendidos y Trezor más de dos, mientras que los fabricantes especializados como Coinkite se reparten un resto que no llega al cinco por ciento. Con eso, la horquilla razonable deja la probabilidad en algún punto entre «poco probable» y «bastante posible», sobre todo contando que mucha gente genera varias semillas a lo largo de los años: pruebas, reinstalaciones, billeteras temporales.

Ahora la parte que da vértigo. Si eso pasó, la persona lo habría visto. Al estrenar una billetera, el programa recorre la cadena buscando sus direcciones. Si esa semilla coincidió con la de otra persona, la billetera recién creada aparecería con saldo. Bitcoin dentro. Sin explicación.

Imagina la escena, en 2023. Alguien acaba de sacar el dispositivo de la caja, ha apuntado sus doce palabras, y el programa le dice que tiene fondos. ¿Qué conclusión saca? Desde luego no que el generador de números aleatorios de su hardware wallet esté roto: eso no lo sabía nadie en el mundo todavía. Pensaría que se ha equivocado de billetera, que el programa se ha colgado, o que ha restaurado sin querer un respaldo viejo.

Si mira el historial, ahí aparece el dato que no admite confusión: esos bitcoin llegaron años antes de que él comprara el dispositivo. En ese momento se abre una bifurcación que ya no es técnica, sino moral, y el protocolo no tiene absolutamente nada que decir sobre cuál de las dos ramas se toma.

Quien decide que eso no es suyo tiene una salida limpia y que no le cuesta nada: genera una billetera nueva, olvida esas palabras y no toca ni un satoshi. Devolverlo no puede, porque la cadena no dice de quién era. Pero tampoco hace falta: dejándolo quieto, el dueño no llega a enterarse nunca y no pierde nada. Es, con diferencia, lo más fácil de hacer.

Quien decide quedárselo, firma y se lo lleva. Y aquí está lo desagradable: en la cadena esa transacción no se distingue de ninguna otra. Tiene la llave, la firma es válida, y para Bitcoin eso es todo lo que hay que saber sobre de quién es el dinero. No queda constancia de que ahí ocurriera nada.

Solo en esa segunda rama hay alguien que, al otro lado, un día abre su billetera y no encuentra nada. Sin robo, sin phishing, sin haber enseñado sus palabras a nadie. Y sin ninguna forma de averiguar qué pasó, porque el fallo no se conocería hasta cinco años después.

No hay manera de saber si ocurrió. Casos así, aislados y sin explicación, se archivan como «error del usuario» y no dejan rastro público. Lo que sí sabemos es que durante cinco años fue posible, y que si hubiera pasado, nadie habría tenido forma de entenderlo.

Un consuelo pequeño: en los modelos con 72 bits este escenario es esencialmente imposible. Haría falta generar ochenta y un mil millones de semillas para que la coincidencia fuese probable. Entre 40 y 72 bits no hay un escalón: hay un abismo.

El fallo: una comprobación que preguntaba lo que no era

En 2021, Coldcard migró parte de su código a libsecp256k1, la biblioteca criptográfica que usa el propio Bitcoin Core. Era una decisión razonable: apoyarse en código muy probado en lugar de mantener el tuyo.

Con esa migración, la generación de la semilla dejó de llamar directamente al generador de aleatoriedad del hardware y pasó a llamar a ngu.random.bytes(). Y ahí, en el punto donde encajan dos componentes, ocurrió todo.

La biblioteca traía una comprobación de seguridad que decía, en esencia, «si no hay generador de hardware, no compiles». Escrita así:

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef pregunta si el símbolo existe. No pregunta si vale algo. Y Coldcard lo tenía definido… con valor cero, porque usaba su propio generador y quería desactivar el de MicroPython:

#define MICROPY_HW_ENABLE_RNG (0)

El símbolo existía. La comprobación se dio por satisfecha y no dijo nada. Pero MicroPython, unas líneas más allá, sí miraba el valor, vio un cero, y compiló su generador de reserva por software: un algoritmo determinista llamado Yasmarang.

Las dos implementaciones se llamaban igual y tenían la misma firma, rng_get(). El enlazador no protestó. El dispositivo arrancó. Generó palabras válidas. Firmó transacciones correctas. Todo funcionaba.

Es el equivalente a una inspección que comprueba si hay un extintor colgado en la pared, en vez de comprobar si está cargado. El extintor estaba. Rojo, visible, en su sitio, superando todas las revisiones durante cinco años. Y vacío.

Yasmarang se inicializaba una sola vez con tres cosas: parte del identificador único del microcontrolador, el valor de un contador del sistema y un registro del reloj. Después de eso, según el análisis independiente del equipo de ingeniería de Block, no recogía ni un bit más de aleatoriedad: cada salida siguiente era una transición determinista del estado anterior.

Coldcard pasaba después ese resultado por funciones hash. No sirve de nada, y merece la pena entender por qué: un hash puede desordenar, no puede crear. Si el generador solo puede producir mil resultados distintos, aplicarle SHA-256 te da mil valores que parecen aleatorios. Siguen siendo mil. Es como asignar códigos postales de treinta cifras a mil casas: los códigos se ven complicadísimos y siguen apuntando a mil casas.

Cómo se roba sin tocar el dispositivo

Ya sabemos qué buscaba y cómo lo buscaba. Falta lo más llamativo del asunto: lo poco que necesitó para hacerlo.

El atacante no se conectó a ninguna Coldcard, no rompió ningún chip seguro y no infectó la computadora de nadie. Le bastó con lo que ya hemos visto: reproducir en su propia máquina los estados que aquel generador podía producir, derivar las direcciones de cada uno y buscarlas en el registro. Lo único que necesitó traer de fuera fue una copia de la cadena de bloques, que cualquiera se descarga sin pedirle permiso a nadie.

Y fíjate en esa última parte, la de buscar en el registro, porque tiene un giro cruel. La transparencia de Bitcoin normalmente no es un problema: puedes publicar todas las direcciones que quieras, porque nadie puede recorrer el espacio de claves. Pero en cuanto ese espacio se encoge, esa misma transparencia se convierte en el catálogo donde el atacante comprueba si ha acertado. La red le dice gratis y al instante cuáles de sus candidatos valen dinero.

Bitcoin, por su parte, no notó nada raro. Desde la red, esas transacciones eran perfectamente válidas: firmas correctas sobre fondos legítimos. Bitcoin no sabe qué es un robo. Solo sabe comprobar firmas.

Una cosa que sí conviene decir: nadie serio ha publicado cuánto se tarda. Block se negó explícitamente a dar una cifra de fuerza bruta de extremo a extremo, porque el coste real depende de cuánto pueda acotarse el identificador del chip, el momento de arranque, cuántas llamadas previas hubo y lo caro que sea derivar y comprobar cada candidato. Que los dos análisis técnicos disponibles se abstengan de dar un número es, en sí mismo, información: significa que quien te dé uno redondo probablemente se lo esté inventando.

Veinticuatro horas: de «es culpa del usuario» a «asumimos la responsabilidad»

La parte humana de esta historia es tan instructiva como la técnica.

El barrido ocurrió de madrugada. La primera víctima no apareció hasta las 13:19 UTC, contándolo en Reddit. A las 17:35, Kevin Loaec, cofundador de Wizardsardine, pidió públicamente a quien tuviera una Coldcard que revisara su saldo, con una frase que envejeció fatal: «espero que no sea nada, pero hago mi trabajo».

A las 18:10, Rodolfo Novak (NVK, fundador de Coinkite) respondió que no había que entrar en pánico: que alguien había cargado una semilla comprometida, o que se le había filtrado por otro lado. Es decir, culpa del usuario.

Menos de una hora después, a las 19:05, Loaec cambió el tono a «esto no es un simulacro». Para entonces el desarrollador conocido como grubles había confirmado un caso, Jameson Lopp reportaba robos parciales, y entre las víctimas había bitcoiners conocidos y competentes. La hipótesis del despistado ya no se sostenía.

Novak retiró su valoración diciendo que no quería que circulara información incorrecta. Esa misma noche Coinkite publicó el aviso de seguridad. De madrugada salió el firmware de emergencia. Y el 31 de julio la empresa pidió disculpas públicamente y asumió la responsabilidad.

Merece la pena señalar lo obvio, porque es un patrón que se repite en todos los incidentes de seguridad que he visto de cerca: la primera explicación de cualquier fabricante es siempre que el usuario hizo algo mal. A veces es verdad. Cuando no lo es, el tiempo que se pierde defendiendo esa hipótesis lo pagan los usuarios que todavía podían haber movido sus fondos.

Por qué esto duele más: era la que recomendaban los más exigentes

Si esto le hubiera pasado a un cacharro de dudosa procedencia que guarda tus claves en un servidor, la conclusión sería fácil: elegiste mal. Coldcard no permite esa salida.

Coldcard se había ganado su reputación quitando cosas. Solo Bitcoin, sin las mil monedas que arrastran código y formatos que nadie revisa. Capaz de funcionar air-gapped, firmando por tarjeta microSD o por códigos QR, sin tocar nunca un cable USB. Dos elementos seguros. Compilaciones reproducibles. Soporte de dados para que añadieras tu propia aleatoriedad. Multifirma, PSBT, todo el juego de herramientas del usuario paranoico.

Era, para mucha gente, la versión más cercana al ideal cypherpunk que se podía comprar. La defendían precisamente los que más se preocupaban por este tipo de riesgo. Y eso es lo que hace el golpe interesante en vez de anecdótico: un sistema puede tomar muchísimas decisiones correctas y contener aun así un fallo catastrófico.

La corrección incómoda: Coldcard no era software libre

En estos días he leído muchas veces que el fallo demuestra que «el código abierto no basta». Antes de sacar esa lección hay que arreglar un dato que casi todo el mundo repite mal.

El firmware de Coldcard llevaba sin ser software libre desde noviembre de 2020. Hasta entonces era GPLv3. A partir de ahí pasó a MIT con una Commons Clause, que prohíbe vender productos derivados. Eso lo convierte en código disponible, no en código abierto: puedes leerlo, compilarlo y verificar que el binario corresponde, pero no puedes bifurcarlo y competir. El propio Coinkite dejó de llamarlo open source y empezó a llamarlo verificable.

La cronología importa: el cambio de licencia fue en noviembre de 2020, y el fallo entró en la versión 4.0.1, de marzo de 2021. Cuatro meses después.

Zach Herbert, fundador de Foundation Devices, sostiene estos días que ambas cosas están conectadas: su empresa construía sobre el Coldcard con licencia GPL y tuvo que separarse tras el cambio. Conviene tomarlo con la reserva que merece (Herbert es competidor directo y tiene un interés evidente) y también reconocer que el mecanismo que describe es real y no requiere mala fe: quien bifurca tu código es, en la práctica, uno de tus revisores más motivados. Lee cada línea porque va a mantenerla. Cuando cierras esa puerta, no pierdes lectores casuales: pierdes al que tenía un motivo económico para leerte de verdad.

Dicho esto, no conviene convertirlo en la explicación del fallo. Proyectos con licencia impecablemente libre han arrastrado agujeros durante años. La lección honesta es más modesta y más útil: «el código es público» describe un permiso, no una actividad. Que cualquiera pueda mirar no significa que alguien haya mirado, y menos aún que haya mirado la línea correcta con la pregunta correcta.

Coinkite lo ha admitido con una franqueza que se agradece: sus revisiones comprobaron que la implementación correcta del generador de hardware estaba presente en el firmware, pero no siguieron de extremo a extremo qué implementación acababa ejecutándose cuando el usuario pulsaba «crear billetera nueva».

Por qué ninguna de sus defensas podía evitarlo

De todo el episodio, esta es la parte que cualquiera puede aplicar a su propio trabajo, tenga bitcoin o no. Las defensas de Coldcard eran reales y hacían bien su trabajo. Lo que pasa es que ninguna de ellas defendía contra esto, y no había forma de que lo hicieran.

La compilación reproducible es el ejemplo más claro. Sirve para demostrar que el pastel que te venden se corresponde exactamente con la receta publicada. Es una garantía valiosa contra un fabricante que te cuele algo por debajo. No dice absolutamente nada sobre si la receta era buena.

De ahí sale la frase que resume todo el episodio: las propiedades de seguridad no se sustituyen entre sí. No es una puntuación acumulativa donde cinco etiquetas correctas suman «invulnerable». Air-gapped más chip seguro más código verificable más Bitcoin-only no equivale a seguro, porque cada una cubre una amenaza distinta y ninguna cubría la de arriba del todo: que el secreto naciera predecible.

Los dados: la única defensa que aguantó del todo

Ya hemos visto todo lo que no protegía. Toca mirar lo que sí, porque hubo gente que salió indemne de esto, y no por suerte.

Coldcard permitía algo que casi ningún fabricante ofrece: tirar un dado físico y meter esas tiradas en la generación de la semilla. El firmware las mezclaba con lo que producía el dispositivo. Cada tirada de un dado de seis caras aporta unos 2,58 bits de imprevisibilidad, así que con cincuenta tiradas ya se superan los 128 bits por sí solas, sin depender del generador para nada.

Coinkite considera que entre 50 y 98 tiradas aportan al menos esos 128 bits, y que 99 o más se acercan a 256. Si tiraste el dado al menos cincuenta veces, con un dado honesto, sin repetir patrones y sin que nadie apuntara los resultados, tu semilla no está en riesgo por este fallo. La aleatoriedad que el software no podía predecir venía de tu mano.

La escala es lineal y aquí sí es fiel, porque los bits ya son un logaritmo. Tiene truco, eso sí: vale si el dado es honesto, si tiras de verdad en vez de elegir los números y si nadie apunta la secuencia.

Es la defensa perfecta contra este problema por una razón conceptual: no confía en el dispositivo. Le añade una fuente que el fabricante no controla, no puede simular y no puede estropear con una macro mal escrita. Y es también la más incómoda de usar, motivo por el cual casi nadie la usaba.

Ojo, que tiene su propia trampa. Si eliges los resultados mentalmente en vez de tirar, si el dado está sesgado, si fotografías la secuencia o si apuntas mal una tirada, has creado un problema nuevo mientras intentabas evitar otro. La entropía manual es una herramienta avanzada, no un ritual que haga segura una billetera por el mero hecho de practicarlo.

Y ahora la parte de esta historia que más me cuesta digerir, porque no hace falta suponer nada para que sea grave.

En octubre de 2021, un usuario preguntó a la cuenta de Coldcard qué era un retirement attack. La respuesta, que sigue publicada, fue esta: «es cuando los creadores del proyecto podrían tener un “fallo” en la generación de entropía para recuperarlo más tarde». Lo decían mientras promocionaban precisamente la función de dados como defensa.

Léelo otra vez. Coinkite conocía este modelo de amenaza tan bien que le había puesto nombre en público, se lo había explicado a sus usuarios y les había ofrecido la herramienta exacta para protegerse de él. Y para entonces el fallo llevaba ya siete meses dentro de su propio firmware.

Hay quien ha usado ese tuit para insinuar que fue deliberado. Yo no voy por ahí, y las fechas juegan en contra de esa lectura: el fallo entró en marzo de 2021 y el tuit es de octubre, así que difícilmente anuncia un plan. Además, una puerta trasera bien puesta sería exclusiva de quien la pone, y esta dejó 40 bits al alcance de cualquiera con una tarjeta gráfica. Prueba de ello es que hoy hay quince atacantes distintos sirviéndose de ella.

Pero no hace falta ninguna conspiración para que esto sea demoledor, y por eso lo cuento. El fallo no fue no saber. Fue no verificar. La empresa tenía el modelo de amenaza perfectamente identificado, con nombre propio y con mitigación recomendada, y aun así no comprobó de extremo a extremo qué generador acababa ejecutándose en su propia ruta de creación de semillas. Sabían exactamente qué buscar y no miraron ahí.

La multifirma de Coldcards no protegía de esto

La multifirma se vende, con razón, como la respuesta a este tipo de fallo: si hacen falta dos llaves de tres para gastar, que una se rompa no basta. Pero hay una letra pequeña que casi nadie leía, y tiene que ver con algo que ya vimos: esa dirección es un hash.

Mientras una multifirma no ha gastado nunca, el mundo solo ve ese hash. No sabe cuántas llaves hay detrás, ni cuántas hacen falta, ni de qué marca son. En el momento en que gastas por primera vez, el script completo queda registrado en la cadena, y con él las claves públicas de todos los participantes. Para siempre y a la vista de cualquiera.

Con eso, un atacante puede recorrer la cadena buscando scripts de multifirma que contengan claves públicas derivables del espacio defectuoso. Y ahí es donde se rompe el argumento: si dos de tus tres llaves salieron de Coldcards afectadas, tiene las dos que necesita. El umbral se cumple y los fondos son suyos.

El detalle incómodo es que esa configuración era común. Coldcard promocionaba activamente la multifirma, mucha gente compró varias del mismo fabricante para montarla, y a nadie le parecía mal: tres dispositivos son tres dispositivos. Como resume el análisis de operadores de 808bits, «tres llaves en tres dispositivos de la misma marca son redundancia contra la pérdida, no contra un fallo de diseño».

Lo que sí funcionó fue la diversidad de fabricante. Un 2 de 3 con una Coldcard, una Trezor y una BitBox pierde una llave y se queda por debajo del umbral: los fondos siguen a salvo, aunque haya que migrar igual. La lección no es «usa multifirma», es «usa multifirma con implementaciones que puedan equivocarse de formas distintas».

Por qué la passphrase salvó a unos y a otros no

El atacante se quedó con el primer escalón, el número, y con él viene detrás todo lo demás por puro cálculo. Todo menos un cruce: el paso de las palabras a la semilla. Ahí es exactamente donde entra la passphrase, porque las mismas palabras, con passphrase o sin ella, dan dos semillas completamente distintas, y por tanto dos árboles de claves y dos juegos de direcciones que no tienen absolutamente nada que ver.

Y aquí llega la parte que casi nunca se cuenta bien. Sobre la passphrase circulan dos afirmaciones que parecen contradecirse: que «solo compra tiempo» y que «el atacante ni siquiera te ve». Las dos son ciertas, pero cada una describe un escenario distinto, y entre los dos hay una diferencia enorme.

Escenario A: nunca usaste la billetera sin passphrase. El atacante genera candidatos, deriva sus direcciones con la passphrase vacía y las busca en el registro público. Las tuyas no salen de ahí, así que no hay coincidencia y su barrido te pasa por encima sin detectarte. Y no, gastar no cambia nada: al gastar se publica tu clave pública, pero esa clave tampoco está en su lista, porque nació de otra semilla. Con la clave pública maestra, la xpub, pasa lo mismo. En este escenario, literalmente no apareces.

Podría, eso sí, ampliar la búsqueda y probar passphrases contra cada candidato. Los números dicen que no le sale a cuenta: incluso con una passphrase mala de veinte bits, como una palabra común, tendría que hacer esa prueba contra el billón largo de candidatos. Con mil tarjetas gráficas trabajando a la vez, unos cuatro años. Con una passphrase de treinta bits, casi cuatro mil años.

Escenario B: en algún momento depositaste algo en la billetera sin passphrase. Mucha gente lo hace, como señuelo o simplemente probando el dispositivo el primer día. Y eso lo cambia todo, porque esa dirección sí aparece en su barrido. En cuanto sale, el atacante sabe tres cosas: que existes, cuál de los candidatos eres, y que muy probablemente tienes una passphrase escondiendo el resto.

A partir de ese momento ya no tiene que probar nada contra un billón de candidatos. Solo contra el tuyo. Y los números se derrumban: una passphrase de veinte bits cae en menos de un segundo con una sola tarjeta gráfica. Una de treinta bits, en dos minutos. Una de cuarenta, en treinta y una horas. Hace falta llegar a los sesenta bits de verdadera aleatoriedad, que ya no es una frase que uno recuerde, para que vuelva a ser inabordable.

Entre los dos escenarios hay un factor de 1,1 billones. La misma passphrase que te hace invisible en el primero es papel mojado en el segundo, y lo único que separa uno de otro es si alguna vez mandaste unos satoshis a la billetera de abajo.

Con eso ya se entiende por qué las dos frases eran ciertas. Frente al ataque tal como ocurrió, un barrido masivo contra billeteras sin passphrase, quien tenía una no salió en la lista. Frente a un atacante que ya te ha localizado y decide dedicarte cómputo a ti, una passphrase humana cae. Y el precio de pasar de un escenario al otro fueron unos satoshis de prueba en 2022.

Por eso Coinkite la llama mitigación y no arreglo, y recomienda migrar también a quien tenía una. Es la descripción correcta: no sabes en cuál de los dos escenarios estás hasta que es tarde, y no convierte una semilla defectuosa en una sana.

Por qué repartir el respaldo no sirve de nada aquí

Queda una defensa que mucha gente da por buena y que en este caso no aporta absolutamente nada. Merece un apartado corto porque la confusión es muy común.

Shamir, o SLIP-39, permite partir el respaldo de una semilla en varias participaciones, de forma que hagan falta dos de tres, o tres de cinco, para reconstruirla. Protege muy bien contra perder una copia, contra un incendio en una ubicación y contra que te roben una caja fuerte.

Pero fíjate en el orden de las operaciones: primero se genera el secreto, y después se parte. Un secreto de 40 bits partido en tres trozos sigue siendo un secreto de 40 bits. Repartirlo no amplía el espacio del que salió.

Y hay algo peor: al atacante ni siquiera le hacen falta tus trozos. No está intentando reconstruir tu respaldo, está generando los secretos candidatos directamente desde el principio de la cadena. Tus participaciones de Shamir podrían estar en tres cajas fuertes de tres países y daría exactamente igual.

Shamir, o SLIP-39, protege muy bien de perder una copia, de un incendio o de que te roben una caja fuerte. Contra este fallo no hace nada: el atacante no intenta reconstruir tu respaldo, genera los secretos candidatos desde el principio de la cadena.

Shamir reparte la custodia del respaldo. No mejora la calidad de lo que se respaldó. Son dos problemas distintos y conviene no confundirlos.

Quince atacantes, y sangre en el agua

Lo que empezó como un robo se ha convertido en una fiebre.

Cuando Coinkite publicó el aviso, hizo lo único que podía hacer: contarlo para que la gente moviera sus fondos. Pero contarlo también significa explicarle a todo el mundo dónde está el agujero. Y el agujero es fácil de explotar una vez sabes que existe.

Alex Thorn, de Galaxy Research, estima que hay ya al menos quince atacantes distintos operando sobre la misma vulnerabilidad. No un ladrón: quince, en oleadas sucesivas, compitiendo por barrer lo que queda antes de que el dueño se entere.

Y detrás de los que saben programar vienen los que saben mentir. Trezor y Foundation han avisado de una oleada de phishing, y Proofpoint ha documentado campañas de correos que se hacen pasar por una «auditoría coordinada de hardware» y llevan a webs clonadas que instalan software de acceso remoto. El pánico es un terreno fértil: hay mucha gente asustada buscando instrucciones urgentes, y eso es exactamente lo que un estafador necesita.

Los que todavía no saben que les han robado

Aquí hay una crueldad que da vueltas en la cabeza.

Los datos en cadena dicen que las monedas robadas llevaban una media de 3,18 años sin moverse. Eso no es casualidad ni mala suerte: es el perfil exacto de quien hizo bien las cosas. Compró un dispositivo caro y específico, generó sus llaves fuera de línea, apuntó las palabras en papel, guardó el papel y no volvió a tocarlo. Ese era el consejo. Ese es el consejo.

Y ese mismo comportamiento es el que hace que ahora mismo, mientras lees esto, haya gente que no sabe que ya no tiene nada. Alguien que no mira su saldo, que no sigue noticias de bitcoin, que ni siquiera recuerda con qué firmware montó aquello en 2022. Lo descubrirá dentro de meses, o de años, cuando vaya a usarlo.

Es la paradoja más incómoda del almacenamiento en frío: cuanto mejor lo hiciste, menos probable es que te enteres a tiempo. La disciplina de no tocar nada, que es una virtud durante diez años, se convierte en una desventaja durante una semana.

Por eso el consejo más útil que puedo dar en este artículo no es técnico. Si conoces a alguien que compró una Coldcard, escríbele. No des por hecho que se ha enterado.

La única diferencia que de verdad importa

Con todo lo anterior encima de la mesa, toca la pregunta que se está haciendo mucha gente estos días: si la autocustodia también falla, ¿para qué complicarse?

Empecemos por reconocer lo que pasó, porque es incómodo. Tras el aviso, las transferencias pequeñas de bitcoin hacia los exchanges alcanzaron su nivel más alto desde el desplome de FTX en noviembre de 2022, unos 39.600 BTC en un solo día según CryptoQuant. Es decir, lo contrario exacto de lo que pasó entonces: en 2022 la gente sacaba su bitcoin de los exchanges, ahora hay quien lo está devolviendo.

Pero al mismo tiempo, y esto es lo que casi nadie ha puesto en su sitio, ocurrió otra cosa. Se despertaron billeteras que llevaban años quietas: unos 6.400 BTC dormidos entre cinco y siete años se movieron el 31 de julio, y el 3 de agosto se movieron 935 BTC que llevaban más de una década sin tocarse. Gente poniendo a salvo lo suyo por su cuenta, en cuestión de horas.

Nick Neuman, director de Casa, una empresa estadounidense de custodia con multifirma, estima que se protegió del orden de diez veces más bitcoin del que se robó. Es una estimación suya, no un dato auditado, pero la dirección se ve en la cadena.

Y ahí está la comparación que de verdad importa, que no es «autocustodia contra custodio» sino «este fallo contra los fallos del otro modelo». Conviene ser preciso, porque los dos grandes desastres suelen meterse en el mismo saco y no son lo mismo. En Mt. Gox sí hubo un robo: alguien accedió a las llaves del exchange y fue sacando bitcoin durante años sin que nadie lo notara, hasta unos 850.000. En FTX no hubo ningún ataque: la propia empresa usaba el dinero de sus clientes para tapar las pérdidas de otra empresa suya. Eso es un fraude, no un robo, y su fundador fue condenado por ello.

Distintos en la causa, idénticos en lo único que cuenta aquí: en ninguno de los dos hubo nada que hacer. Ni una sola persona pudo reaccionar, porque el dinero no estaba bajo su control. Un día abres la web y ya no está, y da exactamente igual si te enteras en el minuto uno o al día siguiente. No había ventana.

El «miles» sale del movimiento en cadena de los días siguientes al aviso: unos 6.400 BTC dormidos entre cinco y siete años se movieron el 31 de julio, y 935 BTC con más de una década quietos el 3 de agosto.

Eso es lo que compras con la autocustodia, y conviene entenderlo bien porque no es lo que la gente cree. No compras que no haya fallos: acabamos de ver uno enorme. Compras la posibilidad de reaccionar tú, sin pedirle permiso a nadie ni esperar a que una empresa abra su ventanilla. Miles de personas usaron esa ventana la semana pasada. En Mt. Gox no la tuvo nadie.

Lo cual no le sirve absolutamente de nada a quien perdió lo suyo, y hay que decirlo así de claro. Pero quien esté decidiendo estos días si devuelve su bitcoin a un exchange debería mirar las dos columnas enteras, no solo la que está en las noticias.

Si tienes una Coldcard

Restaurar esa misma semilla en una Trezor o una BitBox tampoco la arregla, por el mismo motivo. Y no metas tu frase en ninguna web que ofrezca «comprobar si estás afectado»: ese es el segundo robo que viene siempre detrás del primero.

El procedimiento es: actualizar el firmware primero, generar una semilla completamente nueva, anotar y verificar el respaldo antes de meter nada, comprobar una dirección de recepción en la pantalla del dispositivo, mandar una cantidad pequeña, confirmarla, y solo entonces mover el resto. Conserva el respaldo viejo hasta que todo esté confirmado.

Y lo que no hay que hacer: actualizar el firmware y seguir usando la misma semilla, porque el problema viaja con el secreto y actualizar no lo transforma. Restaurarla en una Trezor o una BitBox tampoco la arregla, por el mismo motivo. Y por descontado, no metas tu frase en ninguna web que ofrezca «comprobar si estás afectado»: ese es exactamente el segundo robo que viene siempre detrás del primero.

El problema que no tiene ninguna solución buena

Hay dos preguntas que se hacen todos los que llevan un rato con esto, y ninguna tiene respuesta cómoda.

La primera: aunque se recuperase el dinero, no se podría devolver. Imagina que detienen al ladrón y un juzgado ordena restituir los fondos a sus direcciones de origen. Sería inútil. Esas semillas siguen siendo débiles, y lo serán siempre: el defecto viaja con el secreto, y el secreto ya es público en la práctica. Devolver bitcoin a una dirección comprometida es dejarlo en la acera. Duraría minutos, y esta vez habría quince personas mirando. La única restitución posible pasa por que cada víctima genere llaves nuevas y reciba el dinero ahí, lo cual es perfectamente posible pero exige identificar a la víctima, algo que la cadena no sabe hacer.

La segunda: ¿y si Coinkite lo hubiera descubierto años antes? Parece que la respuesta obvia es «se habría evitado todo», y no lo es, porque avisar tiene un coste inmediato: publicar el aviso es publicar el mapa. En el momento en que dices «las semillas de estos modelos tienen poca entropía», cualquiera con una tarjeta gráfica y un fin de semana puede hacer lo mismo que hizo el atacante. La empresa se mete en una carrera contra sus propios usuarios, muchos de los cuales, como acabamos de ver, tardan años en enterarse de nada.

Pero eso solo mira una mitad del problema, y la otra pesa más. Cada mes que pasaba se vendían más dispositivos que generaban semillas condenadas, y cada mes se acumulaba más saldo en las que ya existían. Descubrirlo en 2022 habría significado un aviso incómodo y una migración difícil, sí, pero también decenas de miles de billeteras que nunca llegaron a existir. El coste de esperar no fue lineal: fue todo el valor que se fue depositando en billeteras condenadas desde el día en que se crearon.

Repasemos entonces las alternativas, porque tampoco son buenas. Avisar solo en privado a los clientes no sirve: no hay una lista completa, mucha gente compra por terceros o de segunda mano, y un aviso así se filtra en horas.

Y aquí ocurrió algo que convierte ese dilema en un caso práctico incómodo. Coinkite sí escribió a sus clientes, uno por uno, a direcciones de correo que se remontaban a 2019. Muchos usuarios reaccionaron con enfado, y no por el aviso sino por lo que revelaba: que la empresa conservaba sus correos desde hacía años, cuando su fundador había dicho públicamente que ofrecían compra anónima y que borraban los datos del cliente a los noventa días. La empresa respondió que guardaba la dirección para que uno pudiera entrar a comprobar que el resto de sus datos sí estaban borrados, y reconoció que no tenía ningún calendario de borrado para ellas.

Lo que hace fascinante ese episodio es que las dos cosas son ciertas a la vez. Guardar esos correos contradecía lo que habían prometido, y es lo único que permitió avisar a nadie. Si hubieran cumplido su propia política de privacidad al pie de la letra, el aviso habría llegado solo por la prensa, y a mucha menos gente. No conozco una forma limpia de resolver eso, y desconfío de quien diga que la tiene.

Queda una última opción que a primera vista parece la más lista: publicar el firmware corregido sin decir por qué. Protege a quien actualice y no reparte el mapa. Conviene desmontarla, no porque sea difícil, sino porque hay empresas que la eligen.

Se cae por dos sitios a la vez. El primero es que no arregla nada para quien ya está afectado: una semilla débil sigue siendo débil por mucho firmware nuevo que le pongas encima, y ese es el problema entero. El segundo es que el código es público. Cualquiera puede comparar dos versiones y ver qué cambió, y un parche que toca precisamente la ruta del generador aleatorio es una bengala para quien sabe mirar: aquí había algo gordo.

Y ahí acaba siendo peor que decirlo. Porque al mismo tiempo que alguien reconstruye el fallo a partir del parche, queda por escrito que la empresa lo sabía y decidió callarlo. Acabas con las mismas víctimas, menos tiempo para reaccionar y una responsabilidad legal y moral considerablemente mayor.

Mi conclusión, y es una opinión, es que no había ninguna salida buena y sí una claramente menos mala: publicarlo cuanto antes, con el firmware ya listo, instrucciones de migración claras y toda la fuerza mediática posible. Es aproximadamente lo que se acabó haciendo. Solo que cinco años tarde y con el ladrón ya dentro.

Es la conclusión del autor, no un consenso del sector: publicarlo cuanto antes, con el firmware ya listo e instrucciones claras. Es aproximadamente lo que se acabó haciendo, cinco años tarde.

Y hay una arista que lo vuelve más feo. El desarrollador de Bitcoin James O’Beirne ha declarado que en mayo del año pasado avisó a Coinkite de que la implementación del generador aleatorio en esa biblioteca le parecía cuestionable, y que le respondieron que, de existir un problema real, probablemente ya se habría descubierto. Hay que decirlo con cuidado: es su versión, Coinkite no ha respondido públicamente, y avisar de que algo «parece cuestionable» no es lo mismo que reportar este fallo concreto. Pero si se confirma, la pregunta deja de ser hipotética.

¿Es esto el final de Coldcard?

Coinkite no vende cajas de plástico. Vende confianza, que es lo único que justifica pagar por un dispositivo de un solo uso en lugar de apuntar doce palabras generadas en cualquier sitio. Y esa confianza es lo que se ha roto.

La ironía es que hoy es probablemente el momento más seguro de la historia del producto. Hay más ojos sobre ese código que en los cinco años anteriores juntos: investigadores independientes, competidores, gente con motivos personales y modelos de inteligencia artificial peinando cada versión antigua. Si quedara otro agujero de esta magnitud, es difícil imaginar que aguantara semanas sin salir a la luz. El firmware corregido, además, no se limita a parchear la línea: hace que la compilación falle si no se enlaza el generador correcto, que es la clase de arreglo que impide que la categoría entera de error vuelva.

Pero la seguridad técnica y la supervivencia comercial son cosas distintas. Un fabricante de billeteras vive de una reputación que tarda años en construirse, y esta se ha roto con un fallo que además tenía cinco años de antigüedad y un aviso previo en disputa.

Hay además una decisión que marcará mucho lo que pase después: Coinkite no ha ofrecido compensación. Está ayudando a las víctimas a presentar denuncias y reclamaciones al seguro, y dice que su equipo legal coordinará con las autoridades de varias jurisdicciones para identificar a los responsables. Pero no ha puesto dinero encima de la mesa. Es una postura defendible, porque nadie fabrica billeteras con márgenes que aguanten ciento dieciséis millones, y al mismo tiempo es lo que a mucha gente le va a impedir volver a comprarles.

Y aquí está lo que de verdad me preocupa, que no es la empresa: si Coinkite desaparece, ¿quién mantiene los dispositivos que ya están ahí fuera? Una billetera de hardware no es una tostadora. Necesita firmware, necesita que alguien responda cuando salga la siguiente vulnerabilidad, necesita compatibilidad con los cambios de Bitcoin. Un fabricante que cierra deja a sus usuarios con un dispositivo que funciona hasta que deja de hacerlo, y sin nadie a quien preguntar. Eso lo hemos visto en otros sectores y siempre acaba igual.

Lo cual, si lo piensas, es otra vuelta de tuerca al mismo argumento del artículo. Compraste el dispositivo para no depender de nadie, y resulta que dependes de que la empresa siga existiendo. Es un argumento más a favor de la diversidad: no solo porque dos fabricantes se equivocan de formas distintas, sino porque dos fabricantes no suelen quebrar el mismo día.

Lo que esto enseña fuera de Bitcoin

Yo no me dedico a bitcoin, me dedico a redes y a seguridad. Y este incidente es, quitándole las monedas, un caso de manual que podría haber ocurrido en cualquier sistema que administre cualquiera de nosotros.

No hubo una función llamada generar_semilla_insegura(). Hubo una macro con valor cero, una comprobación que preguntaba por la existencia en vez de por el valor, dos funciones con la misma firma y un enlazador que hizo su trabajo sin quejarse. Cada pieza, mirada por separado, era correcta. El fallo vivía entre las piezas, que es justo donde no mira nadie.

De ahí saco tres cosas que sí me llevo al trabajo:

1. Verificar que una defensa existe no es verificar que se usa. La pregunta no es «¿está el generador de hardware en el binario?», sino «¿qué se ejecuta cuando el usuario pulsa el botón?». Son preguntas distintas y solo la segunda importa. Me pasó a mí rehaciendo este blog: tres minutos de página en blanco con el código de estado diciendo que todo iba bien.
2. Un aviso que no puede fallar no es un aviso. La corrección que publicó Coinkite no fue arreglar una línea: fue hacer que la compilación falle si no se enlaza la implementación correcta. Convertir una clase entera de error en algo que rompe el build es infinitamente mejor que confiar en que alguien lo vea leyendo.
3. Comprobar propiedades observables, no inspeccionar componentes. Trezor implementa un protocolo en el que el dispositivo se compromete con su entropía, el programa de la computadora aporta la suya, y después se reconstruye la billetera para verificar que el dispositivo usó de verdad ambas. No es infalible, pero es de otra categoría: no confía en que el firmware haga lo correcto, intenta demostrarlo desde fuera.

Hay un último detalle que se me ha quedado clavado. Coinkite dice que asume que el atacante usó inteligencia artificial para peinar versiones antiguas del firmware, y admite que ellos mismos habían pasado uno de los mejores modelos disponibles buscando vulnerabilidades y no encontró este fallo. Su fundador lo formuló diciendo que la revisión de código asistida por IA encuentra ya fallos latentes más rápido que los expertos más veteranos del sector.

Conviene añadir que varios especialistas en seguridad han discutido ese marco, y creo que con razón: la opción de compilación que desactivaba el generador de hardware es un fallo de ingeniería humano que una revisión convencional debería haber cazado años antes. Atribuirlo a que la IA se ha vuelto muy buena desplaza el foco de una pregunta más incómoda, que es por qué nadie siguió esa ruta a mano en cinco años.

Dicho lo cual, la herramienta la tienen los dos bandos. La conclusión no puede ser «pongamos otra IA a revisar», porque el atacante también la tiene y solo necesita acertar una vez. La conclusión es diseñar sistemas donde el fallo de una sola pieza no sea suficiente: entropía de más de una fuente, firmantes de más de un fabricante, comprobaciones que rompan la compilación en vez de esperar a un revisor atento. Sobre lo que cuesta de verdad asegurar el código que escribe una IA, con cifras y fuentes, escribí aparte.

Bitcoin no falló. La criptografía no falló. Falló una capa humana alrededor, en el punto donde se unían dos bibliotecas, y estuvo cinco años esperando a que alguien se molestara en seguir el hilo hasta el final.

Datos actualizados al 5 de agosto de 2026. La investigación técnica y el análisis de las transacciones siguen en curso: las cifras de fondos son estimaciones a partir del registro público, no un recuento confirmado de víctimas, y tanto Coinkite como Block han calificado sus estimaciones de entropía como preliminares.

Fuentes

Fuentes primarias

• Coinkite, aviso de seguridad y procedimiento de migración: blog.coinkite.com
• Coinkite, análisis técnico del fallo de entropía: blog.coinkite.com
• Block Engineering, análisis independiente del generador y del resembrado: engineering.block.xyz
• ST, nota de aplicación AN4230 sobre el generador de hardware del STM32: st.com
• El tuit de Coldcard de 2021 explicando qué es un retirement attack: x.com
• Jonathan Goodman, relato en primera persona de su pérdida: x.com

Cifras y análisis en cadena

• Galaxy Research amplía el recuento a 1.082,65 BTC: kucoin.com
• El primer recuento público, de unos 594 BTC: coindesk.com
• Recuento en 116 millones de dólares y el «lo hice todo bien»: forbes.com
• Cronología horaria del incidente: bitcoinwell.com
• Quince atacantes distintos y la oleada de phishing: decrypt.co
• El aviso conjunto de los fabricantes sobre la campaña de phishing: forklog.com
• Entradas de bitcoin hacia los exchanges: cryptoquant.com

Los precedentes de entropía débil

• LuBian: 127.426 BTC robados en 2020 con claves de 32 bits, destapado en 2025: coindesk.com
• Milk Sad (CVE-2023-39910): el mismo fallo en Libbitcoin Explorer: milksad.info
• El reto público que mide hasta dónde llega la fuerza bruta real: privatekeys.pw

Contexto y consecuencias

• El estándar BIP-39, que convierte el número en palabras: github.com
• El estándar BIP-32, que convierte la semilla en un árbol de claves: github.com
• Análisis de operadores sobre por qué la multifirma de una sola marca no protegía: 808bits.com
• James O’Beirne dice haber avisado en mayo del año pasado: bitcoinworld.co.in
• La polémica por los correos que Coinkite conservaba desde 2019: news.bitcoin.com
• El fraude de FTX, en la declaración de la CFTC: cftc.gov