-
El diseño mueve PSBT y rondas MuSig2 de un coordinador a relays Nostr.
-
Ningún relay debería ver claves, fragmentos ni el grafo de gasto.
Entre el 1 y el 9 de septiembre de 2026, un intercambio en el foro Delving Bitcoin planteó un diseño para coordinar sesiones de firma multisig y MuSig2 a través de una malla de relays Nostr, en lugar de un servidor único operado por el proveedor de la wallet.
El desarrollador Rafael Turon publicó una nota técnica junto con un documento de referencia coescrito con BitVault, y recibió preguntas de un usuario identificado como Anzus_GemWallet que terminaron exponiendo el verdadero punto débil del sistema.
La promesa suena atractiva: PSBT (BIP-174) y MuSig2 (BIP-327) viajando por relays (retransmisores) independientes que, según el hilo técnico, no retienen material de claves, no descifran fragmentos y no conocen el grafo de gasto. Ningún relay debería poder hacer más que negar el servicio.
Pero esa promesa merece una lectura menos entusiasta de la que suele acompañar a cualquier anuncio que use la palabra Nostr. El problema, conviene aclararlo de entrada, nunca fue solo el servidor.
Configuraciones como el 2-de-3, los agregados MuSig2 sobre Taproot o las bóvedas con bloqueo temporal ya reparten la autoridad de firma entre varias partes en la cadena. Eso nunca estuvo en duda. Lo que sí seguía concentrado en una sola pieza era la coordinación: quién ve las rondas de firma, quién decide si una sesión sigue viva y quién puede, en la práctica, negarse a transmitirla.
Trasladar esa coordinación a una malla de relays resuelve una parte real del problema, y conviene no restarle mérito. Según describe la nota de trabajo publicada por el autor, si un relay cae, el cliente publica a todos los relays fijados al inicio de la sesión, así que basta con que uno siga vivo para continuar. Un mensaje duplicado tampoco representa un riesgo, porque el nonce secreto se consume una sola vez dentro de la operación de firma y cada resultado de ronda queda en caché.
La censura sigue sin tener dueño
Ahí termina la parte del diseño que ya funciona. La parte que no funciona todavía es más reveladora que la que sí.
Un relay que valida lo que transmite se convierte, por definición, en un censor. Uno que transmite cualquier cosa sin filtrar se convierte en un vector de spam. No existe todavía una salida limpia a ese dilema, y el propio autor lo reconoce como un problema abierto, no como un detalle menor pendiente de pulir.
Es una admisión honesta, pero también una señal de que «descentralizar el transporte» no es lo mismo que «eliminar el punto de censura». Simplemente lo reubica en un lugar donde todavía no hay una respuesta clara sobre quién puede ejercerlo.
Sustituir un coordinador por una malla de relays sin resolver esa pregunta no elimina el riesgo de censura: lo distribuye entre más operadores sin garantizar que ninguno pueda ejercerla. Eso es un avance parcial, no una solución.
El fallo real no estaba en el relay
La conversación que siguió al anuncio original terminó llevando la discusión a un terreno mucho más interesante que la arquitectura de red. Un usuario preguntó, con sentido común, qué pasa si alguien cierra la aplicación o restaura la wallet desde una copia de seguridad mientras hay una sesión de firma activa.
La respuesta expuso el verdadero punto único de fallo del sistema, y no está en ningún relay. Está, según detalló el propio autor en el foro, en el dispositivo del firmante.
Restaurar un backup, sincronizar el estado de una sesión por la nube, o mantener la misma sesión abierta en dos dispositivos a la vez puede resucitar un nonce que el firmante ya consumió. Ese es el único error de la lista que no cuesta simplemente reiniciar una sesión: cuesta la clave privada completa.
La razón técnica es clara una vez que se explica. La seguridad de MuSig2 depende de que un nonce secreto se use exactamente una vez. Cualquier mecanismo que lo reintroduzca, sin que el firmante lo sepa, rompe esa garantía sin que haya mediado ningún ataque externo.
Lo llamativo es que ese riesgo no depende de ningún adversario sofisticado. Depende de una acción que millones de usuarios de wallets ejecutan sin pensarlo dos veces: pulsar «restaurar desde respaldo» después de cambiar de teléfono.
La respuesta del autor a ese hallazgo también merece atención, porque descarta la salida más obvia. Una advertencia en la interfaz, admite, es la capa más débil de las tres que propone, y falla justo en el caso que más importa: cuando la restauración ocurre en un dispositivo nuevo, sin sesión activa que mostrar ninguna advertencia.
Las dos capas que sí sostiene son estructurales, no informativas: 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é atada a una clave local del dispositivo, de modo que una copia resucitada en otro aparato quede rechazada automáticamente. La advertencia queda como complemento, no como defensa principal.
Eso invierte el orden habitual en que se presentan estas propuestas. Lo que se anuncia como el avance —la coordinación distribuida vía Nostr— resulta ser la parte menos delicada del diseño. Lo que decide si un usuario pierde o no su clave privada nunca dependió del relay que transportó el mensaje.
Confundir esas dos capas tiene un costo concreto para cualquier wallet que adopte este tipo de coordinación. Publicitar «coordinación descentralizada» sin blindar primero el estado de sesión del dispositivo traslada la seguridad a la capa equivocada, mientras el riesgo real —un botón de restaurar backup que cualquier usuario presiona sin pensarlo— sigue exactamente donde estaba.
