El caso Stone Man
Dentro del problema de copia de seguridad de cartera Bitcoin que perdió 8.999 BTC
Stone Man hizo lo que se recomienda: respaldar wallet.dat. Pero un pago de 1 BTC y un reinicio revelaron el fallo. La copia existía, la clave para los 8.999 BTC de cambio no.
La blockchain nunca perdió las monedas.
La cartera perdió la capacidad de gastarlas.
Esa distinción convierte esta historia de un USB defectuoso en una sobre arquitectura de carteras. Bitcoin temprano no derivaba todas las claves futuras de una semilla recuperable. Una copia era solo una instantánea de las claves existentes al copiar.
Índice
La noche de la pérdida
Una copia de seguridad cuidadosa, un pago propio de 1 BTC y un reinicio con consecuencias duraderas
Stone Man acumuló 9.000 BTC y los movió a un cliente Bitcoin en un Debian live CD. El sistema vivía en memoria, así que apagarlo borraría la cartera activa. Primero copió wallet.dat a una unidad flash.
- 01
Proteger
La cartera está respaldada
El wallet.dat con 9.000 BTC se copia del sistema activo a una unidad flash.
- 02
Autopago
Stone Man se envía cerca de 1 BTC
Mientras comprobaba cuándo se confirmaría otro pago, Stone Man se envió aproximadamente 1 BTC. La cartera gastó la salida completa de 9.000 BTC y creó una nueva clave de cambio para el resto sin avisar.
- 03
Borrar
El sistema activo se apaga
La cartera en memoria que contiene la nueva clave de cambio desaparece antes de actualizar la copia.
- 04
Restaurar
La copia antigua regresa
La blockchain muestra la transacción, pero la cartera restaurada no puede gastar la salida de cambio de 8.999 BTC.
“Nunca imaginé que podría comprometer todo mi saldo.”
Lo que sabemos sobre Stone Man
¿Quién era Stone Man?
La identidad real de Stone Man es desconocida. Su perfil en BitcoinTalk era la cuenta 288. En el foro dijo que había comprado 9.000 BTC con el tiempo, usó Bitcoin en un live CD de Debian y guardó una copia de wallet.dat antes de apagar el ordenador.
No sabemos su nombre real, dónde vivía, a qué se dedicaba ni qué pasó tras el hilo. Las afirmaciones posteriores sobre su identidad no han sido probadas.
Buscando la clave perdida
La búsqueda de la clave comenzó en 2010
Minutos después de que Stone Man pidiera ayuda, otro usuario se ofreció a revisar la antigua cartera. Insti reconstruyó la transacción con herramientas tempranas de Bitcoin de Gavin Andresen. Para recuperar con éxito, el archivo wallet.dat guardado debía contener la clave privada de la dirección de cambio. El análisis de 2010 sugirió que probablemente no la tenía. Sin esa clave, la cadena de bloques podía mostrar dónde estaban las monedas, pero nadie podía moverlas.
El primer intento de recuperar la clave
Los usuarios del foro siguieron ambas salidas de la transacción, pidieron a Stone Man que listara las claves de su monedero y encontraron la dirección de cambio perdida. Pudieron explicar la pérdida, pero no recuperaron la clave.
Una nueva búsqueda en 2026
En 2026, un usuario anónimo del foro afirmó haber probado más de 6,5 millones de claves posibles con una GPU. Ninguna coincidió con la dirección perdida. Dijeron que necesitarían detalles de Stone Man y su antiguo monedero para reducir la búsqueda.
La autopsia de la transacción
Por qué enviar 1 BTC movió los 9.000 BTC
Bitcoin gasta salidas de transacción como unidades completas. La cartera de Stone Man usó una salida de 9.000 BTC, devolvió 1 BTC a la dirección elegida y creó una segunda salida con los 8.999 BTC restantes. Esa segunda salida era cambio, no un pago robado.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgEl fallo oculto
wallet.dat era una instantánea, no una promesa sobre claves futuras
La cartera Bitcoin original almacenaba claves privadas generadas independientemente. Cuando necesitaba una nueva dirección de cambio, podía generar una clave nueva tras hacer la copia. Restaurar el archivo antiguo recuperaba las claves viejas, pero no podía recrear una clave aleatoria posterior.
Un reescaneo de la blockchain podría redescubrir la transacción y mostrar a dónde fueron los 8.999 BTC. Pero no puede generar la clave privada perdida. Visibilidad no es control.
La advertencia llegó primero
Stone Man no fue el primero afectado por el cambio
El 14 de julio de 2010, casi un mes antes del post de Stone Man, otro usuario describió un fallo similar a menor escala. Respaldó una cartera con 1,21 BTC, donó 0,01 BTC, restauró el archivo antiguo y vio caer el saldo a cero.
Para el 21 de julio, los usuarios advertían que una copia antigua podía contener la clave gastada pero no la nueva clave de cambio. El peligro era público antes de la pérdida de 8.999 BTC.
Cómo cambió Bitcoin
De claves sueltas a un keypool, luego a carteras deterministas
La respuesta no fue una solución perfecta inmediata. Bitcoin primero creó un buffer de seguridad de claves futuras. Luego, los diseños de carteras permitieron recuperar familias enteras de claves desde una semilla raíz.
-
Fallo observado
Advertencia de 1,20 BTC
Un usuario restaura una cartera antigua tras donar 0,01 BTC y pierde acceso a la salida de cambio recién creada.
-
Diseño propuesto
Satoshi describe una cola de claves futuras
Las direcciones pre-generadas permiten que una copia contenga claves que la cartera aún no usó.
-
Fallo amplificado
Stone Man pierde la clave de cambio de 8.999 BTC
La misma debilidad arquitectónica se vuelve imposible de ignorar para la comunidad.
-
Buffer de seguridad implementado
Bitcoin 0.3.13.3 incorpora un keypool
Un grupo predeterminado de 100 claves pre-generadas ofrece a las copias un margen limitado de cobertura futura.
-
Estándar determinista
BIP 32 define un árbol de claves a partir de una semilla
Las carteras pueden derivar claves futuras de recepción y cambio desde una raíz recuperable en lugar de almacenar solo claves aleatorias no relacionadas.
-
HD por defecto
Bitcoin Core adopta derivación determinista de claves
Para carteras HD nuevas, una copia correcta respaldada en semilla puede regenerar las claves derivadas.
103849419a9c014a69c76b6f96e48b66cbc838ca
El commit cambió la creación de transacciones para reservar claves de cambio de un grupo predeterminado de 100 claves pre-generadas en lugar de generarlas solo al construir la transacción.
Qué implica esto hoy
Las semillas modernas cambiaron la recuperación, pero no eliminaron la necesidad de copias
Las carteras deterministas jerárquicas derivan muchas claves de una semilla, por lo que el fallo exacto de Stone Man no debería ocurrir si se restaura la semilla y la información de derivación correctas. Bitcoin Core introdujo carteras HD en la versión 0.13. Pero claves importadas, carteras antiguas no HD, rutas de derivación desconocidas, contraseñas perdidas, copias dañadas y procedimientos de recuperación no probados aún pueden dejar fondos inaccesibles.
Sabe qué tipo de copia tienes
Una frase semilla, exportación de descriptor, archivo wallet.dat, copia de hardware wallet y clave privada importada no se restauran igual.
Prueba la recuperación sin mover fondos reales
Verifica que la cartera restaurada derive las direcciones de recepción y cambio esperadas antes de que una emergencia te obligue a adivinar.
Trata las claves importadas como un riesgo separado
Las claves importadas tras la semilla o copia original pueden necesitar exportación propia y no siempre se regeneran con la frase de recuperación.
Migra carteras antiguas valiosas con cuidado
Crea una cartera actual desde material de recuperación nuevo, verifica la copia, envía una pequeña prueba y luego mueve el saldo restante.
La lección duradera
Una copia de seguridad solo es tan completa como el modelo de claves que la respalda
La pérdida de Stone Man no fue una falla en la criptografía de Bitcoin ni un atacante desconocido drenando la cartera. Fue un fallo de diseño de recuperación visible por una transacción común. La red preservó el libro contable; la copia antigua preservó un momento equivocado.
Fuentes primarias y verificación
Sigue el registro del foro, la transacción y el código
Las afirmaciones históricas anteriores se verificaron con posts contemporáneos de BitcoinTalk, el registro público de transacciones, el commit original del keypool, BIP 32 y la documentación actual de Bitcoin Core.
Preguntas frecuentes
¿Perdió Stone Man realmente 8.999 BTC?
La transacción pública gastó una salida de 9.000 BTC y creó salidas de 1 BTC y 8.999 BTC. Stone Man informó que la clave privada para la dirección de cambio de 8.999 BTC no estaba en la copia restaurada, y la dirección no había gastado salidas al verificar este artículo.
¿Por qué la copia wallet.dat de Stone Man no recuperó las monedas?
La copia se creó antes de que la cartera generara la clave privada para la nueva dirección de cambio. Las carteras no deterministas tempranas no podían recrear esa clave aleatoria posterior desde claves antiguas o la blockchain.
¿Fue la salida de 8.999 BTC un hackeo o un pago a un atacante?
No se necesita atacante para explicar la transacción. Los 8.999 BTC eran el cambio de un autopago de 1 BTC de Stone Man. El fallo fue perder la clave privada para gastar ese cambio.
¿Puede ocurrir el mismo problema de copia con una frase semilla moderna?
Una cartera determinista restaurada correctamente puede derivar las claves de recepción y cambio esperadas desde la semilla correcta. La recuperación puede fallar si la semilla es errónea o incompleta, la configuración de derivación es desconocida, las claves se importaron por separado, falta una contraseña o la copia nunca se probó.
¿Sabemos qué pasó con Stone Man?
Stone Man pidió ayuda en el foro, dijo que aún tenía el archivo antiguo de la cartera y respondió preguntas técnicas. Más tarde dejó de publicar. No sabemos por qué ni si siguió intentando recuperar la clave en privado.