Entre el 1 y el 9 de septiembre de 2026, el foro Delving Bitcoin fue escenario de un debate técnico sobre un esquema novedoso para gestionar sesiones de firma múltiple y MuSig2. En lugar de depender de un servidor centralizado operado por el proveedor de la cartera, se propuso utilizar una red de retransmisores (relays) basada en Nostr. El desarrollador Rafael Turon presentó una nota técnica junto con un documento de referencia elaborado en colaboración con BitVault, y las preguntas de un usuario identificado como Anzus_GemWallet terminaron revelando un punto débil fundamental del sistema.
El dilema de la censura en los relays
La idea de que las transacciones PSBT (BIP-174) y los agregados MuSig2 (BIP-327) viajen por relays independientes que no almacenan claves, no descifran fragmentos y desconocen el grafo de gasto suena prometedora. Sin embargo, una lectura más crítica muestra que la descentralización del transporte no elimina la posibilidad de censura. Si un relay valida lo que transmite, se convierte en un censor; si no filtra nada, se transforma en un vector de spam. El propio autor reconoce que este es un problema abierto, no un detalle menor. Sustituir un coordinador central por una malla de relays sin resolver quién puede ejercer la censura simplemente distribuye el riesgo entre más operadores, sin garantizar que ninguno pueda bloquear transacciones.
El verdadero punto débil: el dispositivo del firmante
La discusión derivó hacia un aspecto más inquietante. Un usuario preguntó qué sucede si alguien cierra la aplicación o restaura la cartera desde una copia de seguridad mientras hay una sesión de firma activa. La respuesta, detallada por el propio autor en el foro, señaló que el punto único de fallo no está en los relays, sino en el dispositivo del firmante. Restaurar un respaldo, sincronizar el estado de una sesión a través de la nube, o mantener la misma sesión abierta en dos dispositivos puede resucitar un nonce ya consumido. Ese error es crítico: no solo obliga a reiniciar la sesión, sino que expone la clave privada completa.
Restaurar una copia de seguridad puede ser fatal
La seguridad de MuSig2 depende de que cada nonce secreto se utilice una sola vez. Cualquier mecanismo que reintroduzca un nonce, sin que el firmante lo sepa, rompe esa garantía sin que medie un ataque externo. El riesgo no proviene de un adversario sofisticado, sino de una acción cotidiana: pulsar “restaurar desde respaldo” tras cambiar de teléfono. El autor descarta la solución más obvia (una advertencia en la interfaz) porque falla justo cuando la restauración ocurre en un dispositivo nuevo sin sesión activa que mostrar. En su lugar, propone dos capas estructurales: que el estado de sesión quede fuera del alcance de cualquier respaldo o sincronización, y que la identidad de la sesión esté ligada a una clave local del dispositivo, de modo que una copia resucitada en otro aparato sea rechazada automáticamente. La advertencia queda como complemento, no como defensa principal.
Conclusiones
La propuesta de coordinar firmas múltiples a través de una malla de relays Nostr representa un avance parcial, pero la parte más delicada del diseño no es la red de transporte, sino la gestión del estado del dispositivo. Publicitar “coordinación descentralizada” sin blindar primero la sesión en el dispositivo traslada la seguridad a la capa equivocada, mientras el riesgo real —un botón de restaurar respaldo que cualquier usuario presiona sin pensarlo— sigue intacto. La lección es clara: la descentralización no es suficiente si el eslabón más débil sigue siendo el error humano.