MuSig2

La agregación de claves es todo el truco: varios participantes tienen cada uno una clave privada, y las matemáticas suman sus claves públicas en una sola clave agregada que ninguno de ellos controla por sí solo. BIP-327 estableció un esquema de dos rondas de comunicación, frente a las tres del MuSig original. Para una billetera compartida, eso supone comisiones más bajas y ninguna prueba pública de que la billetera era compartida.

Cómo funciona

MuSig2 se ejecuta en dos pasadas por el grupo, y solo la segunda pasada necesita saber qué se está firmando.

En la primera pasada, cada firmante genera dos nonces secretos y publica la pareja de puntos correspondiente. El coordinador suma esas parejas en un solo nonce combinado mediante un coeficiente derivado del hash de todo el conjunto. Ese coeficiente es la pieza concreta de ingeniería que permitió al esquema eliminar una ronda sin reabrir los ataques que rompieron diseños anteriores de dos rondas.

En la segunda pasada, cada firmante produce una firma parcial sobre el hash de firma de la transacción y devuelve un solo número. Sumados, esos números forman una firma de 64 bytes que se verifica con la clave agregada de 32 bytes según las reglas ordinarias de BIP-340. Un nodo que valida el bloque no puede saber cuántas personas participaron, ni siquiera que participara alguien.

Conviene mencionar expresamente dos propiedades de seguridad. La agregación de claves aplica un coeficiente por clave para que un participante no pueda fabricar una clave pública que anule las de todos los demás, el ataque de clave maliciosa que permite la simple suma de claves. Y los nonces son estrictamente de un solo uso: firmar dos mensajes distintos con el mismo nonce revela directamente su clave privada, y por eso las implementaciones correctas borran el nonce secreto en el momento en que se consume y rechazan una segunda firma de la misma sesión.

Dónde aparece

MuSig2 está detrás de un gasto por ruta de clave de Taproot, así que lo que usted ve en realidad es una dirección bc1p que se comporta como cualquier otra.

El argumento del tamaño es concreto. Una entrada Taproot por ruta de clave cuesta 57,5 vbytes tanto si la firmó una persona como si la firmaron cinco, mientras que un gasto con un script de testigo de dos de tres tiene que revelar tres claves públicas y dos firmas y queda muy por encima del doble. Las salidas Taproot pasaron a ser gastables en el bloque 709.632, el 14 de noviembre de 2021, así que la capacidad lleva años disponible en la cadena y el cuello de botella ha sido el software de billetera.

BIP-373 aporta la infraestructura: añade campos PSBT para nonces públicos, claves de los participantes y firmas parciales, de modo que un dispositivo de hardware pueda unirse a una sesión de firma sin que cada fabricante invente un formato de mensaje. La adopción en las billeteras de consumo sigue siendo escasa. El despliegue más concreto es el trabajo de los canales Taproot simples en Lightning, donde los dos pares financian el canal en una sola salida MuSig2.

MuSig2 frente a multisig

MuSig2 es n de n por construcción; el multisig clásico puede tener el umbral que se quiera.

Esa diferencia decide si debe estar siquiera cerca de sus ahorros. Una configuración dos de tres basada en script sigue funcionando cuando se pierde una clave, porque el script nombra tres claves y pide dos de ellas. Una clave agregada necesita que estén presentes todos los participantes, y un firmante que desaparece se lleva las monedas consigo, salvo que la misma dirección fije también una ruta de script que contenga una rama de recuperación. Los umbrales auténticos bajo una sola clave agregada necesitan un protocolo distinto, como FROST, que no es lo que especifica BIP-327.

La segunda contrapartida es deliberada. Un multisig por script es auditable por cualquiera con un explorador de bloques, y MuSig2 no lo es, lo que supone una ventaja de privacidad para un hogar y un obstáculo para un tesorero que tiene que demostrar que un pago requirió a dos directivos.