La respuesta corta
Bitcoin siempre usó firmas digitales para demostrar que un gasto fue autorizado. Hasta noviembre de 2021 tenía exactamente un esquema de firma, ECDSA, y las firmas ECDSA no se combinan. Taproot agregó un segundo, Schnorr, que sí lo hace: varias claves públicas se suman en una sola clave pública, y las partes de firma correspondientes se suman en una sola firma que verifica contra ella. La especificación tiene un nombre para esa propiedad: la linealidad.
Todo lo que se celebra de Taproot se desprende de ahí, más un cambio estructural: una salida ahora puede comprometerse con un árbol de condiciones de gasto alternativas y publicar solo la rama usada. Un gasto que requiere el acuerdo de cinco personas puede llegar a la cadena como una firma contra una clave, indistinguible de una persona gastando sola.
Qué demuestra una firma
Una salida no tiene dueño en ningún sentido que el software entienda. Lleva una condición, y quien la satisface mueve las monedas. Una firma satisface la condición más común: demuestra que quien gasta posee una clave privada, sin poner esa clave donde un nodo pudiera leerla. La criptografía asimétrica es la pieza que va debajo de esta. El esquema que hace esa demostración es una elección, y Bitcoin eligió distinto en 2021.
Dónde se detiene ECDSA
El BIP 340 nombra lo que Bitcoin venía haciendo, ECDSA sobre la curva secp256k1 con hashes SHA256, y enumera sus desventajas frente a Schnorr sobre la misma curva. Las firmas Schnorr son demostrablemente seguras bajo supuestos más débiles. Son no maleables, mientras que las firmas ECDSA son "intrínsecamente maleables": un tercero sin la clave secreta puede alterar una firma válida y obtener otra válida para la misma clave y el mismo mensaje. Se codifican en 64 bytes fijos en vez de una codificación DER variable de hasta 72. Sus claves públicas ocupan 32 bytes en lugar de 33. Y pueden verificarse por lotes, cosa que la formulación estandarizada de ECDSA no permite.
La que importa acá es la linealidad. En palabras del BIP 340, las firmas Schnorr "ofrecen un método simple y eficiente que permite a varias partes en colaboración producir una firma que es válida para la suma de sus claves públicas".
La razón está en la ecuación de verificación. Una firma BIP 340 es un par (r, s) y
verifica cuando s·G = R + h(r || pk || m)·P, donde P es la clave pública, R un punto
de nonce, G el punto base de la curva y h un hash etiquetado. Las claves públicas son
puntos, y los puntos se suman; los valores s son enteros, y los enteros se suman. Un
grupo que acuerda un R compartido puede entonces calcular cada parte de s a partir de
su propio secreto, y esas partes suman un s válido para la suma de sus claves. En ECDSA
el valor s involucra un inverso modular del nonce, y eso rompe la simetría.
Nada de esto vuelve imposible el ECDSA multiparte. El BIP 340 señala que trabajos recientes afirman que estas aplicaciones "también son posibles con ECDSA", pero que el soporte de consenso para Schnorr "simplificaría significativamente las construcciones".
Tres BIPs, y cuál hace qué
La actualización suele mencionarse como una sola cosa. Son tres especificaciones, las tres marcadas como Deployed, y confundirlas es donde empieza la confusión.
| BIP | Título | Qué especifica |
|---|---|---|
| 340 | Schnorr Signatures for secp256k1 | El esquema de firma en sí: firmas de 64 bytes, claves públicas X-only de 32 bytes, hashes etiquetados, verificación por lotes. Por sí solo no cambia ninguna regla de Bitcoin. |
| 341 | Taproot: SegWit version 1 spending rules | El tipo de salida y cómo se gasta: un programa de testigo de 32 bytes, una vía de clave, una vía de script, y el árbol de Merkle de scripts que hay detrás. |
| 342 | Validation of Taproot Scripts | Tapscript: las reglas de script dentro de una hoja de ese árbol. |
El BIP 342 es el que se suele saltear, y trae un cambio real. Dentro de tapscript,
OP_CHECKSIG y OP_CHECKSIGVERIFY verifican firmas BIP 340 en lugar de firmas ECDSA,
OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY quedan directamente deshabilitados, y un nuevo
OP_CHECKSIGADD los reemplaza para que las mismas políticas de multifirma sigan siendo
verificables por lotes. Los tres se activaron juntos en el bloque 709.632,
cubierto acá cuando ocurrió.
La clave de salida, y el árbol detrás de ella
Una salida Taproot es una salida SegWit versión 1 cuyo programa de testigo de 32 bytes es
una clave pública, la clave de salida q. El BIP 341 la construye como
Q = P + int(hash_TapTweak(p || k))·G, donde p es una clave pública interna y k la raíz
de Merkle de un árbol cuyas hojas contienen cada una un número de versión y un script.
El consenso elige entre dos maneras de gastarla contando la pila de testigo. Si queda
exactamente un elemento después de quitar el annex opcional, es un gasto por vía de
clave y ese elemento es la firma, verificada contra q. Si quedan dos o más, es un gasto
por vía de script: el anteúltimo elemento es el script, el último un bloque de control
de 33 + 32m bytes que lleva la clave interna y el camino de Merkle, y el nodo recalcula
la raíz para comprobar que produce q.
Eso es lo que aporta MAST. El BIP 341 lo dice en una línea: las ramas de Merkle "nos permiten revelar a la cadena de bloques solo la parte del script que efectivamente se ejecutó, en lugar de todas las formas posibles en que un script puede ejecutarse". Una wallet puede tener una vía cotidiana, una vía de recuperación tras un timelock y una vía que exige un cofirmante; un gasto revela una, y las demás quedan como hashes dentro de una raíz que nunca se expandió. La vía de clave es todavía más fuerte, porque el BIP 341 señala que "mientras se use la vía de gasto basada en clave, no se revela si además estaba permitida una vía de script".
La afirmación sobre el tamaño es exacta, no aproximada. Un testigo de vía de clave es una única firma de 64 bytes, o de 65 con un byte de sighash explícito, y la salida ocupa 32 bytes. Ninguno de esos números depende de cuánta gente cooperó para producir esa firma. Mismo peso, misma comisión, misma apariencia.
Sumar claves no es, por sí solo, multisig
Acá es donde se desvían los relatos populares. La linealidad significa que las claves y las partes de firma pueden sumarse. No significa que sumarlas sea seguro.
Tomemos a Alice con clave pública XA y a Bob con XB, agregando mediante la suma de los dos puntos. Bob no publica XB sino XB menos XA. Pieter Wuille, uno de los autores del BIP 340, expuso lo que sigue en enero de 2018:
Si lo hace, los demás asumirán que XA + XB' es la clave agregada para la cual Alice y Bob necesitan cooperar para poder firmar. Lamentablemente, esa suma es igual a XB, y Bob claramente puede firmar por sí solo.
La suma que todos tratan como clave conjunta es una clave que Bob controla solo. Esto es un ataque de clave espuria (rogue-key attack). Exigir que cada parte demuestre que posee la clave privada detrás de la clave que publica lo cierra, pero Wuille califica esa mitigación de "frágil en el mejor de los casos", y por eso la agregación necesita un protocolo y no una suma.
El BIP 327 especifica ese
protocolo, MuSig2. Pondera cada clave con un coeficiente derivado de un hash de la lista
completa de claves antes de sumar, lo que elimina el ataque, y define un protocolo de firma
interactivo de dos rondas. Tres límites lo acompañan. Es informativo y no de consenso, así
que es una convención entre wallets, no una regla que los nodos hagan cumplir. Es un
esquema n-de-n y explícitamente "no un esquema de firma de umbral t-de-n", así que un
arreglo 2-de-3 sigue necesitando o bien un esquema de
umbral como FROST o bien una hoja de script con OP_CHECKSIGADD. Y el BIP 340 advierte, en
negrita, que los esquemas de firma multifirma "en general son inseguros" con la generación
determinista de nonces que el propio documento especifica, lo contrario del consejo para un
firmante único. La multifirma agregada es un problema de ingeniería de wallets que Taproot
hizo posible, no uno que resolvió.
El BIP 341 agrega una trampa relacionada. Si el agregado es una suma simple, una de las partes puede colar una vía de script en el tweak sin que las demás lo noten y gastar esquivando la política. La recomendación del BIP es comprometerse con una vía de script no gastable incluso cuando no se quiere ninguna.
Lo que no hace
No es privacidad para la cadena. Los montos, las direcciones y los vínculos entre transacciones son tan públicos como en 2009. Taproot reduce una filtración, la forma de la condición de gasto, y no toca nada más.
No volvió inseguras ni obsoletas a las salidas anteriores. Taproot es un soft fork, y el BIP 341 es explícito en que las salidas que no son de versión 1 con 32 bytes "quedan sin restricciones" ("remain unencumbered"). Nada de una dirección P2WPKH o P2PKH cambió.
No es automático. Una salida Taproot existe solo si una wallet la construye, y la agregación de claves solo si las wallets implementan un protocolo interactivo y se ponen de acuerdo. La adopción es una decisión por wallet, tomada una y otra vez a lo largo de años.
Y la propiedad de privacidad es colectiva. Un gasto multisig cooperativo es indistinguible de un gasto de clave única solamente dentro de una multitud de gastos de clave única. La guía de construcción del BIP 341 muestra lo filoso que es esto: cuando el gasto por vía de clave es genuinamente imposible, recomienda derivar la clave interna como un punto Nothing Up My Sleeve más un desplazamiento aleatorio, únicamente "para evitar filtrar la información de que el gasto por vía de clave no es posible". Una propiedad que cada persona tiene que sostener por su cuenta es una de la que se puede salir sin querer.
Fuentes
- BIP 340, Schnorr Signatures for secp256k1, Wuille, Nick y Ruffing
- BIP 341, Taproot: SegWit version 1 spending rules, Wuille, Nick y Towns
- BIP 342, Validation of Taproot Scripts, Wuille, Nick y Towns
- BIP 327, MuSig2 for BIP340-compatible Multi-Signatures, Nick, Ruffing y Jin
- Pieter Wuille, Key Aggregation for Schnorr Signatures, Blockstream, 23 de enero de 2018
- Nick, Ruffing y Seurin, MuSig2: Simple Two-Round Schnorr Multi-Signatures