MuSig2 y FROST: firmas de grupo con una sola firma en cadena

Una clave, varios dueños: ¿qué ve la cadena?

Imagina una tesorería con tres socios. Con una multifirma por script, cada gasto publica en la cadena las tres claves, el umbral y las firmas, y cualquiera que mire sabe que ahí hay una multifirma 2 de 3. Con MuSig2 o con FROST, el gasto por la ruta de la clave es una única firma de 64 bytes sobre una única clave. Nadie puede saber cuántos firmaron ni cuántas partes tiene la clave. Esa es la promesa. Esta entrada explica qué hay detrás, qué ya está estandarizado y qué se paga a cambio.

Qué es una salida P2TR y cómo funcionan las firmas BIP-340 está en Taproot y en firmas Schnorr. Aquí interesa lo que viene después: cómo se reparte una clave entre varias personas y qué riesgos aparecen al hacerlo.

MuSig2: n de n, dos rondas

MuSig2 es un esquema n de n: hacen falta todos los firmantes. Lo especifica BIP-327 («MuSig2 for BIP340-compatible Multi-Signatures», de Nick, Ruffing y Jin), y lo dice sin ambigüedad: es un esquema de multifirma n de n y no un esquema de firma umbral t de n.

El esquema tiene dos fases. La primera es la agregación de claves (KeyAgg), que es no interactiva: cada participante publica su clave pública y cualquiera puede calcular la clave agregada. El resultado es una clave x-only de BIP-340, así que sirve como clave interna de Taproot. Con el tweak x-only, BIP-341 la compromete con el árbol de scripts, igual que con una clave normal.

Sumar las claves a pelo no vale. Si Alicia y Bob suman sus claves, Bob puede anunciar como suya una clave calculada para que la suma sea una clave que solo él controla. Es el ataque de clave falsa (rogue key). KeyAgg multiplica cada clave por un coeficiente que sale de un hash del conjunto entero de claves. Si Bob cambia la suya para cancelar la de Alicia, cambian todos los coeficientes, y la cuenta ya no le sale.

La segunda fase es la firma, en dos rondas:

1. Ronda 1. Cada participante genera dos nonces secretos aleatorios y publica los nonces públicos correspondientes (66 bytes por participante en el campo PSBT de BIP-373).
2. Ronda 2. Se agregan los nonces, cada uno calcula su firma parcial (32 bytes) y alguien las suma en una firma BIP-340 de 64 bytes. Con PartialSigVerify se puede comprobar cada firma parcial y saber quién envió una contribución inválida, para abortar la sesión sin adivinar.

La firma final pasa la verificación BIP-340 normal. Un nodo no necesita saber que MuSig2 existe. Y es una firma por entrada: MuSig2 junta firmantes, no entradas. Juntar en una sola las firmas de varias entradas de una transacción no existe hoy en Bitcoin.

Reutilizar un nonce: el fallo silencioso

Primero, el caso simple. En una firma Schnorr de una sola clave, la parte secreta de la firma es s = k + e·d: el nonce secreto k más el reto e multiplicado por la clave secreta d. Si dos firmas con retos distintos comparten k, al restarlas el nonce se cancela y d queda despejada.

En MuSig2 la cuenta es otra. Cada firmante usa dos nonces secretos, k₁ y k₂, y según el algoritmo Sign de BIP-327 su firma parcial es s = k₁ + b·k₂ + e·a·d. Aquí a es el coeficiente de su clave en KeyAgg. El coeficiente b sale de un hash del nonce agregado, la clave agregada y el mensaje. Y e es el reto de BIP-340, calculado con el nonce final de la firma. Los tres son públicos. Lo importante es que b y e dependen de los nonces de todos los participantes. Si un firmante usa el mismo par (k₁, k₂) en dos sesiones y en la segunda otro participante cambia su nonce, salen b′ y e′ distintos. Al restar las dos firmas parciales, el nonce ya no se cancela: queda (b − b′)·k₂ + (e − e′)·a·d (si las dos R tienen la y par; si las dos la tienen impar, cambia el signo del término de k₂, y si no coinciden, tampoco se cancela k₁).

Eso no salva al firmante. Cada firma parcial hecha con el mismo secnonce es una ecuación lineal con las mismas incógnitas secretas (k₁, k₂ y d) y con coeficientes que el atacante conoce. Con ecuaciones suficientes, el sistema se resuelve y d sale despejada. Por eso BIP-327 es tajante: Sign no debe ejecutarse nunca dos veces con el mismo secnonce, porque la clave secreta se puede extraer de las firmas parciales. La cabecera de libsecp256k1 lo repite: «nonce reuse will leak the secret key».

Con una sola clave, BIP-340 mezcla en el nonce la clave, el mensaje y unos datos auxiliares que recomienda que sean aleatorios. Aunque fallara el azar, el nonce cambiaría con el mensaje, y eso basta, porque el reto depende solo del mensaje y de lo que controla el propio firmante. En MuSig2 no: b y e dependen también de los nonces de los demás. Si k₁ y k₂ salieran de forma determinista de la clave y el mensaje, un adversario activo podría pedir la misma firma tantas veces como quisiera cambiando solo su propio nonce, y cada vez obtendría una firma parcial con el mismo secnonce y otros b y e. BIP-327 lo prohíbe por esa razón, y BIP-340 ya avisa de que los esquemas multifirma son inseguros con un nonce determinista. La única excepción es DeterministicSign, que mete en el hash el nonce agregado de todos los demás: si alguien cambia el suyo, cambia también el de este firmante. Como necesita esos nonces antes de generar el suyo, solo lo puede usar el último en generarlo.

Esto tiene consecuencias operativas. El secnonce es estado que vive entre la ronda 1 y la 2, y cualquier copia de ese estado es una ocasión de usarlo dos veces. La documentación de libsecp256k1 lo dice así: copiar la estructura del secnonce puede llevar a reutilizar el nonce, y eso filtra la clave. Restaurar una copia de seguridad o una instantánea de máquina virtual tomada entre las dos rondas, o reintentar una sesión con el estado guardado, es justo eso. Es un fallo silencioso: la firma sale válida y nadie nota nada hasta que alguien junta las firmas parciales y calcula la clave.

Bitcoin Core no guarda nunca los secnonces en disco. Según la PR #29675 (fusionada el 14 de octubre de 2025), solo viven en memoria y, si se reinicia el programa, el proceso de firma empieza de cero. Coldcard hace lo mismo en su firmware Edge: guarda los datos de la sesión solo en memoria volátil, así que el aparato tiene que seguir encendido entre la primera y la segunda ronda. BIP-327, y con él el borrador de FROST, permite esconder el secnonce en un estado interno de la biblioteca para que no se reutilice por accidente.

Queda otro riesgo: un firmware malicioso que elige sus propios nonces para filtrar datos, un tema que se trata en billeteras hardware. Ni BIP-327 ni el borrador BIP-445 incluyen protección anti-exfil. En la PR de BIP-445 se discutió para FROST, y en septiembre de 2026 se acordó dejarla para una propuesta aparte.

Ojo: este nonce de firma no tiene nada que ver con el nonce de minería, el campo de la cabecera que cambian los mineros.

El umbral no existe en MuSig2

Un error frecuente es creer que MuSig2 permite un 2 de 3 con una sola firma. No existe. Un 2 de 3 se monta con una clave interna musig(A,B) más hojas musig(A,C) y musig(B,C), o con hojas multi_a. Solo el par de la clave interna gasta sin revelar nada. Si firma cualquiera de los otros dos pares, se publican su hoja, la clave interna y la prueba de que se gastó por script; la otra hoja queda oculta. El diseño de esos árboles se trata en diseño de multifirma y en miniscript.

FROST: umbral t de n

FROST sí es un esquema de umbral. Una generación distribuida de claves (DKG), o un dealer de confianza, reparte participaciones (shares) de una única clave secreta. Con DKG, nadie llega a tener la clave entera. Después, cualquier grupo de t participantes firma en dos rondas: primero compromisos de nonce y luego participaciones de firma, que suma un coordinador. El resultado, otra vez, es una firma BIP-340 normal.

La especificación general es el RFC 9591 (IRTF, junio de 2024, Informational; Connolly, Komlo, Goldberg y Wood). Deja fuera la generación de claves y trae un reparto con dealer de confianza en su apéndice C. Pero el RFC no sirve tal cual para Bitcoin. BIP-445 («FROST Signing Protocol for BIP340 Signatures», de Sivaram Dhakshinamoorthy) da dos razones: las firmas del RFC son incompatibles con las claves x-only de BIP-340, y el RFC no especifica el tweak de claves, que hace falta para derivar con BIP-32 y para Taproot. Así que escribe su propia especificación, y elige la variante FROST3, la más eficiente de las publicadas según el propio borrador. La generación de claves también queda fuera de BIP-445, que remite al dealer de confianza o a una DKG como ChillDKG.

Eso sí, BIP-445 le pone una condición a esa generación: la clave umbral tiene que ser «Taproot-safe», es decir, estar comprometida con una rama de script imposible de gastar. Si no, un participante malicioso podría esconder en la clave una rama suya y gastar sin reunir el umbral. El borrador también limita n a 128 participantes.

ChillDKG (Ruffing, Nick y otros tres autores) es un borrador de BIP para la generación distribuida de claves de FROST, alojado en BlockstreamResearch/bip-frost-dkg, fuera del repositorio de BIPs. La última versión de su registro de cambios es la 0.3.0, del 30 de julio de 2026. La 0.2.0 (diciembre de 2024) ya había corregido un fallo en CertEq y hacía Taproot-safe la clave umbral por defecto.

Estado a 7 de octubre de 2026: BIP-445 tiene número, pero no está publicado. La PR #2070 seguía abierta, bip-0445.md da 404 en la rama master y no figura en el README. En septiembre de 2026 el editor preguntó si estaba lista para publicarse, y el autor respondió que faltaba un último ajuste. Así que «FROST ya es un BIP» es falso hoy.

Qué se gana y qué se pierde

Lo que se gana es espacio y privacidad. Un gasto por la clave pesa unos 57,5 vB por entrada, con MuSig2 (n de n) o con FROST (t de n). Un 2 de 3 en P2WSH, unos 104,5 vB. Un 3 de 5, unos 139,75 vB. Un 2 de 3 montado con MuSig2 y hojas cuesta 57,5 vB si firma el par de la clave interna, y unos 82,75 vB si hay que gastar por una de las dos hojas musig(). Una hoja multi_a 2 de 3 sola en el árbol pesa unos 108,75 vB, algo más que P2WSH. Así que Taproot no abarata por sí solo: lo que ahorra es que firme una sola firma agregada, por la clave (57,5 vB) o por una hoja musig() (82,75 vB), y eso exige MuSig2 o FROST. Y ese ahorro crece con n, porque la firma por la clave no cambia de tamaño.

Las cifras están calculadas con las reglas de peso de BIP-141 y los formatos de BIP-341 y BIP-342. Los supuestos: 41 bytes por entrada fuera del witness (punto de salida, scriptSig vacío y nSequence), firmas ECDSA de 72 bytes contando el byte de sighash y firmas Schnorr de 64 con el sighash por defecto. Cada nivel más de profundidad en el árbol suma 8 vB. Con firmas ECDSA de 71 bytes, los P2WSH bajan a 104 y 139 vB.

En privacidad, un gasto por la clave no publica ni el umbral, ni las claves, ni el número de firmantes, y desaparece la huella de «multifirma 2 de 3 en P2WSH».

Lo que se pierde:

• Interacción. Dos rondas con todos los firmantes (MuSig2) o con t de ellos (FROST), y estado que hay que conservar entre una ronda y la otra, que es donde está el riesgo de los nonces.
• Rendición de cuentas. En cadena no se ve quién firmó. A veces es una ventaja y a veces un problema, por ejemplo en una auditoría de empresa.
• Recuperación. Es el coste menos visible, y se explica a continuación.

Recuperación: la parte que se subestima

En MuSig2 n de n, perder una sola clave bloquea la ruta de la clave. Hace falta una hoja de respaldo, con otro quórum o con timelock (ver billeteras con timelock). Además, reconstruir la billetera exige el descriptor con musig() y software que entienda BIP-390 y BIP-328. El orden de las claves no es el problema, porque BIP-390 las ordena con KeySort antes de agregarlas. Lo que no dicen las xpubs solas es qué hojas tiene el árbol ni con qué condiciones, y sin el descriptor no se reconstruye la dirección. Los descriptores de salida ya explican por qué el descriptor es parte de la copia de seguridad.

En FROST, la share depende de lo que aportaron los demás en la generación de claves, así que no se puede volver a derivar de una seed. ChillDKG, que sigue siendo un borrador, define la copia como la clave secreta de host más los «datos de recuperación» de cada sesión. Esos datos son iguales para todos y llevan cifrados los secretos, así que otro participante o el coordinador te los pueden devolver. Pero dejan ver el umbral y las claves públicas. Un producto que use su propia generación de claves tendrá su propio formato. Antes de depositar, comprueba cuál usa el tuyo y si otro software sabe leerlo.

Estándares que ya existen alrededor de MuSig2

MuSig2 está más avanzado que FROST en integración. A 7 de octubre de 2026:

• BIP-327 (borrador de marzo de 2022, número asignado el 26 de marzo de 2023): Deployed.
• BIP-328 (Ava Chow, Complete): construye una xpub sintética de la clave agregada, con profundidad 0 y un chain code fijo, el SHA256 de «MuSig2MuSig2MuSig2». Solo admite derivación no endurecida. En una billetera HD el descriptor queda como tr(musig(xpubA,xpubB,…)/0/*).
• BIP-373 (Complete): campos PSBT por entrada para las claves de los participantes (0x1a), el nonce público de 66 bytes (0x1b) y la firma parcial de 32 bytes (0x1c). Por salida, las claves de los participantes (0x08), para reconocer el cambio.
• BIP-390 (Draft, de Ava Chow): el descriptor musig(). Solo vale dentro de tr(), rawtr() o sp(), no se puede anidar y desde la clave agregada solo se deriva sin endurecer.

Qué firma qué, con fecha

Según doc/bips.md de Bitcoin Core (consultado el 7 de octubre de 2026), Core analiza y deriva con musig() desde la 30.0 (10 de octubre de 2025, PR 31244) y maneja los campos PSBT de BIP-373 desde esa misma versión (PR 31247). Firma desde la 31.0 (19 de abril de 2026). El módulo musig de libsecp256k1 llegó con la 0.6.0, del 4 de noviembre de 2024. FROST no tiene módulo en libsecp256k1: no está en la rama master ni en ninguna versión publicada, la última la 0.8.0, del 3 de agosto de 2026. En secp256k1-zkp, el repositorio de Blockstream Research, las PR #138 («FROST») y #278 («FROST Trusted Dealer») siguen abiertas.

En aparatos: la aplicación Bitcoin de Ledger añadió musig() en políticas Taproot en la 2.4.0 (7 de marzo de 2025) y corrigió el soporte de musig() dentro de fragmentos multi_a en la 2.5.1 (9 de septiembre de 2026), según su CHANGELOG. Coldcard firma MuSig2 solo en su firmware Edge, el canal experimental, desde la 6.5.0X (24 de marzo de 2026). La 6.6.1X (31 de agosto de 2026) corrigió un fallo por el que dos derivaciones de la misma clave agregada podían recibir el mismo nonce, así que la versión mínima razonable es esa. Coldcard guarda la sesión solo en memoria volátil (ver arriba) y no admite musig() dentro de multi_a. En el firmware estándar (5.6.3 y 1.5.3Q, 30 de septiembre de 2026) no está. Nunchuk anunció el 27 de agosto de 2025 MuSig2 «software keys only (for now)», dentro de Miniscript Taproot. A 7 de octubre de 2026, los CHANGELOG de Jade, BitBox02 y Trezor no mencionan MuSig, y las notas de Sparrow 2.5.5 (17 de septiembre de 2026) tampoco.

Qué significa esto para ti

Si hoy quieres una multifirma que ahorre comisiones y no deje huella, MuSig2 con una hoja de respaldo es técnicamente posible. Las opciones son Core 31.0 o posterior, con las claves en un ordenador conectado; Ledger, si tu programa coordinador sabe manejar los campos PSBT de MuSig2 (BIP-373), cosa que conviene comprobar antes; o Coldcard en Edge 6.6.1X o posterior, que su fabricante desaconseja para cantidades grandes. Y el descriptor musig() sigue en Draft. Si necesitas un umbral indistinguible de una clave simple, FROST aún no tiene BIP publicado, y la copia de las shares depende de la generación de claves que use cada producto. En ambos casos, guarda el descriptor y prueba la recuperación antes de depositar nada que importe. Y si una sesión de firma se queda a medias, no la continúes desde una copia ni desde una instantánea: empieza de cero. Para la multifirma por script, la de siempre, el punto de partida es multifirma.