ECDSA frente a firmas Schnorr: qué cambió con Taproot

Hoy, ECDSA frente a Schnorr es sobre todo una cuestión de Bitcoin, porque Taproot (BIP 340–342, activado en noviembre de 2021) añadió las firmas Schnorr junto a ECDSA sobre la misma curva, secp256k1. Los dos esquemas usan las mismas claves y el mismo problema difícil, pero la estructura lineal de Schnorr hace que las multifirmas, la firma de umbral y la verificación por lotes resulten naturales, mientras que la estructura de ECDSA las complica.

De un vistazo

En qué se diferencian

Ambos firman con un nonce secreto k y su punto R = k·G. ECDSA combina el hash z, la clave privada d y r (la coordenada x de R) mediante el inverso modular de k. Schnorr, en cambio, calcula el hash del compromiso, la clave pública y el mensaje para obtener un desafío e, y responde con s = k + e·d, que el verificador comprueba como s·G = R + e·P.

Esa única decisión de diseño determina todo lo demás:

• Linealidad. Las firmas Schnorr se pueden sumar. Varios firmantes pueden combinar sus nonces y sus respuestas parciales en una única firma que se verifica con la suma de sus claves. MuSig2 (BIP-327) lo hace en dos rondas para la firma n de n; FROST (RFC 9591) hace la firma de umbral t de n. En ECDSA, el inverso de k rompe la linealidad, así que la firma de umbral con ECDSA requiere protocolos multipartitos pesados, que las billeteras y los servicios de custodia utilizan, pero que han tenido errores graves.
• Verificación por lotes. Muchas firmas Schnorr pueden comprobarse juntas más rápido que una por una, algo importante para la validación de bloques. ECDSA no tiene un atajo así.
• Compromiso con la clave. Como e es un hash que incluye la clave pública, una firma Schnorr no puede reutilizarse con otra clave, y la clave no se puede recuperar a partir de la firma. ECDSA permite la recuperación de la clave pública, de la que Ethereum depende para ahorrar bytes; con Schnorr debes transmitir la clave o conocerla.
• Maleabilidad. En ECDSA, tanto (r, s) como (r, n − s) se verifican, así que Bitcoin exige low-S y DER estricto. BIP-340 fija una única codificación, de modo que terceros no pueden alterar una firma válida.
• Historia. El esquema de Claus Schnorr de 1989 estaba patentado, y DSA (y más tarde ECDSA) se diseñó para esquivar la patente; esta caducó en 2008, cuando ECDSA ya se había afianzado. EdDSA (2011) es una variante determinista de Schnorr sobre curvas de Edwards.

Qué cambió Taproot en la práctica

Una salida Taproot se compromete con una única clave x-only de 32 bytes. Gastar por la ruta de clave (key path) requiere una sola firma Schnorr de 64 bytes, tanto si esa clave pertenece a una persona como si es una agregación MuSig2 de varias, así que en la cadena un gasto multifirma 2 de 2 o 3 de 3 se ve igual que cualquier gasto con una sola firma. Las condiciones de gasto alternativas se guardan en un árbol de Merkle de scripts que solo se revela cuando se usa. El equivalente en SegWit v0 de un gasto con una sola clave lleva en el witness una firma ECDSA DER de hasta 72 bytes, más un byte de sighash y una clave pública de 33 bytes.

El script siguiente, ejecutado con @noble/curves 2.3.0 sobre Node.js 26.10, muestra la diferencia de tamaño para una misma clave secreta.

import { secp256k1, schnorr } from "@noble/curves/secp256k1.js";
import { sha256 } from "@noble/hashes/sha2.js";
import { utf8ToBytes } from "@noble/hashes/utils.js";

const secretKey = secp256k1.utils.randomSecretKey();
const msg = sha256(utf8ToBytes("pay 0.01 BTC to bc1p..."));

// ECDSA: 33-byte compressed public key, 64-byte compact (r, s) signature.
const ecdsaPub = secp256k1.getPublicKey(secretKey, true);
const ecdsaSig = secp256k1.sign(msg, secretKey, { prehash: false });

// BIP-340 Schnorr: 32-byte x-only public key, 64-byte (R.x, s) signature.
const schnorrPub = schnorr.getPublicKey(secretKey);
const schnorrSig = schnorr.sign(msg, secretKey);

console.log("ECDSA   public key:", ecdsaPub.length, "bytes, signature:", ecdsaSig.length, "bytes, valid:", secp256k1.verify(ecdsaSig, msg, ecdsaPub, { prehash: false }));
console.log("Schnorr public key:", schnorrPub.length, "bytes, signature:", schnorrSig.length, "bytes, valid:", schnorr.verify(schnorrSig, msg, schnorrPub));

ECDSA   public key: 33 bytes, signature: 64 bytes, valid: true
Schnorr public key: 32 bytes, signature: 64 bytes, valid: true

La forma compacta de ECDSA también ocupa 64 bytes, pero los scripts de Bitcoin llevan ECDSA en DER, y Ethereum añade un byte de recuperación; la forma Schnorr es la que va a la cadena tal cual.

Trampas comunes a ambos

Ninguno de los dos esquemas perdona un nonce defectuoso: reutilizar k en dos mensajes, o filtrar repetidamente unos pocos bits de él, revela la clave privada en ambos. BIP-340 recomienda derivar el nonce de la clave y del mensaje, mezclados con 32 bytes de aleatoriedad auxiliar nueva. La firma Schnorr multipartita añade una regla nueva: los nonces de MuSig2 nunca deben derivarse de forma determinista solo a partir del mensaje, porque un atacante que controle a otro participante puede hacer que el mismo nonce firme dos desafíos agregados distintos. Usa implementaciones auditadas, como el módulo MuSig2 de libsecp256k1, en lugar de combinar primitivas por tu cuenta.

Cuándo elegir cada uno

• Billeteras y salidas nuevas de Bitcoin: gastos por la ruta de clave de Taproot con Schnorr; MuSig2 para claves multipartitas cuando los participantes puedan coordinarse, y rutas de script (script path) como alternativa de respaldo.
• Firma de mensajes en Bitcoin: BIP-322 para direcciones Taproot, ya que el formato BIP-137, más antiguo, solo conoce ECDSA.
• Ethereum y cadenas EVM: ECDSA, porque las transacciones, ecrecover y las billeteras lo esperan; las cuentas inteligentes pueden verificar otros esquemas en el código del contrato.
• Nostr: Schnorr BIP-340, como exige NIP-01.
• Custodia con umbral: FROST donde los verificadores acepten firmas Schnorr o EdDSA; ECDSA de umbral solo donde la cadena de destino exija ECDSA.
• Sistemas fuera de las cadenas de bloques: Ed25519 te ofrece el diseño de Schnorr con un estándar (RFC 8032), compatibilidad en las bibliotecas y nonces deterministas.

Notas de migración

En Bitcoin, la misma clave secreta puede producir los dos tipos de firma, pero son las salidas las que determinan qué se exige: la migración consiste en mover los fondos de salidas P2WPKH o P2PKH a salidas P2TR.

1. Actualiza el software y el hardware de la billetera a versiones compatibles con Taproot (ruta de derivación BIP-86 m/86'/0'/0') y con los campos Taproot de PSBT.
2. Usa correctamente las claves x-only: las claves de BIP-340 omiten el byte de paridad y se ajustan (tweak) con el compromiso del árbol de scripts; no reutilices las codificaciones de clave pública de ECDSA.
3. Pasa la firma de mensajes a BIP-322 para que las direcciones Taproot puedan demostrar su titularidad.
4. Para la multifirma, elige entre la agregación por la ruta de clave con MuSig2 (la opción más privada y más barata, pero interactiva) y las rutas de script de Tapscript con OP_CHECKSIGADD (no interactivas; revelan la política cuando se usan).
5. Sigue verificando ECDSA para las salidas antiguas; las reglas de consenso admiten ambos de forma indefinida.

Referencias

• BIP-340, firmas Schnorr para secp256k1
• BIP-341, Taproot
• BIP-327, MuSig2
• RFC 9591, FROST
• FIPS 186-5, ECDSA
• SEC 1 v2, §4.1 ECDSA
• RFC 8032, EdDSA
• BIP-146, low-S