Gasto por ruta de clave

Una salida Taproot puede vaciarse firmando con su clave o revelando un script fijado, y la ruta de clave es la discreta. BIP-341 establece que ese testigo tiene exactamente un elemento, una firma Schnorr de 64 bytes con el sighash predeterminado, lo que hace que la entrada completa ocupe 230 unidades de peso, o 57,5 vbytes. Para un tenedor, una bóveda compartida y un pago individual se ven entonces iguales on-chain.

Cómo funciona

Un gasto por ruta de clave firma con la clave de salida, que no es una clave que haya elegido nadie: BIP-341 la construye como Q = P + int(t)G, donde P es la clave pública interna y t es un hash etiquetado de P junto con la raíz de Merkle del árbol de scripts.

Por eso, firmar supone aplicar ese mismo desplazamiento al lado privado. La rutina de referencia cambia primero el signo de la clave privada cuando el punto interno tiene una coordenada y impar, porque el ajuste (tweak) de Taproot se aplica a claves x-only (solo coordenada x) de 32 bytes, y después suma t módulo el orden de la curva. El resultado firma según BIP-340 y pasa a la pila del testigo como único elemento.

La validación es una comprobación de recuento antes de ser una comprobación criptográfica. Un nodo lee los 32 bytes del programa de testigo, hace fallar el gasto de inmediato si la pila del testigo está vacía y elimina el último elemento como anexo cuando hay dos o más elementos y ese elemento empieza por 0x50. Si queda exactamente un elemento, el gasto es un gasto por ruta de clave, y ese elemento tiene que verificarse como firma BIP-340 con la clave de salida. Nada en ese procedimiento le dice al nodo si la salida fijó alguna vez un árbol de scripts.

La firma mide 64 bytes cuando está implícito el indicador SIGHASH_DEFAULT, de valor 0x00, que cubre toda la transacción. Llega a 65 bytes cuando se añade un byte de sighash distinto, y una firma de 65 bytes que lleve 0x00 en esa última posición se rechaza deliberadamente: permitirla dejaría que un minero o cualquier nodo que la retransmita rellenara una firma de 64 bytes hasta 65, lo que cambiaría el wtxid y la comisión por vB que pretendía el remitente.

Lo que cubre la firma es, como máximo, un mensaje de 206 bytes. Cubre la versión y el locktime de la transacción, los hash del outpoint, del monto, del scriptPubKey anterior y del número de secuencia de cada entrada, y las salidas.

La aritmética del tamaño se desprende de ahí. Según BIP-141, el peso de la transacción es el tamaño base por tres más el tamaño total, y el tamaño virtual es ese peso dividido entre cuatro, redondeado hacia arriba para una transacción entera. Una entrada Taproot aporta 41 bytes base (un outpoint de 36 bytes, un byte de longitud para un scriptSig vacío, un número de secuencia de cuatro bytes) y 66 bytes de testigo (un recuento de elementos de la pila, un prefijo de longitud, la firma), lo que da 41 por 3 más 107, o 230 unidades de peso, y por tanto 57,5 vbytes.

Una recomendación de BIP-341 toma por sorpresa a los autores de billeteras. Una salida sin ningún script debería fijar igualmente un ajuste, calculado como un hash etiquetado de la clave interna por sí sola, en lugar de publicar la clave interna intacta. La especificación explica por qué: cuando dos partes suman sus claves en una clave de salida compartida, una de ellas puede incorporar en silencio un ajuste que oculte una ruta de script gastable solo por ella, y la otra no tiene forma de notarlo.

Por qué importa cuando compra bitcoin

El mensaje de firma de Taproot es la razón por la que una billetera de hardware puede calcular su comisión sin confiar en la computadora a la que está conectada.

Con BIP-143, las reglas de la versión 0 de SegWit, el mensaje cubría el monto que gastaba la entrada firmada y nada más. Un dispositivo que firmaba una entrada de una transacción de tres entradas tenía que recibir los otros dos montos y no podía comprobarlos, que es la puerta que aprovecha una computadora comprometida para que usted autorice con su firma unas comisiones muy superiores a las que mostraba la pantalla. Con BIP-341, el mensaje cubre los montos de todas las entradas que gasta la transacción y todos sus scriptPubKeys anteriores, así que un firmante puede sumarlos por sí mismo. Esa actualización también abarca los gastos por ruta de script, pero la ruta de clave es donde la encontrará la mayoría de los propietarios de los dispositivos de nuestras 41 reseñas de billeteras.

Su billetera tiene que poder derivar las claves antes de que nada de esto se aplique, y en esas reseñas el panorama es desigual. KeepKey añadió compatibilidad con salidas Taproot en el firmware 7.10.0 en febrero de 2025. El propio anuncio de MetaMask todavía presenta Taproot como algo que llegará más adelante, así que no puede darle una dirección bc1p en la que recibir, sea cual sea el resto de su compatibilidad con bitcoin.

Las comisiones se inclinan hacia la ruta de clave por un pequeño margen por entrada, que se acumula según la forma en que compra la mayoría de los lectores. La entrada P2WPKH firmada del propio vector de prueba de BIP-143 lleva una firma de 71 bytes y una clave de 33 bytes, 107 bytes de testigo una vez contados el recuento de elementos de la pila y los prefijos de longitud, lo que da 271 unidades de peso, o 67,75 vbytes. Una entrada por ruta de clave ahorra 10,25 vbytes frente a eso, así que un ahorrador que ha acumulado 30 compras pequeñas por separado y más tarde las consolida recorta alrededor de 307 vbytes de esa única transacción.

Tenga claro qué compra realmente la privacidad. Ocultar su política de gasto no es ocultar su historial: si las monedas vinieron de uno de los 63 exchanges que reseña este sitio, esa plataforma ya tiene sus documentos de identidad y la dirección de retiro, y ningún formato de firma toca eso. Lo que queda oculto es si la moneda estaba protegida por una clave o por un quórum con una rama de recuperación de un abogado, y ese segundo dato es el que hace que valga la pena atacar una dirección.

Recorrido por taproot_sign_key

La función taproot_sign_key es la rutina de referencia que BIP-341 publica para producir exactamente este testigo, y entera ocupa nueve líneas de Python.

Recibe un árbol de scripts, la clave privada interna, un tipo de sighash y la aleatoriedad auxiliar que pide BIP-340. Cuando el árbol de scripts está vacío, asigna al valor de entrada del ajuste una cadena de bytes vacía; si no, ese valor es la raíz de Merkle que devuelve la función auxiliar del árbol. Ajusta la clave privada interna con ese valor, firma el sighash, añade el byte del tipo de hash solo cuando el tipo no es cero y devuelve una lista con un solo elemento. Ese elemento es todo el testigo.

Dos detalles merecen atención. La rama vacía no es el caso sin ajuste que parece, porque pasar una cadena de bytes vacía deja el ajuste como el hash etiquetado de la clave interna por sí sola, que es exactamente el compromiso imposible de gastar que la especificación recomienda para una salida sin scripts. Y el argumento de aleatoriedad pertenece a BIP-340 y no a Taproot: una vez ajustada la clave, el resultado es una firma Schnorr corriente, y por eso los gastos por ruta de clave no necesitan ningún tratamiento especial para verificarse por lotes.

Gasto por ruta de clave frente a P2TR

P2TR es el tipo de salida, y un gasto por ruta de clave es una de las dos formas de vaciar una. Una moneda sigue siendo una moneda P2TR sin importar qué ruta la vacíe después. La distinción importa cuando alguien le dice que las direcciones Taproot son privadas: recibir en una publica una clave de 32 bytes y nada más en cualquier caso, mientras que la privacidad de la que habla la gente llega en el momento de gastar, y solo si la ruta tomada es la de clave.

Gasto por ruta de clave frente a MuSig2

MuSig2 es una forma de producir la firma que necesita un gasto por ruta de clave, no un requisito de este. Un único propietario que firma con una sola clave hace un gasto por ruta de clave cada vez que paga, sin ningún protocolo de agregación a la vista. Los dos se confunden porque la agregación es el caso interesante: MuSig2 permite que varias partes lleguen a una sola clave y a una sola firma, así que su liquidación toma la misma ruta y ocupa los mismos 57,5 vbytes que alguien que paga el almuerzo. También funciona a la inversa, ya que una clave agregada puede estar dentro de una hoja de script, donde gastarla es un gasto por ruta de script que resulta usar MuSig2.