Copias de seguridad multifirma: qué necesitas además de dos semillas

Financiación: CypherpunkGuide puede recibir comisiones por recomendación a través de las guías de compra enlazadas. Este artículo no contiene enlaces de afiliación para comprar directamente. Ningún fabricante de billeteras patrocinó este trabajo.

La aplicación que coordinaba las firmas ya no está disponible. Un dispositivo de firma ha fallado, pero conservas dos copias de semillas, el material del que se derivan las claves privadas. Parece precisamente el tipo de incidente que debía resistir una configuración de 2 de 3.

Puede serlo, siempre que puedas reconstruir la billetera para la que firmaban esas claves. «2 de 3» expresa un requisito de firmas; no describe todo el procedimiento de recuperación.

Aquí nos limitamos a billeteras Bitcoin P2WSH convencionales que usan sortedmulti: un script que exige un número mínimo de firmas dentro de un conjunto definido de claves públicas. No evaluamos dispositivos físicos, esquemas de firma Taproot ni la compatibilidad de recuperación entre productos. Si todavía estás organizando la autocustodia básica, empieza por las pruebas de recepción, firma y recuperación.

Dos firmas no sustituyen la configuración completa

#

Dos claves pueden satisfacer un script de 2 de 3. Sin embargo, reconstruir sus direcciones exige la configuración completa: las tres claves públicas en los puntos de derivación correspondientes, el umbral de firmas y el tipo de script. Tres claves no equivalen necesariamente a tres personas.

Un descriptor describe de forma estructurada los scripts que debe reconocer una billetera. Puede incluir claves públicas extendidas, capaces de derivar familias de claves públicas, y las rutas que se usan para ello. BIP380 explica por qué una copia que solo guarda claves privadas puede dejar sin determinar el tipo de script y las rutas. BIP383 define las expresiones multifirma, incluido el ordenamiento de las claves públicas derivadas en sortedmulti.

Conviene distinguir tres clases de material:

Un archivo de billetera puede reunir varias de estas piezas. Un descriptor puede conservar gran parte de la configuración. Lo decisivo es qué contiene realmente la exportación y si el programa de recuperación sabe interpretarla. El nombre del archivo y su suma de comprobación no resuelven esas dudas.

La implementación del diálogo de copias de seguridad de Sparrow menciona expresamente las semillas necesarias y todas las claves públicas extendidas, y presenta el archivo de billetera o el descriptor como copias de la configuración. Es una observación del código fuente: no probamos su interfaz actual ni la compatibilidad de importación con otro producto.

Qué mostró la prueba de recuperación aislada

#

El 24 de septiembre de 2026 usamos regtest, la red local de pruebas de Core 31.1, para separar cuatro comprobaciones: reconstruir direcciones, encontrar una salida de prueba concreta, completar la firma y obtener la aceptación del nodo local. El intervalo medido fue de 13,3 segundos, sin las comprobaciones iniciales de versión y hashes ni el cierre y la limpieza finales. Solo usamos entradas ficticias públicas, sin fondos reales; las conexiones entre pares estaban desactivadas y al terminar había cero conexiones.

En cada uno de los cinco primeros casos se reconstruyó la configuración en una billetera de observación nueva e independiente. La salida buscada —el importe asignado a una dirección por la transacción de prueba— contenía 0,01000000 BTC de regtest. Las claves A, B y C se derivaron de entradas ficticias especificadas públicamente; no se introdujeron semillas en ningún dispositivo físico.

En las tres últimas filas comparamos la dirección de recepción con fondos, situada en el índice 1, y no encontramos saldo en el rango importado. Eso no permite concluir nada sobre las direcciones fuera de ese rango. Sustituir 2 de 3 por 2 de 2 comprueba una reconstrucción equivocada; no agota todas las vías de recuperación ni determina si otra copia o un script histórico pueden aportar lo que falta.

Después enviamos la transacción firmada por A/B a la cadena de pruebas privada. La billetera que incluía ambas ramas encontró la salida de cambio de 0,00599000 BTC de regtest, es decir, el importe que volvía a la billetera. La que solo incluía la rama de recepción había encontrado el pago original, pero no detectó esa salida de cambio. La comparación se limita a esa salida: no significa que su saldo total pasara a cero, pues el experimento también contenía salidas de minería independientes. Además, el programa rechazó un descriptor cuya suma de comprobación habíamos dañado deliberadamente; el descriptor original superó las comprobaciones inmediatamente anterior y posterior.

El artículo incluye el script, los resultados medidos, las pruebas de seguridad para detectar regresiones y un inventario de recuperación vacío. Importamos el rango de direcciones de 0 a 2, con marca temporal 0 para volver a explorar la cadena. Para firmar utilizamos claves privadas ficticias derivadas y datos correctos del script y de la salida anterior, aportados por la billetera de referencia completa. No demostramos un procedimiento completo de restauración desde semillas, la recuperación de un dispositivo físico ni la compatibilidad entre productos. La prueba de aceptación local no difunde la transacción. Una ejecución controlada tampoco estima la tasa de éxito de las recuperaciones reales.

Los requisitos y el comando para repetir el experimento están en las notas del laboratorio. No uses ninguna de estas claves ficticias, divulgadas públicamente, para fondos reales.

Encontrar fondos y poder gastarlos son comprobaciones distintas

#

Una billetera restaurada puede reconocer una salida sin poder gastarla. También puede mostrar que no hay saldo coincidente porque sus condiciones de búsqueda están incompletas.

Las direcciones de recepción y de cambio suelen seguir ramas de derivación diferentes. Si la configuración restaurada omite los scripts del cambio, un pago puede llevar el resto de los fondos a direcciones que esa billetera no reconoce. La marca de clasificación internal no equivale por sí misma a incluir o excluir una rama.

El código y la ayuda de importación de descriptores de Core distinguen la marca temporal, el rango de direcciones y la clasificación interna. La sincronización y la disponibilidad de bloques históricos también pueden influir. Un saldo de cero exige investigar; por sí solo no demuestra que los fondos hayan desaparecido.

Por eso tampoco basta con un mensaje de importación correcta o un campo llamado «solvable». La prueba pertinente de firma es una transacción completa que cumpla el script. Un regtest local demuestra el comportamiento bajo esas condiciones controladas, no una confirmación en la red principal ni compatibilidad con dispositivos.

La configuración pública puede revelar información privada

#

Un descriptor que solo contiene información pública no puede firmar por sí solo, pero puede revelar las direcciones derivables de las claves públicas y rutas que incluye. Compartirlo puede permitir que otra persona relacione saldos y transacciones dentro de ese alcance.

«Clave pública» no es una invitación a publicar la configuración de tu billetera. Limita quién puede verla y distingue ese material de un descriptor privado, que puede contener claves privadas. Tampoco conviene prometer que divulgar una clave pública nunca afectará a los fondos: BIP32 describe cómo una clave pública extendida del padre, combinada con una clave privada hija de derivación no endurecida, puede revelar la clave privada del padre.

Esa exposición combinada es distinta de disponer solo de un descriptor público. Ninguna de las dos afirmaciones justifica publicar datos de la billetera en un foro de recuperación para diagnosticar un problema. La guía de privacidad de Bitcoin en la cadena desarrolla el problema más amplio de relacionar transacciones.

Comprueba el plan sin reunir secretos en el inventario

#

Un inventario útil indica si el material necesario existe y si se ha comprobado. No debería convertirse en otra colección de secretos que resulte fácil compartir por descuido.

Nuestra plantilla pregunta por el umbral de firmas, la copia de la configuración, la cobertura de recepción y cambio, los formatos de importación admitidos y las pruebas separadas de búsqueda y firma. No tiene campos para palabras semilla, frases de contraseña, claves públicas ni descriptores reales. Registra el estado, no los valores.

Sigue el procedimiento de comprobación de recuperación documentado por el proveedor de tu billetera o dispositivo de firma. No introduzcas semillas reales en sitios web, chats ni en este script experimental. Sus claves ficticias, reproducibles públicamente, no sirven para custodiar fondos reales. Una prueba de restauración de copias cifradas puede demostrar que los archivos se recuperan, pero no que su contenido permita gastar desde una billetera Bitcoin concreta.

La multifirma añade material que conservar, tareas que coordinar y comprobaciones que mantener. Si no puedes asumir esas responsabilidades, sumar dispositivos no mejora automáticamente tu plan de recuperación. Este artículo ayuda a examinar esa complejidad; no recomienda comprar más dispositivos.

Puntos clave

#

Preguntas durante la recuperación

#

¿Perder el descriptor hace imposible recuperar la billetera?

#

No necesariamente. Otra copia compatible puede contener la configuración, y un script conocido puede conservar parte de la información. Por ejemplo, gastar una salida P2WSH revela su script de testigo según BIP141. Eso no revela automáticamente todas las claves públicas extendidas ni reconstruye el conjunto completo de direcciones de la billetera. La recuperación depende del material que quede.

¿Una suma de comprobación válida demuestra que tengo la configuración correcta?

#

No. Ayuda a detectar errores de transcripción en un descriptor, pero alguien puede generar otro descriptor con su propia suma válida. Contrasta la configuración con una copia de confianza y con la billetera que quieres recuperar. La validez sintáctica no demuestra autenticidad.

Fuentes y copias archivadas

#

Las explicaciones anteriores se basan en estas fuentes primarias. Las copias archivadas permiten consultar el material citado más adelante.