Guía en castellano sobre cómo generar y verificar tus propias llaves de Bitcoin
sin depender del generador de aleatoriedad de ningún fabricante, escrita a raíz
del fallo del RNG de Coldcard de julio de 2026.
El método (secciones 1-4) es agnóstico de dispositivo; los pasos concretos de
cada aparato viven en anexos intercambiables, y la elección de dispositivo se
resuelve con criterios en vez de con una lista de marcas.
Datos del incidente verificados contra fuentes primarias a 7 de agosto de 2026.
*Cómo generar y comprobar tus llaves de Bitcoin sin depender de que ningún fabricante acierte.*
> Guía en castellano, libre y verificable. **[CC BY-SA 4.0](LICENSE)** — cópiala, tradúcela y adáptala.
> ¿Un error, un dato desactualizado, un paso que no funciona en tu aparato? [Corrígelo](CONTRIBUTING.md), no hace falta pedir permiso.
---
## Antes de empezar
> ### 🔴 ¿Puedes estar afectado por el fallo de Coldcard?
>
> **No leas esto entero: ve al [Anexo A](#anexo-a-qué-hacer-si-puedes-estar-afectado).** Y si solo retienes una frase del documento, que sea esta: **actualizar el firmware NO arregla una seed ya generada** (tu seed son las 12 o 24 palabras que te dio el aparato). Protege las nuevas. La excepción, según el propio fabricante: **50 o más tiradas de dado** justas y privadas dejan tu seed fuera de riesgo — que es el método que enseña esta guía.
**Antes de nada, la palabra que más va a salir.** Tu **seed** (o *semilla*) son las **12 o 24 palabras en inglés** de las que se derivan matemáticamente todas tus claves y todas tus direcciones. No están "dentro" del aparato: si se rompe o lo pierdes, cargas esas palabras en otro compatible y recuperas todo. Y al revés — quien las tenga, tiene tus fondos. Por eso **el papel donde las escribes es el objeto importante, no el dispositivo**.
**Para quién es.** Para quien quiera custodiar sus llaves y entender *por qué* cada paso importa, no solo seguirlos. No hace falta saber criptografía ni programar. Los pasos **[avanzado]** piden terminal: puedes saltártelos y seguir teniendo una custodia sólida.
**De qué va esto.** De **entender la entropía y saber generarla tú**. Ese es el tema, y todo lo demás está al servicio de eso. No es la guía de un aparato: el método (secciones 1-4) vale para cualquier hardware wallet que acepte entropía propia, y los anexos solo te dicen dónde está cada menú en el tuyo. Una guía atada a un fabricante tiene el mismo fallo de diseño que una custodia atada a un fabricante.
**Alcance.** Wallet **singlesig** con entropía propia y passphrase, que es lo adecuado para la mayoría. El **multisig** se menciona como concepto, pero su procedimiento queda fuera: montarlo mal es más peligroso que un singlesig bien hecho.
**Qué necesitas.** Una hardware wallet que acepte entropía propia · un dado de seis caras o una baraja · papel y bolígrafo (idealmente placa metálica para el backup definitivo) · un ordenador con [Sparrow Wallet](https://www.sparrowwallet.com/download/) · un par de horas sin prisa.
**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.**
---
## Índice
1. [La premisa: asume que tu dispositivo puede fallar](#1-la-premisa-asume-que-tu-dispositivo-puede-fallar)
2. [Fundamentos de entropía: qué significan los bits y por qué importan](#2-fundamentos-de-entropía-qué-significan-los-bits-y-por-qué-importan)
3. [Por qué la entropía propia funciona](#3-por-qué-la-entropía-propia-funciona)
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)
**Anexos**
- [**Anexo A: qué hacer si puedes estar afectado**](#anexo-a-qué-hacer-si-puedes-estar-afectado) ← *empieza aquí si tus fondos pueden estar en riesgo*
- [Anexos B y C: procedimientos por dispositivo](#anexos-b-y-c-procedimientos-por-dispositivo) — *no son recomendaciones de compra*
- [**Anexo D: cómo evaluar un dispositivo**](#anexo-d-cómo-evaluar-un-dispositivo-que-no-está-en-esta-guía) ← *empieza aquí si estás decidiendo cuál comprar*
- [Fuentes y atribución](#fuentes-y-atribución)
---
## 1. La premisa: asume que tu dispositivo puede fallar
### 1.1 Qué pasó exactamente
El 30 de julio de 2026, Coinkite publicó un aviso de seguridad: un fallo en el firmware de Coldcard hacía que la generación de seeds usara un generador de números aleatorios **por software** en lugar del generador **por hardware** del microcontrolador. La entropía real de las claves quedó muy por debajo de la anunciada, y un atacante pudo reconstruirlas sin tocar el dispositivo físico.
Los números, según la propia Coinkite y los análisis publicados después:
| 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.
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.
> **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.
### 1.2 El detalle que debería incomodarnos
El fallo se introdujo en **marzo de 2021** y no se detectó hasta julio de 2026: **más de cinco años latentes**. Firmware auditado, empresa reputada, comunidad técnica atenta, **código abierto desde siempre** — y aun así, nadie lo vio.
Y la causa raíz no fue un fallo de criptografía. Fue una macro del preprocesador de C.
En 2021, Coldcard migró sus operaciones de curva elíptica a `libsecp256k1` (la misma implementación que usa Bitcoin Core). Decisión criptográfica correcta. Pero en esa migración, la generación de la seed pasó de `ckcc.rng_bytes()` a `ngu.random.bytes()`, y esa ruta acababa resolviendo a la implementación de respaldo **por software** de MicroPython en lugar de al TRNG por hardware de Coldcard.
¿Por qué no lo detectó la compilación? Porque la guarda del código usaba `#ifndef`, que comprueba si una macro **está definida**, no si su valor es distinto de cero. Coinkite había definido `MICROPY_HW_ENABLE_RNG` como **0**, creyendo que así desactivaba ambas implementaciones. Como la macro *estaba definida*, el `#error` de seguridad nunca saltó. Y como ambas implementaciones tenían la misma firma de función, el enlazador cogió la equivocada sin quejarse.
El código del TRNG correcto **estaba en el binario**. Simplemente, la ruta de generación de la seed nunca llegaba a él.
**Y aquí está la lección, que no es la que parece.** No hubo un "generador de respaldo" que alguien decidiera poner por si acaso: la intención era usar el TRNG y solo el TRNG, y esa macro estaba puesta precisamente para desactivar la vía por software. Lo que falló no fue una decisión, fue que **nadie comprobó nunca qué implementación llamaba de verdad la función más crítica del producto**. Su propio análisis lo admite: la revisión verificó que el código correcto estaba presente, *pero no verificó a qué símbolo resolvía ni si la generación de la seed llegaba hasta él*.
Dicho de otra forma: **ni quien escribió el firmware sabía qué código estaba ejecutando su propio aparato.** Durante cinco años.
Por eso el remedio no es leer más código, es **comprobar que el código que crees que se ejecuta es el que se ejecuta** — que es exactamente lo que hace un vector de prueba (Sección 3.3): metes una entrada conocida y miras si sale lo que tiene que salir. No verifica intenciones, verifica comportamiento.
> Coinkite añade un detalle que merece pensarse despacio: asumen que alguien usó una IA para revisar versiones antiguas del firmware y así encontró el fallo. Ellos mismos habían pasado uno de los mejores modelos disponibles por su código unas semanas antes, y no encontró nada. Sus palabras: *"atacantes y defensores tienen las mismas herramientas de IA, pero hoy no nos ayudó a nosotros, solo a los malos."*
### 1.3 Qué falló y qué no
Es tentador leer esto como "la autocustodia falló, mejor un exchange". Conviene ser precisos:
- **No falló** el concepto de autocustodia.
- **No falló** la criptografía de Bitcoin (BIP39, derivación de claves, curva elíptica).
- **Falló la pieza de la que cuelga todo lo demás**: el origen de la aleatoriedad. Si esa es predecible, ninguna de las capas que van encima sirve para nada, por bien hechas que estén. Y falló en silencio durante más de cinco años, en un producto de gama alta, en la empresa que más ha presumido de seguridad.
Que la autocustodia no sea el problema no convierte esto en un accidente menor. Es lo más grave que le ha pasado a una hardware wallet.
### 1.4 La pregunta útil
Preguntar "¿qué dispositivo es seguro?" tiene un problema: cualquier respuesta caduca y no la puedes verificar tú. "No se ha encontrado ningún fallo" y "no hay ningún fallo" no son la misma frase.
La pregunta que sí se puede responder es:
> **Si mi dispositivo tiene mañana un fallo que hoy nadie conoce, ¿pierdo mis fondos?**
Esta guía asume que sí. No por fatalismo, al contrario: asumirlo permite diseñar una custodia donde ese fallo no sea catastrófico. Un exchange no resuelve nada — cambia un fallo técnico que puedes mitigar por un riesgo de contraparte que no controlas.
### 1.5 Los tres pilares
1.**Genera tú la entropía.** Si los bits de tu clave los produces con dados o cartas, el RNG del dispositivo deja de importar. No hace falta confiar en que funciona bien: lo haces irrelevante.
2.**Verifica el cálculo contra implementaciones independientes.** El paso de entropía a palabras sí lo hace el software, pero es matemática pública y reproducible. Si tres implementaciones escritas por gente distinta en lenguajes distintos dan el mismo resultado, un fallo oculto tendría que estar en las tres a la vez.
3.**No dependas de un solo dispositivo ni de un solo fabricante.** Añade una passphrase, que es una capa independiente de la que falló. Y si el patrimonio lo justifica, un multisig con dispositivos de fabricantes distintos.
### 1.6 Por qué "es código abierto" no es suficiente
Este punto es incómodo y hay que decirlo, porque es donde casi toda la divulgación sobre hardware wallets miente por omisión.
El firmware de Coldcard **siempre fue abierto y públicamente auditable**. El repositorio estaba ahí. Cualquiera podía leerlo. Y el fallo estuvo cinco años delante de todo el mundo.
El código abierto es una condición **necesaria** para poder verificar, pero no es **suficiente** para estar verificado. La diferencia entre "auditable" y "auditado" es la que separa a los que perdieron fondos de los que no.
Y hay un escalón más, que es el que casi nadie sube: **"auditado" tampoco basta, porque leer el código no te dice cuál se ejecuta.** Aquí hubo revisión, y la revisión miró el código correcto — el que estaba en el repositorio, el que cualquiera podía leer. El que corría en el aparato era otro.
Por eso el pilar 1 no dice "usa software abierto". Dice **genera tú la entropía**. No porque el código abierto no valga, sino porque el objetivo no es tener un código en el que confiar, sino **reducir la cantidad de código en la que tienes que confiar**. Tu tirada de dado no la puede estropear ninguna macro del preprocesador.
### 1.7 Hasta dónde llega esto (y hasta dónde no)
Ninguna guía puede prometer "cero confianza", y desconfía de la que lo haga. Estos tres pilares eliminan la dependencia del generador del fabricante, del software de conversión de un solo proyecto y de un único dispositivo.
Sigue requiriendo confianza lo que un usuario no puede auditar de forma realista: la criptografía de curva elíptica, el compilador que construyó el firmware, el silicio del chip, y **que el aparato que te llegó sea el que salió de fábrica** (Paso 0a). La diferencia es que ahora son las **únicas** capas que quedan, en vez de estar sumadas a un RNG opaco que sabemos que puede fallar en silencio durante años.
---
## 2. Fundamentos de entropía: qué significan los bits y por qué importan
### 2.1 La entropía se mide en bits, y cada bit dobla las posibilidades
Un bit es una moneda al aire: 2 resultados. Dos bits, 4. La relación es exponencial, así que cada bit **duplica** las combinaciones que un atacante tendría que probar.
256 bits no es "el doble de seguro" que 128: es 2^128 veces más combinaciones. Ambos son inviables por fuerza bruta **si la entropía es real**. La diferencia práctica aparece justo cuando no lo es — que es lo que pasó.
### 2.2 Qué salió mal en Coldcard, en números concretos
¿Qué tan grave es pasar de 128 a 40 bits reales? No es "un poco menos seguro". Cada bit perdido divide la dificultad a la mitad, así que perder 88 bits equivale a dividirla entre 2^88 — un factor con 26 ceros. Es la diferencia entre un espacio de búsqueda imposible de recorrer con toda la potencia de cálculo del planeta y uno que herramientas modernas pueden explorar sistemáticamente.
Y los ≈72 bits de Mk4/Mk5/Q no son un aprobado raspado: son un espacio de búsqueda al alcance de quien tenga recursos, y el coste de recorrerlo baja cada año. La consecuencia práctica es que el propio fabricante indicó a esos usuarios que **migraran también**, no que estuvieran a salvo.
> **Sobre modelos y versiones concretos.** Durante el incidente circuló información contradictoria que se fue corrigiendo con los días. Antes de tomar decisiones sobre un dispositivo concreto, consulta el aviso oficial en [blog.coinkite.com](https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/) en lugar de fiarte de este resumen ni de ningún otro de segunda mano.
### 2.3 Cuánta entropía aporta la passphrase
La passphrase suma su propia entropía, matemáticamente independiente de la de la seed, pero **solo si la generas con un método realmente aleatorio**:
| Frase inventada por un humano | ≈ 1-3 bits **por carácter** | — | — |
Una frase inventada "de la cabeza", aunque sea larga, aporta muchísima menos entropía de la que su longitud sugiere: el lenguaje natural es predecible. Es la misma razón por la que en la Sección 5 recomendamos generar la passphrase con dados, igual que la seed.
**La conclusión práctica:** una seed de 24 palabras (256 bits) más una passphrase de 5-6 palabras generadas por dados (55-77 bits adicionales) te sitúa muy por encima de cualquier escenario de ataque conocido. Y, a diferencia de Coldcard, cada uno de esos bits es real y verificable por ti, no una promesa de firmware.
---
## 3. Por qué la entropía propia funciona
### 3.1 Qué resuelve exactamente
Una seed de 24 palabras necesita **256 bits** (más 8 de checksum). Un dado de 6 caras aporta log2(6) ≈ 2,58 bits por tirada: con **99 tiradas** llegas a los 256.
Si generas esos bits tú, **la seguridad de tu clave deja de depender del RNG de ningún aparato**. Ningún fallo de firmware puede "silenciar" tu entropía, porque el firmware nunca la generó — solo la *procesó*.
**Y esto no es teoría: es lo que salvó a gente en el incidente real.** Coinkite lo dejó por escrito en su propio aviso:
> - **50 a 98 tiradas** independientes y privadas: la entrada de dados aportó por sí sola al menos 128 bits.
> - **99 o más tiradas** independientes y privadas: la entrada de dados aportó aproximadamente 256 bits.
> - *"Si introdujiste al menos 50 tiradas justas e independientes, y las tiradas no se registraron ni se expusieron, no consideramos la seed resultante en riesgo por este problema de RNG."*
Quien tiró el dado no perdió nada. Con el firmware roto, con el fabricante equivocado, con cinco años de fallo latente. Es el argumento más fuerte que tiene esta guía y no es nuestro: es del propio fabricante que falló.
> Fíjate en el matiz de "privadas" y "no registradas": la secuencia de tiradas **es material de clave**. Nunca la fotografíes, ni la guardes en digital, ni la introduzcas en un ordenador conectado.
### 3.2 Qué le sigues confiando al software (y cómo verificarlo)
Con dados, el software ya no genera tu aleatoriedad. Pero sigue haciendo dos cosas: convertir tus tiradas en bits, y esos bits en palabras y direcciones. Eso es matemática pública, determinista y reproducible — y ahí es donde entra el pilar 2.
**Y esa conversión no es trivial, aunque lo parezca.** Seis caras no caben en un número entero de bits: 3 bits dan 8 combinaciones y el dado solo produce 6. Si asignas cada cara a un valor de 3 bits, hay **dos combinaciones que nunca vas a generar**, y estás obteniendo 2,585 bits reales por tirada mientras crees que tienes 3. En 99 tiradas eso son **41 bits menos de los que piensas**.
Las dos formas correctas de resolverlo son descartar las combinaciones sobrantes (*rejection sampling*) o tratar la secuencia como un número en base 6 y convertirlo entero a binario. Tu dispositivo hace una de las dos por ti, y **este es exactamente el tipo de fallo que caza la verificación cruzada**: no un error visible, sino una conversión que produce palabras de aspecto perfectamente normal con menos entropía detrás de la que crees.
Es también el motivo por el que **hacer la conversión a mano es mala idea** salvo que sepas muy bien lo que haces: son cientos de operaciones y el error no avisa.
Tres formas de verificarlo, de menos a más esfuerzo:
1.**Vectores de prueba conocidos** (Sección 3.3). Diez minutos, riesgo cero, sin terminal. Es la verificación con mejor relación esfuerzo/certeza de toda la guía.
2.**Ensayo completo con una seed desechable** [avanzado]. Es el sustituto de "verificar tu seed real", y es mejor: haces el proceso entero —99 tiradas nuevas, con el mismo dado y el mismo método— con una seed que **jamás va a custodiar nada**, y compruebas que el dispositivo, un script de línea de comandos y una herramienta web de terceros producen el mismo **mnemónico** (la lista de palabras), el mismo **fingerprint** (ocho caracteres que identifican la wallet sin revelar nada de ella, ver Paso 3) y las mismas direcciones. Como esa seed nunca tendrá fondos, puedes teclearla en tu ordenador de siempre sin ningún riesgo.
Y cubre un ataque que el vector de prueba solo no cubre: un dispositivo malicioso podría **reconocer el vector público** y portarse bien únicamente con él. Tus tiradas de ensayo no las puede distinguir de las de verdad, así que si las convierte bien, no tiene forma de hacer trampas selectivas después.
3.**Compilación reproducible**: compilar el firmware desde el código fuente y comprobar que el binario es byte a byte idéntico al publicado. Elimina la confianza en quien firma las releases.
> ### 🔴 La regla que no tiene excepciones
>
> **Una seed que vas a usar no se teclea NUNCA en un ordenador, un móvil, una web ni ningún entorno digital.** Ni en uno air-gapped, ni en una sesión efímera, ni "solo para comprobar", ni por un segundo.
>
> Solo se tecleen en un ordenador las **seeds de prueba**: las públicas de los vectores, o las que generas para ensayar y que no van a custodiar nada jamás. Nunca una que tenga fondos, ni una que planees usar algún día.
>
> **Por qué somos más estrictos que otras guías.** Verás por ahí —incluso en documentación oficial de proyectos serios— la recomendación de verificar tu seed real en un ordenador air-gapped y efímero, tipo una sesión de Tails que destruyes después. El problema no es la idea: es que **tú no puedes comprobar que se cumplió**. No puedes verificar que no hubo memoria de intercambio en disco, que el firmware de un USB no persistió nada, que la radio estaba realmente desactivada, ni qué hace el procesador por debajo del sistema operativo. Es un consejo que suena riguroso y traslada el riesgo a un paso que el lector no puede auditar — justo el patrón que esta guía critica en todo lo demás.
>
> Y es innecesario, porque el **ensayo con seed desechable** te da la misma certeza sin exponer nada.
### 3.3 Vectores de prueba: comprueba tu propio dispositivo
Esta es probablemente la verificación más práctica de toda la guía, y muy poca gente la conoce: varios proyectos publican **secuencias de prueba conocidas con su resultado esperado**. Las introduces en tu dispositivo y compruebas que produce exactamente las palabras correctas.
**Vector de SeedSigner — 99 tiradas → 24 palabras:**
Con fingerprint `8d9cced8` y este **zpub** — la clave pública extendida, con la que tu programa de wallet genera todas tus direcciones y ve tu saldo, pero **sin poder gastar**:
> ⚠️ **Estos vectores son específicos de la implementación de SeedSigner.** Cada dispositivo puede procesar la secuencia de dados de forma distinta (SHA-256 del string de tiradas, mapeo directo, orden de bits...), así que **un resultado distinto en otro aparato no significa que esté roto**. Busca el vector de prueba oficial de *tu* dispositivo en la documentación de su proyecto: los anexos B y C indican dónde está el de los que cubre esta guía.
**Por qué esto importa tanto:**
- Es completamente seguro: son seeds públicas. No las vas a usar, solo compruebas que tu instalación produce el resultado esperado.
- Verifica **tu** dispositivo concreto, con **tu** versión de firmware concreta, antes de generar la seed que va a proteger tus fondos.
- **Sirve incluso a posteriori:** si ya generaste una seed real pero no anotaste tu secuencia de tiradas, este test confirma que el código de conversión de tu dispositivo funciona. Si el vector conocido da el resultado correcto, tu seed real —generada con el mismo código en el mismo dispositivo— también se generó correctamente.
Puedes además cargar el vector de 12 palabras en Sparrow y comprobar que el fingerprint coincide con `8d9cced8`, verificando de paso toda la cadena de derivación.
### 3.4 Los dos métodos: dados→bits y dados→palabras
Existen dos enfoques válidos, y ninguno es superior en seguridad: ambos producen 256 bits generados por ti.
**Método A — dados a bits** (el que usa SeedSigner, entre otros). Tiras 99 veces, introduces la secuencia, y el dispositivo la convierte en las 24 palabras.
**Método B — dados a palabras** (documentado por BitBox). Los dados eligen **las palabras directamente** de una tabla de las 2048 palabras BIP39:
- Lanzas 5 dados y una moneda. Los dados que salgan 5 o 6 se relanzan hasta dar un número del 1 al 4.
- La combinación da 4⁵ × 2 = **exactamente 2048** posibilidades, justo el tamaño de la lista BIP39. Cada palabra sale con la misma probabilidad, sin sesgo y sin desperdiciar entropía.
- Repites para las primeras 23 palabras. La 24 no la eliges tú: es en parte un checksum de las anteriores. Introduces las 23 y el dispositivo te muestra las 8 opciones válidas; eliges una al azar.
- La aritmética llega al mismo destino: 23 × 11 = 253 bits, más 3 bits al elegir entre 8 opciones = **256 bits**.
| | A · Dados → bits | B · Dados → palabras |
|---|---|---|
| Material extra | Ninguno | Tabla impresa |
| Tiradas | 99 | ~115-140 (por los relanzamientos) |
| Papel del software | Convierte bits en palabras | Solo calcula la palabra 24 |
El método B reduce un poco más la superficie de software, a cambio de necesitar la tabla impresa.
Necesitas la tabla de las 2048 palabras impresa. BitBox publica una en [su documentación](https://bitbox.swiss/bitbox02/BitBox_Diceware_HowTo.pdf), con tarjeta de backup incluida; sirve con cualquier wallet que permita teclear las palabras a mano, no solo con la suya.
**Un detalle del método B:** aquí **no hace falta anotar las tiradas**. En el método A la secuencia es lo que te permite reproducir la seed en herramientas independientes; aquí el dado es solo un índice, y en cuanto tienes la palabra ya no sirve para nada. Anotarlas deja tu seed escrita dos veces en el mismo papel a cambio de nada. Úsalas como nota de trabajo y destruye esa hoja.
> Vale la pena señalar la honestidad del propio fabricante en ese documento: abre diciendo que no necesitas hacerlo, y explica que la BitBox02 combina cinco fuentes de entropía. Y aun así ofrece el método, porque una hardware wallet debería ser una herramienta de soberanía personal. Es exactamente el planteamiento de esta guía: no se trata de asumir mala fe del fabricante, sino de no depender de que acierte.
### 3.5 Métodos que esta guía no recomienda
**El RNG del dispositivo, a secas.** Es lo que falló. Aunque el firmware esté parcheado hoy, es la capa que no puedes verificar.
**Generación por imagen** (SeedSigner y algún otro la ofrecen: fotografiar algo con la cámara y combinar los píxeles con fotogramas de previsualización, número de serie y tiempo de encendido). Es rápida y cómoda, pero tú no generas ni controlas esa entropía de forma externa: depositas confianza en el algoritmo del propio dispositivo para extraerla y combinarla correctamente. Con dados, la fuente es 100% externa y el software solo hace un cálculo determinista y verificable por terceros.
**Cualquier generador de aleatoriedad en un navegador o en el móvil.** Da igual lo bien hecho que esté o quién lo firme: no puedes auditar qué hace con tus bits, ni si el navegador los guarda en algún sitio. Los generadores de software son exactamente la capa que falló en Coldcard. Para aprender y practicar valen; para producir la seed que va a custodiar tu dinero, nunca.
### 3.6 Qué es responsabilidad tuya (y no de las matemáticas)
- Que el dado no esté groseramente descompensado. **Y esto preocupa a mucha más gente de la que debería**, así que van los números:
| Si el 6 sale... | Bits reales en 99 tiradas | Pierdes |
|---|---|---|
| lo que le toca | 255,9 | — |
| un 13% de más | 255,7 | 0,3 bits |
| un 50% de más | 252,7 | 3,3 bits |
| **el doble de lo que debería** | 244,2 | 11,8 bits |
Un dado que saque el seis **el doble de veces de lo normal** —algo que notarías a simple vista— te deja en 244 bits. Sigues astronómicamente fuera del alcance de cualquiera. Para perder los 88 bits que perdió Coldcard necesitarías un dado que prácticamente solo sacara una cara.
**Conclusión: un dado corriente vale.** Tíralo con ganas sobre una superficie donde ruede, y olvídate. El sesgo físico es el riesgo más pequeño de esta lista, y el que menos merece tu atención comparado con los tres siguientes.
- Anotar y transcribir las tiradas correctamente.
- Que las tiradas sean **privadas**: sin cámaras, sin testigos, sin registro digital.
- Verificar la firma y el checksum del firmware oficial antes de instalarlo (Paso 0b).
*Los pasos son los mismos en cualquier dispositivo. Dónde está cada menú, cómo se introducen las tiradas y qué vector de prueba usar, en el anexo de tu aparato ([B: SeedSigner](#anexo-b-seedsigner) · [C: BitBox02](#anexo-c-bitbox02) · [E: otros](#anexo-d-cómo-evaluar-un-dispositivo-que-no-está-en-esta-guía)).*
### Paso 0 — Preparación
- [ ] Hardware wallet que permita entropía propia.
- [ ] Un dado físico de 6 caras bien equilibrado. Si no tienes, una baraja también sirve (Paso 1b).
- [ ] Papel y bolígrafo (o placa metálica para el backup final).
- [ ] [Sparrow Wallet](https://www.sparrowwallet.com/download/) instalado (puede estar online: la clave privada nunca sale del dispositivo).
- [ ] Entorno tranquilo, sin cámaras ni testigos.
> **Descarga la imagen o firmware correcto para tu hardware.** Varios proyectos publican variantes que no son intercambiables (por modelo de placa, por track de release). Instalar la que no es puede dejar el dispositivo sin arrancar — o, peor, dejarte en una versión que creías parcheada y no lo está. Hay fabricantes que mantienen dos líneas de firmware en paralelo, y sus números **no** son comparables entre sí: una versión 6.x de una línea puede ser más antigua que una 5.x de la otra. Mira la línea, no solo el número.
### Paso 0a — De dónde viene el aparato **[esencial]**
Antes de tocar nada: **el dispositivo que tienes en la mano tiene que ser el que salió de fábrica.** Es una amenaza distinta de todo lo demás que cuenta esta guía —aquí no falla el fabricante, falla lo que pasó entre él y tú— y ninguna cantidad de tiradas de dado te protege de ella.
**Compra solo en el canal oficial del fabricante o en un distribuidor que él mismo liste.** Nada de marketplaces genéricos, revendedores no listados ni anuncios de particulares.
> 🔴 **No compres una hardware wallet de segunda mano. Nunca. Por ningún precio.**
>
> El peligro no es el obvio —un aparato con una seed ya cargada, que verías— sino el que no se ve: **firmware modificado o un implante en el hardware**. Un dispositivo manipulado puede enseñarte unas palabras y guardar otras, filtrar tu seed por un canal que no conoces, o comportarse perfectamente durante meses. Y resetearlo no arregla nada, porque lo que está tocado es el software de debajo o el propio circuito.
>
> Es la excepción a la regla de "lo importante es el papel, el aparato es reemplazable": **el aparato es reemplazable, pero tiene que ser confiable el día que lo estrenas.**
**Al recibirlo:** revisa precintos y embalaje contra las fotos de la web del fabricante, y desconfía de cualquier cosa que venga ya rellenada —sobre todo una hoja de recuperación con palabras escritas, que es una estafa clásica: te dan una seed que el atacante ya conoce.
**Qué te protege y qué no, dicho claro:**
| | ¿Protege de un aparato manipulado? |
|---|---|
| Generar tu entropía con dados | **No.** Elimina el RNG del fabricante, pero un firmware alterado puede mostrarte unas palabras y almacenar otras |
| El vector de prueba (Paso 0c) | **A medias.** Detecta un aparato que calcula mal, no uno que calcula bien y hace trampas solo con tu seed |
| Comprar en canal oficial | **Es la defensa principal**, y por eso no se negocia |
| Compilar tú el firmware | Sí para el software, no para el hardware |
Este es el motivo por el que los dispositivos que **montas tú con piezas genéricas** tienen una ventaja real: no hay un paquete con tu nombre que interceptar, y las piezas no las eligió nadie sabiendo para qué las querías.
---
### Paso 0b — Verificar la descarga del software **[avanzado]**
*Requiere terminal. Si lo saltas, descarga siempre desde el repositorio o web oficial del proyecto, nunca desde un enlace de foros o redes sociales.*
> **Sin terminal:** Sparrow tiene `Tools` → `Verify Download`, con interfaz gráfica. **Pero te mostrará el nombre y correo de la clave, y eso no verifica nada** — ese texto lo eligió quien la creó. Solo cuenta la huella, así que el punto 3 sigue siendo imprescindible.
⚠️ Ejecuta la verificación **antes de abrir o montar el archivo de imagen** — algunos sistemas operativos lo modifican al montarlo y la verificación fallaría.
1.**Importar la clave pública del proyecto.** (Ejemplo con SeedSigner:)
Debe decir "Good signature". Si dice "Bad signature", detente. El aviso de "key is not certified" es normal y se resuelve abajo.
3. **El paso crítico — ¿de quién es esa clave?** Toma los 16 caracteres de la derecha de la última línea y compáralos con la huella publicada por el proyecto. Los proyectos serios la publican en **varias fuentes independientes** (su web, su cuenta de redes, un gist, Keybase). Si todas coinciden, un atacante tendría que haber comprometido todas a la vez. Si no coinciden, detente.
4. **Verificar la imagen:**
```
shasum -a 256 --ignore-missing --check <manifiesto>.sha256.txt
```
(En Windows: `CertUtil -hashfile <archivo>.img SHA256` y compara manualmente.)
> Esto valida el software solo en la medida en que quien publicó la clave sea honesto y no se la hayan robado. Para eliminar esa capa, algunos proyectos ofrecen **compilaciones reproducibles**: compilas desde el fuente y compruebas que el binario es byte a byte idéntico.
### Paso 0c — Probar el dispositivo con un vector conocido **[esencial, 10 min]**
Antes de generar tu seed real, comprueba que tu dispositivo convierte correctamente la entropía en palabras. Introduce el vector de prueba oficial **de tu dispositivo** (Sección 3.3 y anexos) y confirma que produce las palabras esperadas.
Es seguro (esas seeds son públicas), rápido, y te da certeza de que el código que va a generar tu seed real funciona en tu versión concreta de firmware.
### Paso 0d — Higiene operativa antes de generar **[esencial]**
Protege contra fugas que no tienen nada que ver con la criptografía:
**El entorno**
- Móvil en otra habitación. Apaga o retira dispositivos con micrófono o cámara.
- Sin cámaras de seguridad, videollamadas ni asistentes de voz en la sala.
- A solas. Nadie mirando, ni siquiera alguien de confianza.
**Durante el proceso**
- **No digas los números ni las palabras en voz alta.** Ni murmurando. Un micrófono cercano no distingue entre pensar y hablar bajo.
- **No marques nada en las tablas o listas impresas** que uses. Un subrayado deja constancia de qué palabras te tocaron.
- Escribe las palabras únicamente en el papel o placa de backup — nunca en un dispositivo electrónico que no sea el propio hardware wallet.
- **La secuencia de tiradas es material de clave.** Anótala en papel para poder verificarla después, y destrúyela o custódiala con el mismo cuidado que la seed. Nunca en digital.
**El principio menos obvio y más importante: decide el método completo antes de empezar y síguelo mecánicamente.**
Decidir sobre la marcha —"esta tirada no la cuento", "mejor rebarajo ahora", "esa ha salido rara"— mete tu criterio humano en un proceso que debe ser mecánico, y ahí se cuela el sesgo sin que lo notes. Fija de antemano:
- Qué cuenta y qué se descarta (por ejemplo: los reyes se descartan siempre, sin excepciones).
- Cuándo se rebaraja (al agotar el mazo, nunca porque te lo pida el cuerpo).
- Qué haces si dudas de un resultado (reiniciar el proceso entero, no "arreglar" esa tirada).
Sin prisa, y si ayuda, con música. La prisa es la causa más común de errores de transcripción, y esos sí son irreversibles.
### Paso 1 — Generar entropía con dados
1. Enciende el dispositivo (sin conexión).
2. Entra en la opción de crear seed **a partir de tiradas de dado** (ver anexo de tu dispositivo).
3. Elige **24 palabras / 99 tiradas**. Si tu dispositivo solo ofrece 12 palabras, 50 tiradas dan 129 bits y cubren de sobra los 128 que necesitas — pero 99 tiradas y 24 palabras es lo recomendable.
4. Tira el dado e introduce cada resultado (1-6).
5. **Anota cada tirada en papel a medida que la introduces.** Sin la secuencia no podrás hacer la verificación cruzada del Paso 5, y no hay forma de recuperarla a posteriori.
6. Al completar las tiradas, el dispositivo calcula el checksum y te muestra las 24 palabras.
> Si te pierdes o dudas de un lanzamiento a mitad, **reinicia el proceso**. No intentes "corregir" un bit suelto de memoria.
### Paso 1b — Si usas una baraja en vez de dados
Una baraja bien barajada es una fuente física tan válida como un dado, y suele estar más a mano.
**Baraja de póker (52 cartas):** baraja a fondo una vez, saca siempre la carta de arriba sin remezclar. Valores: As=1 … Q=12; los K se descartan. Convierte con `((valor - 1) mod 6) + 1` → As=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=1, 8=2, 9=3, 10=4, J=5, Q=6. Cuando se agote el mazo, baraja de nuevo todas las cartas usadas y continúa.
**Baraja española (40 cartas):** baraja a fondo, saca de arriba. Usa directamente el valor de As a 6; descarta 7, Sota, Caballo y Rey.
Repite hasta tener 99 números válidos, anotándolos en orden. Rebaraja solo cuando se agote el mazo, nunca a media pila: elegir tú cuándo mezclar podría introducir sesgo.
### Paso 2 — Añadir la passphrase (25ª palabra)
⚠️ **No te la inventes sobre la marcha.** Es el error más común y el que más silenciosamente debilita todo lo anterior (ver Sección 2.3). Lee la Sección 5 antes de este paso y genera la passphrase con el mismo método que la seed.
1. Genera la passphrase (Sección 5) y anótala en papel antes de introducirla.
2. Con la seed cargada, entra en la opción de passphrase e introdúcela.
3. Compruébala carácter por carácter. Es case-sensitive y **no tiene corrección de errores**: un solo carácter distinto genera una wallet completamente diferente y vacía, sin ningún aviso.
4. Guarda la passphrase en un lugar **físicamente separado** del backup de las 24 palabras.
### Paso 3 — Anotar el fingerprint
El **fingerprint** (o **XFP**) son ocho caracteres que identifican tu wallet **sin revelar nada de ella**: es un resumen de tu clave maestra pública. Su gracia es que cambia si cambia cualquier cosa —una palabra mal escrita, una letra distinta en la passphrase, dos palabras intercambiadas—, así que es la herramienta con la que compruebas que estás donde crees que estás.
Anota el que muestra el dispositivo para esta combinación seed + passphrase. Son 8 caracteres que identifican la wallet sin revelar nada sobre ella, y los usarás varias veces: para confirmar que Sparrow reconstruye la misma wallet (Paso 4), para verificar tu backup (Paso 6b), y en el futuro para comprobar que recuperas la wallet correcta.
### Paso 4 — Crear la wallet en Sparrow
1. Sparrow → `File` → `New Wallet`. Dale un nombre.
2. `Airgapped Hardware Wallet` (o `Connected Hardware Wallet` si tu dispositivo va por USB) → elige tu modelo.
3. En el dispositivo: exportar el xpub como **Single Sig · Native Segwit**, en el formato que pida Sparrow.
4. Escanea el QR (air-gapped) o conecta por USB.
5. `Apply` para finalizar.
6. **Compara el fingerprint de Sparrow con el que anotaste en el Paso 3.** Deben coincidir.
⚠️ **Este paso se hace con una seed de ENSAYO, antes de generar la de verdad.** No con la tuya. Tira 99 veces con el mismo dado y el mismo método, genera una seed que no vas a usar nunca, y verifica esa. Cuando termines, la descartas y generas la real en un dispositivo que ya has comprobado dos veces.
Con la secuencia de 99 tiradas de ensayo, confirma que implementaciones distintas producen el mismo resultado.
1. Ejecuta la herramienta de línea de comandos de tu proyecto (ver anexo). Con SeedSigner:
cd seedsigner && python3 -m venv venv && source venv/bin/activate
pip install embit && pip install -e . && cd tools
python3 mnemonic.py dice <tus_99_tiradas>
```
> El `venv` evita el error *"externally-managed-environment"* de macOS y deja tu Python intacto. Para salir: `deactivate`.
2. Compara mnemónico, fingerprint, zpub y direcciones contra [iancoleman.io/bip39](https://iancoleman.io/bip39) y [bitcoiner.guide/seed](https://bitcoiner.guide/seed/).
En iancoleman.io: marca "Show entropy details", selecciona **"Hex" o "Base 10"** como formato — **no uses "Dice [1-6]"**, porque ahí el 6 se convierte en 0 y obtendrás un resultado distinto — y fija "Mnemonic Length" a 24 palabras.
3. Si las tres coinciden en todo, tienes confirmación independiente.
> **Orden correcto, y no es negociable:**
>
> 1. Vector de prueba público (Paso 0c) → confirma que el aparato convierte bien.
> 2. **Ensayo**: 99 tiradas desechables, verificadas aquí contra herramientas independientes en tu ordenador de siempre. Sin riesgo: esa seed no va a tener fondos nunca.
> 3. Descartas la seed de ensayo.
> 4. **Ahora** generas la seed real — y esa no se teclea en ningún ordenador, jamás.
>
> Si te saltas el ensayo, el Paso 0c por sí solo ya te da una verificación sólida. Lo que no se hace **bajo ningún concepto** es meter la seed buena en una máquina.
### Paso 6 — Backup físico
1. Transcribe las 24 palabras en metal (placa resistente al fuego/agua) o, como mínimo, en papel duradero.
2. Guarda la passphrase en un lugar distinto al backup de las 24 palabras.
3. Considera 2+ copias en ubicaciones geográficamente separadas.
4. Nunca fotografíes ni escribas la seed o la passphrase en ningún dispositivo conectado a internet.
### Paso 6b — Verificar la transcripción del backup **[esencial]**
Este paso se salta casi siempre y es la causa más común de pérdida de fondos que no implica a ningún atacante. Una letra mal copiada o dos palabras intercambiadas hacen que tu backup no sirva — y no lo descubrirás hasta el día que necesites recuperar, que es el peor momento posible.
**No verifiques releyendo lo que escribiste contra la pantalla.** Tu cerebro corrige solo los errores de algo que acaba de escribir. Hay que ir en la dirección contraria: **partir del papel**.
1. Apaga el dispositivo por completo (o borra la seed, si el tuyo la almacena).
2. Enciéndelo y carga la seed **leyendo tus 24 palabras desde el backup físico**, tal como están escritas. Si escribiste algo mal, aquí es donde saldrá.
3. Aplica la misma passphrase.
4. Comprueba que el fingerprint coincide exactamente con el del Paso 3.
Si coincide, tu backup reconstruye la wallet correcta. Si no, tienes un error de transcripción (o de passphrase): revísalo antes de mover un solo satoshi.
> Otros dispositivos ofrecen su propia variante. La BitBox02, por ejemplo, te desafía a identificar cada palabra correcta entre varias opciones. Cualquier método vale mientras la verificación parta de lo que está escrito en el papel, no de tu memoria.
Aprovecha para comprobar el soporte: letra sin ambigüedad (ojo con 1/l, 0/O, u/v), orden numerado, y que quien tenga que usarlo algún día pueda leerlo sin interpretar nada.
### Paso 7 — Migración de fondos (si vienes de una wallet antigua)
> **Qué es un UTXO.** Cada vez que recibes bitcoin, ese pago queda como una "moneda" independiente en tu wallet (un UTXO). Tu saldo es la suma de todas. Esto importa para la privacidad: si en una misma transacción gastas varias monedas de orígenes distintos, estás demostrando públicamente que todas son tuyas y quedan vinculadas para siempre.
1. Genera una dirección de recepción nueva en la wallet recién creada (en Sparrow, activa la pestaña de UTXOs para elegir qué monedas gastas).
2. Si las monedas de origen no están ya vinculadas entre sí, envíalas en transacciones separadas y a direcciones distintas, para no crear un vínculo nuevo entre esos orígenes.
3. **Verifica cada dirección de recepción en la pantalla del dispositivo** antes de confiar en la que muestra el ordenador (defensa contra malware que sustituye direcciones al copiar y pegar).
4. **Envía primero una cantidad pequeña de prueba** y confirma que llega antes de mover el resto.
5. Si te da igual la privacidad de esos orígenes, o tienes prisa por un motivo de seguridad, consolidar todo en un solo envío es más barato y rápido. Es un intercambio consciente, no un error — pero es irreversible.
---
## 5. Cómo diseñar una passphrase segura
La passphrase es, en la práctica, tu 25ª palabra: se combina matemáticamente con la seed para derivar una wallet completamente distinta. A diferencia de las 24 palabras (que vienen de una lista fija y una entropía verificada), la passphrase la compone el usuario — la responsabilidad de que aporte entropía real recae en ti.
Su valor está en que es una capa **independiente del generador de aleatoriedad**: aunque la seed salga debilitada, un atacante que la reconstruya sigue sin poder llegar a los fondos si no acierta también la passphrase. Con dos límites que no se pueden ignorar: **no repara una seed comprometida** —sigue habiendo que migrar—, y solo cuenta si es fuerte de verdad. Una passphrase corta, común, con patrón, sacada de una cita o reutilizada no añade nada.
### Qué la hace segura
- **Longitud y aleatoriedad, no complejidad memorizada.** El método más sólido es generarla igual que la seed: con dados o cartas, seleccionando varias palabras al azar de una lista (la propia lista BIP39 de 2048 palabras, o la lista diceware de la EFF de 7776). 5-6 palabras así ya aportan una barrera muy alta.
- **Sin relación con tu vida pública.** Nada de nombres, fechas, mascotas, ciudades, equipos, ni nada rastreable.
- **Sin reutilización.** Nunca una contraseña que hayas usado en otra cuenta: si se filtra en una brecha ajena, no quieres que apunte también a tu wallet.
- **Sin frases con sentido gramatical.** "El sol sale por el este" es más débil de lo que parece: tiene estructura lingüística predecible.
- **Evita fuentes públicas.** Citas de libros, letras de canciones, refranes — todas están en diccionarios de ataque.
### Precisión, no solo fortaleza
La passphrase **no tiene checksum ni corrección de errores**. Un solo carácter distinto (incluidas mayúsculas) genera una wallet completamente diferente y vacía, sin aviso. Por eso:
- Decide de antemano un formato exacto y reproducible (palabras separadas por un carácter fijo, sin espacios ambiguos).
- Escríbela con cuidado y verifícala más de una vez al crearla.
- Practica reproducirla de memoria unos días después, en un entorno de prueba, antes de confiar en ella con fondos reales.
### Dónde y cómo guardarla
- **Nunca junto al backup físico de las 24 palabras.** Si alguien encuentra ambas cosas juntas, la capa adicional desaparece por completo.
- Puedes memorizarla, guardarla en un gestor de contraseñas cifrado, o escribirla en un soporte y ubicación distintos a los de la seed. Cada opción tiene sus trade-offs de conveniencia vs. riesgo de pérdida.
- Nunca la introduzcas en una web ni en un dispositivo no confiable.
- Si usas passphrases distintas en varios dispositivos de un mismo **quorum** (el conjunto de llaves de un multisig: en un 2-de-3, las tres), documenta cuál corresponde a cada uno **sin escribir el valor real de ninguna**.
---
## 6. Practica primero en una red de pruebas
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):**
- **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.
- **Regtest** — tu propia red privada. Requiere un nodo propio, pero es la opción más limpia si lo tienes: controlas la cadena entera, generas bloques a voluntad y no dependes de que un faucet público esté vivo ese día.
- **Testnet3** — ⚠️ **evítala.** Lleva años deteriorada: cadena enorme, faucets rotos y monedas que llegaron a especularse. Muchas guías antiguas todavía la recomiendan.
> ⚠️ **Comprueba primero qué redes ofrece TU dispositivo.** No es una elección libre: cada aparato soporta las suyas. SeedSigner 0.8.7, por ejemplo, ofrece mainnet, testnet y regtest — **no signet**. Mira el menú de red de tu dispositivo antes de decidir, y elige la mejor de las que realmente tengas.
**Cómo activarla:**
- Sparrow: `Tools` → `Restart in...` y elige la red. Cada red guarda sus wallets en subcarpetas separadas, así que puedes cambiar sin líos.
- En el dispositivo: busca el ajuste de red en el menú de configuración avanzada (ver anexo).
- Las monedas de prueba se consiguen en "faucets" (busca "bitcoin signet faucet").
**Repite el proceso completo de esta guía** en la red de pruebas — generación de seed, passphrase, creación de wallet, recepción, envío y firma — antes de tocar fondos reales. Si vas a montar un multisig, es aquí donde conviene practicar también firmar con distintas combinaciones de signers.
---
## 7. 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:
- **¿Nodo propio o servidor de terceros?** Un servidor público es cómodo, pero le cuentas qué direcciones son tuyas y confías en que te dice la verdad sobre el estado de la red. Un nodo propio es privado y no pide confianza, a cambio de mantenimiento.
- **¿Cuántos miembros tiene tu "consejo" (quorum)?** 2-de-3 es habitual para individuos; 3-de-5 da más tolerancia a fallos a costa de complejidad.
- **¿12 o 24 palabras?** Para singlesig, 24 por entropía máxima. En multisig con 3+ cosigners, algunos consideran aceptable 12 palabras por signer, ya que la seguridad total del quorum viene reforzada por combinar claves independientes — pero si tienes dudas, 24 nunca es un error.
- **¿Fondos señuelo para coacción física?** Una wallet singlesig aparte con una cantidad menor, pensada para "entregar" si alguien te coacciona, mientras el grueso permanece protegido.
- **¿Mezclar fabricantes de hardware?** Sí, y es la ventaja principal del multisig. Con tres aparatos de tres marcas distintas, un fallo como el de 2026 debilita una llave y deja el quorum intacto: siguen haciendo falta dos para gastar, y las otras dos no comparten ni el código ni la fábrica. Con tres iguales, un solo fallo se las lleva todas.
---
## 8. Enseñando esto a otros
Las tres ideas que más importa transmitir, si solo puedes transmitir tres:
1. **La autocustodia no falló.** Falló la pieza de la que cuelga todo lo demás, en silencio, durante años. La respuesta no es volver a un exchange, es dejar de depender de un componente que no puedes verificar.
2. **Tirar un dado es el paso con mejor relación esfuerzo/protección de toda la custodia**, y lo confirmó por escrito el fabricante que falló.
3. **Un backup que nunca se ha probado no es un backup.** Es lo que más fondos pierde, y comprobarlo es gratis.
Y tres avisos que valen siempre, den igual el aparato y el año:
- **Tus palabras no se escriben nunca** en un móvil, un ordenador, una foto, la nube o un mensaje.
- **Nadie legítimo te pedirá jamás tu seed.** Quien te la pida está robándote.
- **Nadie puede recuperar bitcoin robado.** Todo "servicio de recuperación" es una estafa, y aparecen en bandada después de cada incidente.
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
- [ ] 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.
- [ ] Confirmada la versión de firmware instalada (y el *track* correcto, si tu dispositivo tiene varios).
- [ ] Dispositivo probado con el vector de prueba oficial: produce las palabras esperadas (Paso 0c).
- [ ] Entorno preparado: sin móvil ni dispositivos con micrófono, a solas, método decidido de antemano (Paso 0d).
- [ ] 256 bits de entropía generados con 99 tiradas de dado o cartas, anotando la secuencia en papel.
- [ ] Passphrase generada con entropía propia, escrita y confirmada dos veces (Sección 5).
- [ ] Fingerprint coincide entre dispositivo y Sparrow.
- [ ] Verificación cruzada con herramientas independientes, si hiciste el Paso 5.
- [ ] Backup físico de la seed en metal o papel duradero, numerado y legible.
- [ ] **Transcripción del backup verificada**: seed recargada desde el papel y fingerprint coincidente (Paso 6b).
- [ ] Passphrase guardada por separado del backup de la seed.
- [ ] Secuencia de tiradas destruida o custodiada como material de clave.
- [ ] Dirección de recepción verificada **en la pantalla del dispositivo**.
- [ ] Transacción de prueba pequeña enviada y confirmada.
- [ ] Proceso completo ensayado de principio a fin en signet o testnet4.
- [ ] Plan de herencia/acceso de emergencia documentado para alguien de confianza (sin revelar la seed).
---
## Anexo A: qué hacer si puedes estar afectado
*Para quien tiene fondos en un dispositivo potencialmente comprometido. Si estás montando una wallet nueva desde cero y tus fondos actuales están seguros, puedes saltártelo.*
### A.1 Lo primero: el malentendido que puede costarte todo
**Actualizar el firmware no repara una seed ya generada.** Coinkite lo declaró de forma inequívoca: el parche evita que el problema afecte a *seeds nuevas*, pero no restaura la seguridad de una seed creada con firmware vulnerable. Hay que **crear una seed nueva y mover los fondos a ella**.
Si actualizaste el firmware y diste el tema por cerrado, no lo está.
### A.2 Triaje: ¿estás en riesgo?
**1. ¿Cómo se generó la entropía de tu seed?**
- *Con **50 o más** tiradas de dado justas, independientes y privadas, sin registrar la secuencia* → según Coinkite, tu seed **no se considera en riesgo** por este fallo. De 50 a 98 tiradas aportaron al menos 128 bits; 99 o más, unos 256.
- *Con menos de 50 tiradas, o no recuerdas cuántas, o no sabes si fueron privadas* → trátalo como afectado.
- *La generó el dispositivo por su cuenta* → afectado, continúa.
**2. ¿Qué dispositivo y qué firmware?**
Según el aviso oficial de Coinkite:
| Modelo | Versiones afectadas | Versión corregida |
| Mk4 / Mk5 (Standard) | anteriores a 5.6.0 | **5.6.0** o posterior |
| Q (Standard) | anteriores a 1.5.0Q | **1.5.0Q** o posterior |
| Mk4 / Mk5 (Edge) | anteriores a 6.6.0X | **6.6.0X** o posterior |
| Q (Edge) | anteriores a 6.6.0QX | **6.6.0QX** o posterior |
⚠️ **Standard y Edge son tracks de release separados.** No asumas que una versión 6.x de Edge está corregida solo porque su número es mayor que una 5.6.0 estándar. Instala la release corregida **de tu track**.
**No afectados:** Mk1, y los productos TAPSIGNER, OPENDIME y SATSCARD (bases de código distintas).
> Estos datos son de agosto de 2026. **Contrasta con el [aviso oficial](https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/) antes de decidir nada.** Durante el incidente circuló información contradictoria que se fue corrigiendo con los días — incluido este documento.
**3. ¿Usas passphrase?**
Una passphrase **fuerte, única y secreta** añade una barrera independiente: la entropía reducida de la seed por sí sola no basta para llegar a los fondos. Pero Coinkite es explícito: una passphrase corta, común, con patrón, citada, reutilizada o de fortaleza incierta **no cuenta**, y en ningún caso repara la seed. Los usuarios con passphrase también deben migrar en cuanto sea practicable.
**4. Ante cualquier duda, migra.** El coste de migrar innecesariamente son unas horas y unas comisiones. El coste de no migrar cuando debías es todo.
### A.3 Migración de emergencia
⚠️ **Aquí se invierte la recomendación del Paso 7.** En una migración normal conviene separar los UTXOs por origen para no vincular procedencias. Si sospechas que tu seed puede estar comprometida, **eso es un error**: cada hora que pasa es riesgo. Consolida y muévelo ya. La privacidad se puede recuperar después; los fondos no.
Pero **migrar con prisa crea un riesgo más inmediato que el que intentas evitar** — palabras de Coinkite. Rápido no es atropellado:
1. **Verifica primero el backup escrito y el fingerprint de la seed afectada.** Antes de tocar nada.
2. **Actualiza el firmware** a la versión corregida de tu modelo y track. Confirma la versión en el dispositivo.
3. **Genera una seed nueva**, preferiblemente en un dispositivo distinto, y **con entropía propia** (99 tiradas). No reutilices el método que falló.
4. **Verifica el dispositivo nuevo** con su vector de prueba antes de confiarle nada. Diez minutos.
5. **Anota la seed nueva en papel y verifica la transcripción** (Paso 6b) antes de mover un solo satoshi. Con prisa es cuando se cometen errores de copia.
6. **Verifica la dirección de destino en la pantalla del dispositivo**, no solo en el ordenador. Este paso no se salta ni con prisa.
7. **Envía una transacción de prueba pequeña** y confirma que llega.
8. **Mueve el resto** con una comisión suficiente para confirmar pronto.
9. **Conserva el backup viejo** hasta que todo el saldo haya llegado y esté confirmado.
10. **Retira de circulación la seed vieja.** No la reutilices para nada, ni para cantidades pequeñas "de prueba".
> **Si el aparato afectado es el único que tienes.** Puedes migrar sin comprar otro: el firmware corregido genera seeds correctamente. Pero hacerlo con un solo dispositivo obliga a alternar entre la seed vieja y la nueva, y ahí es fácil borrar lo que no debes — **verifica el respaldo escrito y el fingerprint de cada seed antes de quitar ninguna del aparato**.
>
> El procedimiento exacto, menú a menú, está en el aviso del fabricante. **Esta guía no lo reproduce**: si vas a seguir instrucciones para tu modelo concreto, cógelas de la fuente que las mantiene actualizadas, no de un documento de terceros escrito en agosto de 2026.
>
> Y si puedes conseguir un segundo dispositivo, hazlo así: es más lento y mucho más difícil de estropear.
### A.4 Si ya te han robado fondos
- **No tires ni resetees el dispositivo.** Coinkite pidió expresamente conservar los dispositivos afectados: pueden ser necesarios si en algún momento se recuperan fondos. Guárdalo tal cual, aunque duela verlo.
- **Documenta lo ocurrido**: fechas, modelo, versión de firmware, direcciones afectadas, IDs de las transacciones de salida. Sirve para procedimientos legales y para cualquier proceso de recuperación futuro.
- **Consulta los canales oficiales de Coinkite** para el contacto sobre coordinación legal.
- **Considera denunciar** ante las autoridades de tu país. Aunque la recuperación sea improbable, la denuncia puede ser necesaria a efectos fiscales o legales.
### A.5 Cuidado con la segunda oleada: las estafas
Después de cada incidente aparecen personas ofreciendo "servicios de recuperación de fondos", herramientas de rescate, o soporte técnico que parece oficial. Es un patrón sistemático: los damnificados son objetivo fácil porque están desesperados y han perdido confianza en su propio criterio.
Reglas que no admiten excepción:
- **Nadie puede recuperar bitcoin robado pidiéndote tu seed.** Quien te la pida está robándote lo que quede.
- **Nadie legítimo te pedirá un pago por adelantado** para "rastrear" o "descongelar" fondos.
- **Desconfía del contacto no solicitado**, especialmente por Telegram, X o correo, aunque parezca venir del fabricante.
- **Verifica siempre por el canal oficial**, escribiendo tú la dirección web, nunca siguiendo un enlace que te hayan enviado.
> ⚠️ **Y esto incluye los correos del propio fabricante.** Durante el incidente, Coinkite envió avisos legítimos a sus clientes — con asunto urgente, botón grande y "migra tus fondos". Es exactamente la forma que tendría un correo fraudulento, y quien quiera estafarte lo va a imitar. **Da igual que sea auténtico: no pulses el botón.** Escribe tú la dirección del fabricante y busca el aviso allí. Un correo legítimo no pierde nada por que lo verifiques; uno falso lo pierde todo.
### A.6 Después de la emergencia
Cuando los fondos estén a salvo y hayas dormido, vuelve al principio de esta guía. El objetivo ya no es apagar el fuego, sino que el próximo fallo —el de este fabricante o el de cualquier otro— no vuelva a ponerte aquí: entropía propia, verificación independiente, y no depender de un único dispositivo.
---
## Anexos B y C: procedimientos por dispositivo
> **Qué hacen estos anexos, y qué no.** Su único trabajo es decirte **dónde está cada cosa en tu aparato** una vez que ya entiendes el método: en qué menú se meten las tiradas, qué vector de prueba te corresponde, cómo exportar el xpub. Son cortos a propósito, porque el porqué ya está en las secciones 1 a 4 y no se repite.
>
> **No son recomendaciones de compra y el orden no es un ranking.** Si estás decidiendo qué comprar, el sitio es el [Anexo D](#anexo-d-cómo-evaluar-un-dispositivo-que-no-está-en-esta-guía): los criterios envejecen mucho mejor que una lista de marcas.
>
> **Y no son manuales del dispositivo.** No cubren montarlo, recorrer su interfaz ni resolver sus averías: para eso, la documentación oficial de tu aparato.
### Anexo B: SeedSigner
**Qué aporta al método:** air-gapped por diseño (sin WiFi ni Bluetooth; solo entra y sale información por códigos QR), sin almacenamiento persistente de la seed (es *stateless*: al apagarse no queda nada), hardware genérico y barato, y código abierto con herramienta de verificación propia.
| **Vector de prueba** | El de la Sección 3.3 (documentado en [`docs/dice_verification.md`](https://github.com/SeedSigner/seedsigner/blob/dev/docs/dice_verification.md)) |
| **Verificación CLI** | `tools/mnemonic.py dice <tiradas>` en el propio repositorio |
| **Passphrase** | Opción de añadir passphrase con la seed cargada |
| **Exportar a Sparrow** | `Export Xpub` → `Single Sig` → `Native Segwit` → `Sparrow`, y escanear el QR animado |
| **Verificar backup** | Apagar del todo, reencender, cargar la seed leyendo del papel, aplicar passphrase, comparar fingerprint |
**Al instalar:** cada [release](https://github.com/SeedSigner/seedsigner/releases) incluye varias imágenes **no intercambiables** — `pi0` para Raspberry Pi Zero 1.3, `pi02w` para Pi Zero 2 W, y otras para Pi 2 y Pi 4. Si flasheas la que no es, el dispositivo no arranca. Descarga también el manifiesto `.sha256.txt` y su firma `.sha256.txt.sig` de la misma release para el Paso 0b. La huella de la clave se publica en [keybase.io/seedsigner](https://keybase.io/seedsigner), en la cuenta de Twitter del proyecto, en un gist de GitHub y en [seedsigner.com/keybase.txt](https://seedsigner.com/keybase.txt) — contrasta las cuatro.
Al flashear la MicroSD con Raspberry Pi Imager o balenaEtcher, cuando macOS diga que el disco es ilegible: **Expulsar**, nunca Inicializar.
Desde la v0.7.0 las imágenes son **reproducibles**: puedes compilarlas desde el código fuente y comprobar que el resultado es byte a byte idéntico.
**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.
---
### Anexo C: BitBox02
**Qué aporta al método:** existe en **edición Bitcoin-only** (criterio 9 del Anexo D: menos código, menos superficie), el fabricante documenta oficialmente el método de dados, con tabla de consulta y tarjeta de backup imprimibles, y usa el enfoque *dados → palabras* (Método B de la Sección 3.4), que reduce aún más la superficie de software.
| | |
|---|---|
| **Entropía propia** | 5 dados + 1 moneda por palabra, relanzando los 5 y 6, según la tabla de 2048 palabras. 23 palabras + la 24 elegida entre las 8 válidas |
| **Documentación oficial** | [BitBox_Diceware_HowTo.pdf](https://bitbox.swiss/bitbox02/BitBox_Diceware_HowTo.pdf) — incluye la tabla y la tarjeta de backup |
| **Material extra** | Imprescindible la tabla impresa. **No marques nada en ella** (Paso 0d) |
| **Verificar backup** | La propia BitBox02 te desafía a identificar cada palabra correcta entre varias opciones |
| **Conexión** | Por USB (no air-gapped), soportada nativamente por Sparrow |
**Qué le falta:** va por USB, así que no es air-gapped, y guarda la seed en el aparato.
**El detalle honesto que vale la pena leer:** el documento de BitBox abre diciendo que **no necesitas** hacer esto, y explica que la BitBox02 combina cinco fuentes de entropía y que ninguna puede reducir la aleatoriedad, solo añadirla. Y aun así ofrece el método, porque una hardware wallet debería ser una herramienta de soberanía personal. Esa es exactamente la postura de esta guía — con el matiz, ahora inevitable, de que todo fabricante que ha fallado estaba igual de convencido de que su generador funcionaba.
---
## Anexo D: cómo evaluar un dispositivo que no está en esta guía
**Este es el anexo que responde a "¿cuál me compro?", y lo hace sin nombrar marcas a propósito.** Una lista de dispositivos recomendados caduca —el de hoy es el que falla mañana, como acabamos de ver— y además no la puedes verificar tú. Unos criterios sí: los aplicas al aparato que tengas delante, hoy y dentro de cinco años.
Si tu hardware wallet no es ninguna de las anteriores, o estás decidiendo cuál comprar, estas son las preguntas.
**0. ¿Puedes comprarlo en un canal que controles?**
Antes que cualquier propiedad del aparato: que exista una forma de conseguirlo sin pasar por un revendedor desconocido. Los que **montas tú con piezas genéricas** parten con ventaja aquí — no hay paquete con tu nombre que interceptar. Y en ningún caso de segunda mano (Paso 0a).
**1. ¿Permite introducir entropía propia?**
Busca "dice rolls", "dice entropy", "coin flips" o "user-provided entropy" en su documentación. Si no lo permite, el pilar 1 no está disponible y estás confiando en su RNG — exactamente la posición de quien perdió fondos.
**2. ¿Documenta *cómo* procesa esa entropía?**
No basta con que acepte dados. ¿Los hashea directamente? ¿Los mezcla con su propio generador? La diferencia importa: una ruta **dice-only** no depende del RNG; una ruta **mixta** sí depende en parte (aunque, como demostró el caso Coldcard, mezclar nunca resta entropía y la protección se mantiene si tus tiradas son suficientes y privadas).
**3. ¿Publica vectores de prueba?**
Secuencias conocidas con su resultado esperado. Si los publica, puedes verificar tu unidad concreta en diez minutos. Si no, pide que los publiquen: es una petición razonable y barata para el fabricante.
**4. ¿Es el código abierto Y hay una herramienta independiente de verificación?**
Abierto es el mínimo, no el objetivo (Sección 1.6). Lo que de verdad ayuda es que exista un script o herramienta que reproduzca su conversión entropía → mnemónico fuera del dispositivo, para poder cruzarla.
**5. ¿Ofrece compilaciones reproducibles?**
Poder compilar desde el fuente y obtener un binario idéntico al publicado elimina la confianza en quien firma las releases.
**6. ¿Es air-gapped, y por qué canal entra y sale la información?**
QR o tarjeta SD elimina el canal de exfiltración que tiene el USB. No es imprescindible, pero es una capa menos de confianza.
**7. ¿Soporta passphrase BIP39?**
Es la capa independiente. Un dispositivo sin passphrase te deja sin el pilar 3 en configuración singlesig.
**8. ¿Cómo verifica el backup?**
Si el fabricante no propone ninguna forma de comprobar la transcripción partiendo del papel, tendrás que hacerlo tú a mano (Paso 6b). Que no lo mencione es una señal sobre qué tan en serio se toma el error humano.
**9. ¿Tiene firmware solo para Bitcoin?**
Varios fabricantes publican dos versiones del mismo aparato: una que soporta decenas de criptomonedas y otra que solo entiende Bitcoin. La segunda es **menos código**: menos librerías de terceros, menos formatos que parsear, menos integraciones, menos superficie donde esconder un fallo. No es cuestión de purismo — es la misma idea del pilar 2 aplicada al aparato: **cuanto menos código tiene que ser correcto, mejor.**
Y no es teórico: el fallo de Coldcard no estuvo en la criptografía, estuvo en la integración de una librería. Cada dependencia que un dispositivo no necesita es una integración que no puede salir mal.
Si el fabricante ofrece las dos, la edición **Bitcoin-only** es la opción sensata salvo que tengas una razón concreta para la otra.
**10. ¿Qué datos tuyos conserva, durante cuánto, y coincide con lo que dice en público?**
Comprar el aparato deja rastro, y ese rastro es una lista de personas que probablemente tienen bitcoin. Es el material con el que se preparan extorsiones y asaltos en casa, y no es hipotético: el ataque de julio de 2026 **priorizó las carteras grandes**.
Antes de comprar, mira **su política de privacidad, no sus declaraciones**: qué guarda, cuánto tiempo, y si hay un plazo de borrado escrito o solo una intención. Y comprueba si lo que dice la política coincide con lo que dice su gente en redes.
El caso de 2026 sirve de ejemplo: Coinkite envió avisos a correos de compras **desde 2019**, cuando su cofundador había afirmado públicamente que borraban los datos de cliente a los 90 días. Al ser preguntados señalaron su política, que sí contempla guardar el correo de compra para que puedas entrar en tu cuenta — **sin plazo de borrado**, se conservan "por ahora". Las dos versiones no encajan.
> **La tensión que no tiene solución limpia:** sin esa lista no habrían podido avisar a nadie, y ese aviso es la razón por la que mucha gente movió sus fondos a tiempo. **Retener datos te protege y te expone a la vez.** Por eso la respuesta no es confiar en que el fabricante guarde "lo justo" —eso lo decide él y tú no lo puedes comprobar—, sino **no darle datos que enlacen contigo**: un alias de correo o un relay de los que ocultan tu dirección real, envío a un punto de recogida en vez de a tu casa, y pago sin tarjeta si lo admite.
>
> ⚠️ **Lo que NO se hace para ganar privacidad es comprar de segunda mano.** Cambias una fuga de datos por un ataque de cadena de suministro, que es muchísimo peor. Ver el aviso del Paso 0.
**11. ¿Cómo se ha comportado el fabricante cuando algo le ha salido mal?**
Todos los fabricantes tendrán un fallo alguna vez; lo que los distingue es qué hacen ese día. Busca si ha habido incidentes y mira tres cosas: **cuánto tardaron en avisar**, si publicaron un análisis técnico **señalando su propio error** o una nota vaga, y si fueron claros sobre lo que el parche **no** arreglaba. Coldcard en 2026 sirve de vara de medir en ambas direcciones: cinco años sin detectar un fallo cuya revisión no comprobó la ruta de ejecución, y a la vez un aviso el mismo día y un postmortem que se señalaba a sí mismo.
Un historial limpio no significa que no haya fallos: puede significar que aún no se han encontrado. Un fallo bien gestionado dice más que un silencio.
> Un dispositivo que responda bien a 1, 2, 3 y 7 basta para seguir esta guía. Los demás son mejoras, no requisitos — salvo el **10 y el 11**, que no son propiedades del aparato sino de quien lo vende, y que conviene mirar **antes de pagar**, porque después ya le has dado tus datos.
---
## Fuentes y atribución
**Sobre el incidente (fuentes primarias):**
- Coinkite — [Coldcard Security Advisory](https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/) (30 jul 2026, act. 1 ago) y [Technical Deep Dive into the Entropy Issue](https://blog.coinkite.com/entropy-technical-backgrounder/): modelos afectados, excepción de las 50 tiradas, causa raíz y las cifras de 40 y 72 bits.
- Block Engineering — [Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware): análisis independiente.
- Wizardsardine — [Critical Coldcard flaw: what happened, who is affected, and what to do](https://wizardsardine.com/blog/coldcard-rng-vulnerability/).
- Bitcoin.com News — [Coinkite Under Fire for Retaining Customer Emails](https://news.bitcoin.com/security/coinkite-under-fire-for-retaining-customer-emails-after-88m-coldcard-hack/) (2 ago 2026) y [Coldcard Attacker Stole $30M in 10 Minutes by Targeting Big Wallets](https://news.bitcoin.com/security/coldcard-attacker-stole-30m-in-10-minutes-by-targeting-big-wallets/): retención de datos y priorización de carteras grandes (criterio 10 del Anexo D).
- TRM Labs — [Inside the USD 116 Million Coldcard Hack](https://www.trmlabs.com/resources/blog/the-largest-hardware-wallet-exploit-of-2026-inside-the-usd-116-million-coldcard-hack): cuantificación del robo.
**Sobre el método:**
- SeedSigner — [repositorio](https://github.com/SeedSigner/seedsigner), en particular [`docs/dice_verification.md`](https://github.com/SeedSigner/seedsigner/blob/dev/docs/dice_verification.md) (vectores de prueba de la Sección 3.3) y las instrucciones de verificación de releases.
- SeedSigner — [Independent Custody Guide](https://github.com/SeedSigner/independent_custody_guide), del creador del proyecto.
- Shift Crypto — [BitBox02: Seed generation with dice](https://bitbox.swiss/bitbox02/BitBox_Diceware_HowTo.pdf) (Método B de la Sección 3.4, e inspiración para la higiene operativa del Paso 0d y la verificación del backup del Paso 6b).
**Uso y reutilización.** Comparte, copia y adapta esta guía libremente. Si la modificas, indica qué cambiaste y mantén el enlace a las fuentes oficiales — el objetivo es que la gente pueda verificar por su cuenta, no que confíe en esta versión concreta.
**Sin garantías.** Material educativo elaborado por usuarios. No es asesoramiento profesional ni un producto oficial de ningún fabricante. Errores de custodia pueden causar pérdida irreversible de fondos. Verifica cada paso técnico contra la documentación oficial y practica siempre en una red de pruebas antes de usar fondos reales.
---
*Última actualización: agosto de 2026. Escrita por Pícaro para Bitcoin Txoko.*
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Picaro