La propuesta BIP138 para respaldar monederos de Bitcoin con configuraciones complejas ya figura en el repositorio de propuestas de mejora de Bitcoin, aunque todavía mantiene el estado de borrador. Su objetivo es recuperar información que una frase semilla, por sí sola, no siempre puede reconstruir. El mecanismo tiene una contrapartida de privacidad: alguien que ya disponga de una clave pública extendida —xpub— elegible podría descifrar una copia del respaldo si consigue acceder a ella.
La semilla no siempre basta en un monedero multisig
En un monedero multifirma, las operaciones requieren la participación de más de un firmante. La configuración del monedero se recoge en un descriptor, un registro que contiene las claves públicas y las reglas de gasto necesarias para que el software pueda reconstruir la cuenta y localizar sus fondos.
La frase semilla permite regenerar las claves privadas de uno de esos firmantes, pero no necesariamente recupera el descriptor. Si esa información se pierde, el monedero multisig o una configuración basada en miniscript puede quedar sin posibilidad de reconstruirse a partir de la semilla. El problema también puede aparecer en diseños pensados para soportar la pérdida de una de las semillas: junto con ella podría desaparecer la clave pública de ese firmante, que sigue siendo una pieza necesaria del esquema de gasto.
BIP138 está dirigido a este tipo de configuraciones, no a todos los monederos de Bitcoin. La propuesta plantea guardar en un archivo cifrado los descriptores, las políticas del monedero y otros metadatos que no forman parte de la semilla. Antes del cifrado, el formato debe eliminar cualquier material relacionado con las claves privadas.
El acceso mediante xpub introduce una exposición condicionada
El diseño permite que el propietario de una xpub elegible asociada al monedero descifre una copia del archivo sin disponer de la semilla. De ese modo puede obtener las claves públicas y la estructura de los scripts necesarias para la recuperación. La xpub, por sí sola, no proporciona las claves privadas que hacen falta para firmar transacciones.
La especificación establece límites sobre qué claves pueden utilizarse para abrir el respaldo. Quedan excluidas las claves públicas que aparecen directamente en un script y las raíces xpub que podrían quedar expuestas al gastar fondos. Si la clave de un cosignatario está excluida, ese participante no podrá emplearla para descifrar el archivo.
Estas restricciones buscan evitar que una clave pública visible en la cadena de bloques se convierta automáticamente en la llave de acceso a un respaldo almacenado fuera de ella. Aun así, el propio diseño contempla un riesgo de privacidad. Si el servidor de un servicio de monederos ya conoce una xpub de la cuenta antes de que se cree el monedero multifirma y esa misma clave se reutiliza como clave elegible, el servidor podría descifrar el respaldo si obtiene una copia.
En ese supuesto, el tercero podría conocer los metadatos del monedero, aunque eso no le concedería capacidad para gastar los fondos. La advertencia describe una exposición posible bajo determinadas condiciones, no una brecha de seguridad comunicada.
Un borrador, no un cambio en la red
La propuesta se incorporó al repositorio de Bitcoin Improvement Proposals el 21 de septiembre, pero sigue en fase de borrador. Su integración no modifica el protocolo de Bitcoin ni garantiza que los monederos actuales puedan crear o restaurar archivos con este formato.
Existe una implementación pública en Rust con instrucciones para compilarla desde la línea de comandos. El texto también señala que Liana, un monedero de Bitcoin, utiliza un formato de respaldo anterior que no es compatible con el archivo definido por BIP138. Por tanto, la propuesta ofrece una vía en desarrollo para preservar configuraciones que van más allá de una semilla, pero deja abierta la cuestión de su adopción y mantiene un coste potencial de privacidad para quienes compartan determinadas claves públicas extendidas.
