Taproot

Qué no podía hacer bien SegWit v0

Una salida SegWit de versión 0 que protege fondos con una multifirma de 2 de 3 es un P2WSH. Al gastarla, el script completo, con las tres claves públicas, queda en la cadena. Cualquiera ve que era una multifirma y con qué tres claves. Si además hay una condición alternativa, como una recuperación tras un timelock, se publican todas las ramas aunque solo se use una. Y cada clave, cada firma y cada condición pagan espacio.

Taproot (BIP-340, BIP-341 y BIP-342) intenta arreglar eso sin añadir supuestos de seguridad nuevos, según dice el propio BIP-341. Su objetivo declarado es mejorar la privacidad, la eficiencia y la flexibilidad de los scripts. Las firmas Schnorr, que Taproot usa, se explican en firmas Schnorr. Aquí interesa lo que se construye encima.

La salida P2TR: clave interna, tweak y clave de salida

Una salida P2TR es un programa witness de versión 1. Su scriptPubKey mide 34 bytes: OP_1 y un push de 32 bytes con la clave de salida Q, en formato x-only. Nada más. No hay hash de un script ni de una clave: la propia clave está a la vista.

Q no es una clave cualquiera. Sale de una clave interna P y de un tweak: Q = P + t·G, con t = hash_TapTweak(P || raíz del árbol de scripts). Si no hay scripts, BIP-341 recomienda igualmente aplicar el tweak solo con P. La razón aparece cuando la clave interna es de varias partes: sin ese tweak, una de ellas podría haber metido una ruta de script sin que las demás lo notaran. Esa es la fórmula de BIP-86, que fija también la ruta de derivación m/86'/0'/account'/change/index para una billetera (wallet) de clave única. Bitcoin Core crea por defecto el descriptor BIP-86 en las billeteras con descriptores desde la versión 23.0 (doc/bips.md). Ojo, que eso no cambia la dirección de recepción por defecto: sigue siendo bc1q (DEFAULT_ADDRESS_TYPE en wallet.h).

Las direcciones usan Bech32m (BIP-350), no Bech32. Con Bech32, si el checksum acababa en «p», se podían insertar o borrar caracteres «q» justo antes de esa «p» final sin invalidarlo. Bech32m cambia la constante del checksum de 1 a 0x2bc830a3 y se aplica a las versiones de witness 1 a 16. En mainnet, P2TR empieza por bc1p. Ese prefijo solo dice que es una salida de versión 1. No dice si hay scripts detrás.

Dos formas de gastar

Por la clave (key path), el witness lleva un único elemento: una firma BIP-340 válida para Q, de 64 bytes, o de 65 si indica un sighash explícito. Eso es todo. No se sabe si existía un árbol de scripts, ni cuántas personas había detrás, ni si la clave la generó una sola persona o varias. En el caso común, el de BIP-86, firma una sola persona con una clave normal.

Por script (script path), el witness lleva los datos que satisfacen un script, el script de una hoja y un control block. El control block mide 33 + 32m bytes, con m entre 0 y 128. Su primer byte combina la versión de la hoja con la paridad de Q. Después van la clave interna P y m hashes hermanos, que pueden ser de hojas o de subárboles enteros. El validador recalcula la raíz, comprueba que encaja con Q y ejecuta el script. Este gasto revela el script usado, su versión, la clave interna, la profundidad de la hoja y que no se gastó por la clave. Las demás hojas no se publican, solo aparecen hashes en el camino.

El árbol de scripts, y por qué «MAST» despista

Las hojas son scripts completos. Cada hoja se hashea con hash_TapLeaf, y los pares de nodos se combinan con hash_TapBranch, ordenando los dos hashes lexicográficamente. La profundidad máxima es 128. BIP-341 aconseja colocar las hojas más probables más arriba, con la forma de un árbol de Huffman.

Mucha gente lo llama MAST (Merkelized Abstract Syntax Tree). No es un error grave: BIP-341 nombra el término, junto con BIP-114 y BIP-117, como antecedente, y BIP-114 ya usaba un árbol de Merkle para codificar ramas excluyentes de un script. Pero la sigla habla de un árbol sintáctico, y lo que Taproot especifica es un árbol de Merkle de scripts alternativos, de los que se ejecuta uno entero. «Árbol de scripts» describe mejor lo que hay. Si una salida no debe poder gastarse por la clave, se usa una clave interna sin clave privada conocida (tipo NUMS). BIP-341 propone el punto H, al que conviene sumar r·G con r aleatorio, para que nadie pueda reconocerla como la clave habitual.

Tapscript

Tapscript es la versión de hoja 0xc0 (BIP-342). Dentro de Tapscript, y en el gasto por clave, las firmas son Schnorr de BIP-340. Las salidas antiguas y las de versión 0 siguen con ECDSA. Tres cambios importan.

Primero, OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY están desactivados: hacen fallar el script. Probar combinaciones de firmas y claves impide validar por lotes, que es una de las ventajas de Schnorr. En su lugar está OP_CHECKSIGADD. Un 2 de 3 se escribe así: <A> OP_CHECKSIG <B> OP_CHECKSIGADD <C> OP_CHECKSIGADD 2 OP_NUMEQUAL. Cada clave se comprueba contra su firma, o contra un hueco vacío, y se suma 1 por cada firma válida. Una firma vacía suma 0. Una firma no vacía que no sea válida hace fallar el script.

Segundo, los opcodes OP_SUCCESSx. Son opcodes sin uso, o desactivados desde antiguo, como OP_CAT (126) y OP_MUL. Si uno aparece en el script, aunque la ejecución nunca llegue a él, el script tiene éxito de forma incondicional, porque se comprueba antes de ejecutar. Un soft fork futuro puede darles significado, con más margen que los antiguos OP_NOPx. Es una de las vías por las que podrían entrar opcodes que permiten covenants: BIP-347 propone reutilizar el 126 para devolver OP_CAT en Tapscript. Es una propuesta, no está activada. Además, una clave pública que no mida 0 ni 32 bytes se trata como de tipo desconocido, una vía para esquemas de firma nuevos. La de 0 bytes hace fallar el script.

Tercero, el presupuesto de firmas. Cada entrada dispone de 50 unidades más el tamaño de su witness, y cada firma no vacía gasta 50. Sustituye al límite de sigops. Se eliminan los topes de 10.000 bytes de script y de 201 opcodes, y se mantienen los de 1.000 elementos de pila y 520 bytes por elemento. Más sobre el lenguaje en Bitcoin Script.

Multifirma: qué oculta MuSig2 y qué no

MuSig2 (BIP-327) es un esquema de n de n. La agregación de claves es no interactiva: cualquiera puede calcular la clave conjunta a partir de las claves públicas. Para firmar, las n partes ejecutan dos rondas, una de nonces y otra de firmas parciales, y obtienen una firma que pasa la verificación de BIP-340 para esa clave x-only. Es compatible con BIP-340, no derivado de él. Sumar claves públicas sin ese protocolo es inseguro, por el ataque de clave falsa (rogue key). Y reutilizar un nonce secreto permite extraer la clave privada de quien firma.

Un 2 de 3 con MuSig2 no queda oculto del todo. Se puede poner MuSig2(A,B) como clave interna y las otras dos parejas, (A,C) y (B,C), como hojas. Si firman A y B, el gasto es por la clave y parece un pago a una sola clave. Si firman A y C, hay que revelar una hoja. Solo el par del key path se esconde. Un umbral t de n indistinguible exige un esquema de firma umbral, como FROST. Su firma para BIP-340 es el borrador BIP-445, que a 7 de octubre de 2026 seguía abierto como PR #2070 en bitcoin/bips, sin fusionar. No es un estándar. Ya hay productos con implementaciones propias de FROST, fuera del proceso BIP, pero eso no lo convierte en BIP. Las multifirmas que se usan hoy (P2WSH o Tapscript con OP_CHECKSIGADD) se explican en las billeteras multifirma.

Tampoco hay agregación de firmas entre entradas. Una transacción con varias entradas P2TR lleva una firma por entrada. Schnorr permite, en teoría, validarlas por lotes, lo que acelera la verificación pero no reduce el tamaño. BIP-340 lo define, pero Bitcoin Core aún no lo hace: el módulo de libsecp256k1 seguía sin fusionar en octubre de 2026. Lo que sí comparten las entradas es el mensaje firmado: con el tipo de firma por defecto, el sighash de BIP-341 compromete los importes y los scriptPubKeys de todas las entradas, algo útil para un firmador offline, que ya no puede ser engañado sobre la comisión. SegWit v0 no lo cubría del todo, como se cuenta en la entrada de SegWit.

Bitcoin Core admite descriptores musig() y campos PSBT desde la versión 30.0 (octubre de 2025), y la firma desde la 31.0 (doc/bips.md).

Límites reales de la privacidad

Taproot hace parecidos muchos gastos distintos, pero no es una capa de anonimato. Las billeteras se delatan por sus comisiones, por nVersion, nLockTime, el orden de entradas y salidas y la forma de dar el cambio. Gastar por script revela el script. Los scripts reconocibles, como los de Lightning o las inscripciones, se identifican. Reutilizar una dirección con árbol puede mostrar más hojas con el tiempo. Y todos los participantes conocen el árbol entero. Una clave NUMS sin aleatorizar también marca la salida.

Tampoco es más barato en el caso común. Las firmas no son iguales: la de P2TR por clave es Schnorr de 64 bytes, y la de P2WPKH es ECDSA de unos 72 bytes. La salida P2TR ocupa 43 bytes (8 de valor, 1 de longitud y 34 de script), frente a 31 de una P2WPKH. La entrada P2TR por clave pesa unos 57,5 vB y la P2WPKH unos 68. Por UTXO, creando y gastando, salen 43 + 57,5 = 100,5 vB para P2TR y 31 + 68 = 99 vB para P2WPKH (98,75 con una firma de 71 bytes). Una transacción de una entrada y dos salidas, toda P2TR, pesa 154 vB frente a 141 vB de la P2WPKH (cálculo propio). Con clave única, el coste es prácticamente igual o algo mayor. La ventaja está en las multifirmas y los contratos, donde un gasto cooperativo por clave evita publicar el script. Si gastas por script, el coste depende de la hoja y de su profundidad.

Activación y adopción

Las reglas de Taproot rigen desde el bloque 709.632, minado el 14 de noviembre de 2021 a las 05:15:27 UTC (mempool.space). El proceso está en la activación de Taproot.

Para el uso reciente, mainnet.observer (la fuente que usa Murch en la lista bitcoindev), en medias de 30 días del 6 de septiembre al 5 de octubre de 2026 y con cálculo propio sobre sus series diarias: P2TR fue el 5,5 % de las salidas, el 7,3 % de las entradas se gastó por clave y el 0,8 % por script. Es una cuota del tráfico, no del número de usuarios: sube y baja con lo que otros tipos de salida meten en la cadena. A mediados de 2025 (11 de junio a 10 de julio) la misma cuenta daba el 20,6 %, el 15,9 % y el 7,3 %.

El reparto del conjunto UTXO no está en esas series. Lo más reciente es de julio de 2025: según el panel de Dune que citó Murch en bitcoindev el 12 de julio de 2025, el 34,7 % de los UTXO, por número, eran P2TR (57.956.440), pero sumaban unos 156.309 BTC, el 0,79 % del suministro.

Qué significa para ti

Si tu billetera genera direcciones bc1p con BIP-86, gastas con una clave y una firma de 64 bytes. En el ciclo completo no ahorras: tus entradas son más ligeras al gastar, pero cada salida bc1p, también tu cambio, ocupa 12 bytes más. El provecho grande llega con contratos y multifirmas: un gasto cooperativo por clave, y las condiciones alternativas fuera de la vista. Pero antes de confiar en la privacidad, mira qué revelan tus hábitos. Y si usas una multifirma con umbral, comprueba qué protocolo emplea tu software, porque FROST aún es un borrador.