diff --git a/README.md b/README.md index 0952d43..7227ca1 100644 --- a/README.md +++ b/README.md @@ -26,7 +26,9 @@ **Cómo usarla.** No hace falta leerla entera de una sentada. Lee las **secciones 1 a 3** para entender qué estás haciendo y por qué, y ten la **4** delante mientras lo haces. Ensaya el proceso completo en una red de pruebas (Sección 6) antes de generar la seed que vaya a custodiar fondos. -**Vigencia.** Escrita en agosto de 2026. Contrasta los pasos técnicos con la documentación oficial de tu dispositivo: **si algo aquí la contradice, gana la fuente oficial.** +**Si tu aparato es una SeedSigner.** Este documento no cubre montarla ni manejarla — para eso hay una [guía dedicada](https://git.bitcointxoko.org/pikaro/guia-seedsigner), libre igual que esta. Los dos documentos son independientes y cada uno se lee solo: este explica **el método**, aquel explica **el aparato**. No hace falta el otro para seguir este. + +**Vigencia.** Escrita en agosto de 2026, revisada en septiembre de 2026. Contrasta los pasos técnicos con la documentación oficial de tu dispositivo: **si algo aquí la contradice, gana la fuente oficial.** --- @@ -38,9 +40,9 @@ 4. [El procedimiento paso a paso](#4-el-procedimiento-paso-a-paso) 5. [Cómo diseñar una passphrase segura](#5-cómo-diseñar-una-passphrase-segura) 6. [Practica primero en una red de pruebas](#6-practica-primero-en-una-red-de-pruebas) -7. [Variables adicionales a decidir](#7-variables-adicionales-a-decidir) -8. [Enseñando esto a otros](#8-enseñando-esto-a-otros) -9. [Checklist final antes de mover fondos reales](#9-checklist-final-antes-de-mover-fondos-reales) +8. [Variables adicionales a decidir](#8-variables-adicionales-a-decidir) +9. [Enseñando esto a otros](#9-enseñando-esto-a-otros) +10. [Checklist final antes de mover fondos reales](#10-checklist-final-antes-de-mover-fondos-reales) **Anexos** @@ -65,11 +67,13 @@ Los números, según la propia Coinkite y los análisis publicados después: | Mk2 y Mk3 (firmware 4.0.1 – 4.1.9) | 128 bits | **≈ 40 bits** | | Mk4, Mk5 y Q (antes del parche) | 128 bits | **≈ 72 bits** | -Galaxy Research rastreó barridos programáticos de **1.596 BTC confirmados** desde unas 7.300 direcciones, cifra que sube hacia los 2.055 BTC si se confirma una cuarta oleada detectada el 3 de agosto. TRM Labs estimó el daño en torno a los 116 millones de dólares. +Galaxy Research rastreó barridos programáticos de **más de 1.778 BTC confirmados** desde **más de 5.200 direcciones** —tres oleadas grandes más 41 huellas menores—, cifra que sube hacia los 2.417 BTC si se confirma la cuarta oleada. En dólares: unos 112 millones confirmados, y hasta 151 millones si se confirma todo. TRM Labs había estimado el daño en torno a los 116 millones. *(Datos de Galaxy Research al 14 de agosto de 2026.)* -Conviene detenerse en lo que significa "7.300 direcciones": son miles de personas que hicieron lo correcto —sacar su bitcoin de un exchange y custodiarlo ellas mismas, con un aparato de gama alta comprado precisamente para eso— y se levantaron un día con la cartera vacía. **No hay recuperación, no hay seguro y no hay a quién reclamar.** El barrido fue automático y se ejecutó contra todas las direcciones vulnerables a la vez: no hubo forma de reaccionar a tiempo. +**El ataque parece haberse detenido:** Galaxy no registró actividad confirmada después del **6 de agosto de 2026**, lo que sugiere que los atacantes agotaron los objetivos fáciles o que los usuarios vulnerables migraron a tiempo. Eso no cambia nada para quien no haya migrado todavía: la seed sigue siendo predecible mientras exista. -> **Las cifras de robo son de agosto de 2026 y siguen moviéndose.** Si citas números, di de cuándo son y enlaza la fuente. La magnitud es lo que importa, no el decimal. +Conviene detenerse en lo que significan esas cifras: son **miles de personas** que hicieron lo correcto —sacar su bitcoin de un exchange y custodiarlo ellas mismas, con un aparato de gama alta comprado precisamente para eso— y se levantaron un día con la cartera vacía. **No hay recuperación, no hay seguro y no hay a quién reclamar.** El barrido fue automático y se ejecutó contra todas las direcciones vulnerables a la vez: no hubo forma de reaccionar a tiempo. + +> **Las cifras de robo se han movido, y pueden volver a moverse.** La primera versión de esta guía daba 1.596 BTC y 7.300 direcciones; un mes después Galaxy confirmaba más BTC repartidos entre **menos** direcciones, porque cambió el método de conteo. Si citas números, **di siempre de cuándo son y enlaza la fuente**. Lo que importa es la magnitud, no el decimal — y la magnitud no ha cambiado: es el mayor robo a una hardware wallet que se conoce. ### 1.2 El detalle que debería incomodarnos @@ -589,7 +593,7 @@ La passphrase **no tiene checksum ni corrección de errores**. Un solo carácter No se puede tener confianza real en un procedimiento que nunca se ha ejecutado de principio a fin. Las redes de prueba son redes separadas de la principal, con sus propios nodos y mineros, donde las monedas no tienen valor económico. -**Cuál usar (situación en agosto de 2026):** +**Cuál usar (situación en septiembre de 2026):** - **Signet** — la mejor para practicar custodia: bloques regulares y predecibles, sin la congestión ni las reorganizaciones masivas de testnet3. ⚠️ **Pero no todos los dispositivos la soportan.** - **Testnet4** — sustituye a testnet3 y da condiciones más parecidas a mainnet. Soportada por Sparrow desde la v1.9.1. @@ -608,7 +612,43 @@ No se puede tener confianza real en un procedimiento que nunca se ha ejecutado d --- -## 7. Variables adicionales a decidir +## 7. Si pierdes el aparato, el papel, o parte de él + +Es la pregunta que todo el mundo se hace tarde y conviene contestar pronto, porque la respuesta cambia dónde pones el esfuerzo. + +| Qué pierdes | Gravedad | Qué haces | +|---|---|---| +| **El aparato** (roto, perdido, robado, apagado) | **Ninguna.** No había nada dentro | Cargas tus palabras en otro dispositivo compatible, o en Sparrow, y recuperas todo | +| **El fabricante desaparece** | Ninguna | Tu seed es un estándar (BIP-39), no un formato propietario. No dependes de que la empresa siga viva | +| **El aparato encendido y con la seed cargada** | **Seria.** No hay elemento seguro que aguante eso | Mueve los fondos desde otra copia de la seed, inmediatamente | +| **La passphrase** | **Total.** Es una wallet distinta y vacía sin ella | Nada. Por eso se guarda por duplicado y separada | +| **El papel de la seed** | **Total, si no hay otra copia** | Si aún controlas los fondos: genera una wallet nueva y muévelos **hoy** | + +**La conclusión operativa:** el aparato es reemplazable y el papel no. Todo el esfuerzo de custodia va al backup —cuántas copias, dónde, aguantando qué— y no a proteger un dispositivo que cuesta lo que cuesta y no guarda nada. + +### 7.1 Copias múltiples, y el error de partir la seed + +Lo sensato es **más de una copia completa del backup, en sitios separados**, pensando en fuego, agua e inundación además de en ladrones. Con la passphrase guardada aparte, cada copia por sí sola no basta para gastar, así que multiplicar copias no multiplica el riesgo en la misma medida. + +> 🔴 **Lo que NO se hace: partir las 24 palabras en trozos.** «Ocho palabras en casa de mi hermano, ocho en el banco, ocho aquí» suena a que cada trozo no vale nada. **Es falso.** Quien consiga 16 de las 24 no se enfrenta a un problema imposible: ha reducido el espacio de búsqueda a algo que puede recorrerse. Partir la seed a mano no reparte el secreto, **lo debilita en cada trozo a la vez que multiplica las formas de perderlo entero**. Si quieres repartir de verdad, la herramienta correcta es un multisig o Shamir — no unas tijeras. + +### 7.2 Shamir (SLIP-39): qué es y por qué esta guía no lo usa + +**Shamir Secret Sharing** hace bien lo que el párrafo anterior hace mal: divide el secreto en N partes de las que hacen falta M, y —esto es lo importante— **con M-1 partes no tienes absolutamente nada**. Matemáticamente es elegante y resuelve el problema real de tener un único papel que puede arder. + +Aun así, aquí no se recomienda, por tres razones que encajan con el resto del documento: + +1. **Te ata a un ecosistema.** SLIP-39 **no es BIP-39**: no puedes cargar esas partes en cualquier wallet. El soporte es estrecho y gira en torno a un fabricante concreto. Una guía que se pasa cuatro secciones argumentando que no dependas de un fabricante no puede recomendar un formato de backup que te ata a uno. +2. **Crea un momento de exposición que antes no existía.** Para gastar hay que **juntar las partes y reconstruir la seed** en un aparato, en un instante concreto. Ese instante es un punto único de fallo nuevo — justo lo que la reparto pretendía eliminar. +3. **Más complejidad es más formas de perderlo todo.** Hay que documentar cuántas partes hay, dónde, cuál es el umbral y cómo se reconstruye — y quien te herede tiene que entenderlo. El fallo más común de los backups sofisticados no es que los rompan: es que nadie sabe usarlos cuando hacen falta. + +**Qué hacer en su lugar.** Para la mayoría, **varias copias completas repartidas geográficamente + passphrase guardada aparte** da una protección parecida con muchísima menos superficie de error. Y si de verdad necesitas que ninguna ubicación baste por sí sola, **multisig** es la respuesta madura: soporte amplio, formato abierto, y sin momento de reconstrucción — cada llave firma desde donde está y nunca se juntan. + +*(Si eliges Shamir con los ojos abiertos, que sea SLIP-39 estándar y nunca un esquema casero, y ensaya la reconstrucción entera antes de confiarle nada.)* + +--- + +## 8. Variables adicionales a decidir Antes de comprometerte a una configuración final, decide conscientemente sobre estos puntos. Varios son relevantes solo si en el futuro montas un multisig, que queda fuera del alcance de esta guía: @@ -620,7 +660,7 @@ Antes de comprometerte a una configuración final, decide conscientemente sobre --- -## 8. Enseñando esto a otros +## 9. Enseñando esto a otros Las tres ideas que más importa transmitir, si solo puedes transmitir tres: @@ -637,7 +677,7 @@ Y tres avisos que valen siempre, den igual el aparato y el año: Y una que va contigo: **nadie debería seguir esta guía a ciegas, incluida esta guía.** Contrasta con la documentación oficial de tu dispositivo. Ese hábito es exactamente lo que habría limitado el daño del incidente. -## 9. Checklist final antes de mover fondos reales +## 10. Checklist final antes de mover fondos reales - [ ] Dispositivo comprado en el canal oficial o un distribuidor listado por el fabricante. **Nunca de segunda mano.** Precintos y embalaje revisados al recibirlo (Paso 0a). - [ ] Software descargado de la fuente oficial. Si hiciste el Paso 0b: firma verificada y huella contrastada en varias fuentes independientes. @@ -780,6 +820,8 @@ Desde la v0.7.0 las imágenes son **reproducibles**: puedes compilarlas desde el **Qué le falta:** hay que montarla (es un proyecto de voluntarios, no un producto con soporte), no tiene elemento seguro ni resistencia a manipulación física, y su seguridad viene de ser air-gapped y no guardar nada — no de aguantar a alguien que se haga con el aparato encendido. +> **Montarla y manejarla tiene guía propia:** [guia-seedsigner](https://git.bitcointxoko.org/pikaro/guia-seedsigner) — materiales, montaje, verificación del software, generación de la seed con dados en el aparato, rutina de firma y averías. Este anexo se queda en lo que necesitas para aplicar **el método** de las secciones 1 a 4. + --- ### Anexo C: BitBox02