BIP 340 (firmas Schnorr para secp256k1)

El BIP 340 es el documento que define cómo se crea y se comprueba una firma Schnorr sobre la curva de Bitcoin. Claus Schnorr publicó el esquema subyacente en 1989, pero no había un estándar para usarlo con secp256k1, y un esquema de firmas sin una especificación exacta es un bug de consenso anunciado. Los autores del BIP, Pieter Wuille, Jonas Nick y Tim Ruffing, se propusieron arreglar eso. El primer borrador llegó a la lista bitcoin-dev en julio de 2018, el número se asignó en enero de 2020 y el esquema se activó en mainnet con Taproot en noviembre de 2021.

La especificación toma cuatro decisiones que conviene conocer. Las claves públicas son x-only, de 32 bytes en vez de 33, dando por sentado que la coordenada Y es par. Las firmas tienen 64 bytes fijos, la coordenada X de un punto de nonce R seguida de un escalar s, en lugar de la codificación DER de longitud variable del ECDSA, de hasta 72 bytes. Cada hash dentro del esquema es un hash etiquetado (tagged hash), así que un hash calculado para un propósito nunca puede confundirse con uno calculado para otro. Y el valor de desafío se compromete con la clave pública además del nonce y el mensaje, lo que bloquea una clase de ataques de claves relacionadas que, de otro modo, romperían la derivación BIP 32 y el ajuste (tweak) de Taproot.

La ecuación de verificación es s*G = R + e*P, con e = hash(r || P || m). Como esa ecuación es lineal, las firmas de varias claves sobre el mismo mensaje se suman en una firma válida para la suma de las claves, que es la base de MuSig2 (en inglés) y de todo diseño que hace que un gasto entre varias partes se vea como el de una sola. La linealidad también permite a un verificador comprobar muchas firmas en una sola ecuación combinada; el BIP se escribió para que la verificación por lotes sea posible, aunque en 2026 Bitcoin Core todavía comprueba las firmas de una en una.

El BIP también fija cómo se firma. Reutilizar un nonce filtra la clave privada, así que el procedimiento de firma por defecto deriva el nonce de la clave secreta, el mensaje y 32 bytes de aleatoriedad fresca, todo junto, y verifica su propio resultado antes de publicarlo. Eso es seguro incluso con un mal generador de números aleatorios. La firma entre varias partes es la excepción: los nonces de MuSig2 nunca deben ser deterministas, y el BIP lo dice.

El BIP 340 se aplica solo a SegWit versión 1, es decir, a los gastos por la ruta de clave de Taproot y a las comprobaciones de firma de Tapscript. Todo gasto legacy y SegWit versión 0 sigue usando ECDSA, y la mayor parte de los bitcoins sigue en esas salidas. El esquema tampoco es resistente a la computación cuántica: descansa en el mismo problema del logaritmo discreto que el ECDSA. Fuera de Bitcoin, la misma especificación la usan Nostr y las Offers (ofertas, BOLT 12) de Lightning.

Consulta Cómo funciona Taproot en realidad (en inglés) para saber qué cambió el esquema en la práctica, y para la historia de la patente que la mayoría de las explicaciones cuenta mal.