Firmas Schnorr y agregación multisig

En el artículo anterior recorrimos cómo SSP construye realmente una wallet multisig on-chain: rutas BIP48, dos xpubs en orden lexicográfico, un redeem script contra el cual la chain comprueba. Todo ese mecanismo está construido encima de un esquema de firma particular — ECDSA sobre la curva secp256k1, el mismo esquema con el que Bitcoin se lanzó en 2009 y que la mayoría de las chains heredó.

Este artículo trata del otro esquema de firma — Schnorr — y qué cambia cuando construyes multisig sobre él. El cambio titular es que Schnorr soporta agregación: bajo el protocolo correcto, n firmas de n cosigners se pueden combinar en una única firma que, on-chain, parece una firma normal de una sola llave. La wallet se comporta como una wallet multisig, pero la chain nunca ve la multi-naturaleza. Eso tiene consecuencias reales para fees, privacidad, y qué tipos de multisig se vuelven económicamente viables.

TL;DR

• ECDSA es con lo que la mayoría del multisig actual (incluido SSP hoy) firma. Cada cosigner produce una firma separada; la chain las comprueba todas. Coste y huella escalan con n.
• Schnorr es un esquema de firma distinto, habilitado en Bitcoin vía la actualización Taproot de 2021. Tiene una propiedad matemática — linealidad — que a ECDSA le falta. La linealidad permite que múltiples firmas Schnorr se sumen en una sola firma válida para una llave combinada.
• MuSig2 es el protocolo moderno y práctico que convierte esa propiedad matemática en un protocolo multisig usable. n cosigners ejecutan un breve protocolo interactivo, cada uno aportando una ronda de nonces y una firma parcial; el resultado es una sola firma Schnorr indistinguible de una de una llave única.
• Esto es una victoria estricta en el lado de la verificación — fees, hinchazón del blockchain y privacidad se benefician. No es una victoria gratis en el lado de la firma: la agregación necesita manejo cuidadoso de nonces, y una implementación con bugs puede filtrar llaves privadas.
• SSP hoy usa BIP48 + ECDSA multisig en las chains que soporta. El roadmap es añadir rutas Schnorr/MuSig2 donde la chain las soporte, sin romper el modelo 2-of-2 existente que los usuarios ya tienen.

Un repaso rápido de qué hace una firma

Una firma digital prueba dos cosas a un verificador: este mensaje exacto fue firmado por alguien que sostiene la llave privada para esta llave pública. On-chain, el "mensaje" es el hash de una transacción, la "llave pública" es la dirección (o lo que la deriva), y el "verificador" es cada nodo de la red. Si la firma cuadra, la transacción es válida; si no, se rechaza.

ECDSA — el esquema que usan Bitcoin y la mayoría de las chains EVM — está bien entendido, es conservador y funciona bien para el caso de un solo firmante. El problema es lo que pasa cuando quieres que múltiples firmantes autoricen la misma transacción. ECDSA no tiene manera de combinar firmas. Si quieres two-of-two, la chain tiene que almacenar ambas firmas y comprobarlas. Three-of-five, cinco firmas. La transacción crece con la cantidad de cosigners.

What is multisig describe la parte de protocolo — m de n llaves, reglas de redeem, la chain imponiendo el umbral. Lo que esa pieza anterior no se demora en explicar es el coste: bajo ECDSA, todas esas firmas viven en la transacción. Una transacción P2WSH 2-of-2 es genuinamente más grande y más cara de transmitir que una transacción single-sig con el mismo efecto.

Qué cambia Schnorr

Las firmas Schnorr, originalmente propuestas a finales de los 80, fueron evitadas en el diseño original de Bitcoin por incertidumbre de patentes en su momento. Son matemáticamente más limpias que ECDSA en un aspecto específico: son lineales. Si s1 es una firma válida sobre un mensaje bajo la llave P1, y s2 es una firma válida sobre el mismo mensaje bajo la llave P2, entonces s1 + s2 es una firma válida sobre ese mensaje bajo P1 + P2. Tanto las llaves como las firmas se suman.

Por qué importa: de repente se vuelve posible combinar firmas antes de que toquen la chain. En vez de almacenar dos firmas en la transacción, almacenas una — la suma. El verificador comprueba la única firma contra la suma de las dos llaves públicas, que ambos firmantes pueden computar de antemano. Desde la perspectiva de la chain, la transacción resultante parece indistinguible de una transacción firmada por una sola llave.

ECDSA no puede hacer esto. Las matemáticas de ECDSA involucran un inverso multiplicativo que rompe la linealidad; las sumas de firmas ECDSA no son firmas válidas. Por eso el multisig basado en ECDSA tiene que enviar todas las firmas individuales on-chain. La chain inspecciona cada una por separado.

Bitcoin lanzó firmas Schnorr (vía BIP340) como parte del soft fork Taproot de 2021. Las firmas en sí son ligeramente más pequeñas que las firmas ECDSA (64 bytes frente a ~71), pero el asunto mucho más grande es lo que esa linealidad habilita cuando la combinas con multisig.

MuSig2 — multisig que parece una sola firma on-chain

La versión honesta de "puedes sumar firmas Schnorr" es que tienes que hacerlo con cuidado. El enfoque ingenuo — dejar que cada cosigner elija un nonce, compartir su firma parcial, sumar todo — filtra material de llave bajo firma repetida y es vulnerable a una clase de ataques de "llave rebelde". Un protocolo de agregación práctico tiene que defenderse de ambos.

MuSig2 es el resultado de una década de refinamiento sobre este problema. Es el estándar de facto para multisig Schnorr n-of-n: en el momento de firmar, los cosigners intercambian dos rondas de nonces, cada uno produce una firma parcial, y uno de ellos suma las parciales en una firma agregada final. El resultado es una sola firma Schnorr, válida contra una sola llave pública agregada, indistinguible on-chain de una firma de llave única.

Unos puntos importantes sobre MuSig2:

• Actualmente es n-of-n. Para conseguir un verdadero m-of-n (p.ej. 2-of-3) bajo agregación necesitas maquinaria adicional — FROST es la propuesta líder — y eso todavía se está productivizando. Así que en 2026, lo que SSP agregaría limpiamente es el default 2-of-2. Las configuraciones 2-of-3 y superiores del artículo selector en su mayoría todavía usan visibilidad on-chain estilo ECDSA.
• Sigue requiriendo a ambos cosigners online para firmar. La agregación no reduce el número de firmantes necesarios; solo comprime la salida final. La UX es la misma que hoy — dos dispositivos firman la misma transacción — pero la huella on-chain del resultado es más pequeña.
• Una implementación MuSig2 con bugs puede filtrar llaves. El manejo de nonces es sutil. Los despliegues en producción se apoyan en bibliotecas bien auditadas (el módulo MuSig2 de libsecp256k1, el stack rust-bitcoin, etc.) por esa razón.

Qué significa esto para SSP hoy

SSP hoy, en cada chain que soporta, usa multisig ECDSA derivado de BIP48. Dos dispositivos, dos llaves privadas, dos firmas separadas on-chain. Eso es correcto, está auditado (por Halborn — ver la referencia inside-ssp-2025-halborn-audits en la pieza 2-of-2 existente), y es interoperable con cualquier otra wallet compatible con BIP48. La desventaja es que pagas el coste on-chain completo del 2-of-2.

El roadmap desde aquí, en cristiano: añadir una ruta de código Schnorr/MuSig2 para Bitcoin (donde Taproot está activo y estable) que firme la misma wallet 2-of-2 usando agregación en su lugar. Las semánticas de umbral de la wallet no cambian — ambos dispositivos todavía tienen que firmar. Los bytes on-chain se encogen, y la transacción resultante parece un gasto single-sig.

Para el usuario, esto se vería sobre todo como:

• Fees de Bitcoin ligeramente más bajos por transacción.
• Privacidad mejorada — la wallet deja de gritarle "soy una wallet multisig" a la analítica de chain.
• Reconciliación más rápida para la UI de la wallet (ligeramente menos datos para obtener y parsear por dirección).

No es — y vale la pena decirlo claro — una actualización de seguridad. La criptografía es comparablemente dura, solo estructurada de manera distinta. La razón para adoptarla es eficiencia y privacidad, no seguridad cruda.

Qué significa esto para coste, privacidad y UX

Tres lugares donde esto cae una vez que la agregación se despliega ampliamente en una chain:

Coste. Bitcoin cobra fees aproximadamente por tamaño de transacción en vbytes. Una transacción ECDSA P2WSH 2-of-2 es notablemente más grande que la transacción Taproot-MuSig2 equivalente. Para wallets de saldo bajo enviando cantidades pequeñas, los ahorros relativos de fee pueden ser del 20–30%. Para negocios de alto throughput, los ahorros absolutos en fees anuales son dinero real.

Privacidad. Hoy, cuando una wallet emite un gasto P2WSH 2-of-2, ese hecho es visible para cualquiera con un explorador de blockchain. Las firmas de chain-analytics sofisticadas agrupan direcciones por patrón de gasto, y "esta dirección es multisig" es una señal fuerte de cluster. Un gasto Schnorr-agregado parece idéntico a un gasto single-sig. La señal de cluster desaparece.

UX. La UX de firmado en SSP — firma en el navegador, después confirma en el teléfono — no cambia. Ambos dispositivos siguen produciendo firmas parciales; la wallet simplemente las combina antes de emitir en lugar de emitir ambas. Desde la perspectiva del usuario el único cambio visible es "la wallet se siente más barata de usar".

Hay una victoria de UX más profunda en el horizonte, también. Una vez que la agregación m-of-n (vía FROST o similar) esté lista para producción, podrías imaginar una wallet SSP 2-of-3 — como el setup solo de recovery que describe el artículo anterior — que on-chain parece una wallet single-sig normal. La tercera llave "de recovery" es genuinamente una tercera llave de firma, pero la chain nunca tiene que saberlo.

Qué significa esto para ti

Tres conclusiones:

1. No tienes que pensar en Schnorr para usar SSP correctamente. El setup 2-of-2 que tienes hoy está construido sobre multisig ECDSA bien auditado, y eso permanece independientemente de cómo aterrice la agregación. El siguiente artículo de la serie (social recovery vs multisig) ignora deliberadamente la agregación porque la pregunta de quién puede gastar es independiente de cómo se ve la firma on-chain.
2. La agregación es una mejora de "fees y privacidad", no de "seguridad". Si alguna vez ves una wallet vendiendo "MuSig2 = más seguro", desconfía. La seguridad criptográfica de un MuSig2 bien implementado es comparable al multisig ECDSA bien implementado; las victorias están en otra parte.
3. Vigila el soporte de la chain, no el marketing de la wallet. Schnorr está activo en Bitcoin y siendo adoptado en el mundo EVM vía account abstraction. Las chains que lo soportan bien son donde SSP desplegará primero multisig agregado; en el resto, BIP48 + ECDSA sigue siendo el default correcto y seguro.

El siguiente artículo de esta serie, Social recovery vs multisig, cambia el foco de la criptografía a las operaciones: ¿cuándo recurres al multisig y cuándo el social recovery le gana? Ambos protegen contra perder llaves; responden preguntas distintas. Para un repaso rápido de qué dispositivos usa SSP hoy y por qué, Meet SSP Wallet sigue siendo el punto de partida.