Datos de testigo

Cada entrada recibe su propio testigo: una pila de elementos, en la mayoría de los casos una firma y una clave pública. La sección va después de las salidas, detrás de dos bytes, un marcador y un indicador, que avisan al software de que la transacción está en el formato más nuevo. Un nodo que ejecuta software anterior a la actualización de 2017 nunca la pide y nunca la ve.

Cómo funciona

Los datos de testigo tienen su propio lugar en la estructura de bytes de una transacción, que define el BIP-144.

Una transacción serializada en el formato más nuevo se lee así: la versión, el byte marcador 0x00, el byte indicador 0x01, las entradas, las salidas, después una pila del testigo por cada entrada, en el mismo orden, y por último el locktime. El marcador es donde reside el truco de compatibilidad, porque un valor de cero significaría cero entradas para el analizador antiguo, lo cual no tiene sentido, así que el software antiguo que recibe el formato nuevo sabe de inmediato que no es para él, y a los pares heredados (legacy) simplemente nunca se les envía.

De aquí salen dos identificadores. El txid es un doble SHA-256 de la transacción sin el marcador, el indicador ni los testigos, y por eso nada de lo que hay dentro de un testigo puede alterarlo. El wtxid, en cambio, es el hash de la serialización completa. Cada bloque fija una raíz de Merkle de sus wtxid dentro de una salida coinbase, una salida OP_RETURN cuyo script mide al menos 38 bytes y empieza por la etiqueta de cuatro bytes 0xaa21a9ed, de modo que los datos quedan protegidos aunque vivan fuera del compromiso más antiguo.

El costo es donde se nota el descuento. Todo lo que queda fuera del testigo cuenta cuatro unidades de peso por byte y todo lo que va dentro cuenta una, con un tope de 4.000.000 unidades de peso por bloque. Si se divide el peso de una transacción entre cuatro, se obtienen bytes virtuales, que es la unidad en la que se expresa la comisión por vB.

Dónde aparece

Abra cualquier transacción en un explorador de bloques y verá el tamaño, el tamaño virtual y el peso de la transacción uno junto a otro. Cuando no coinciden, la diferencia es el testigo. Un pago sin ningún testigo muestra un tamaño igual a su vsize; un pago Taproot puede mostrar un vsize de apenas una cuarta parte de su tamaño en bruto.

Al desplegar una sola entrada en un explorador moderno, se ve la propia pila. En un pago desde una dirección que empieza por bc1q son dos elementos, una firma de alrededor de 71 o 72 bytes y una clave pública comprimida de 33 bytes, y en un gasto por ruta de clave de Taproot es un solo elemento de exactamente 64 bytes. Ese recuento es toda la razón por la que gastar desde los tipos de salida más nuevos resulta más barato.

El campo también aparece en los archivos que maneja su billetera de hardware. Una transacción de bitcoin parcialmente firmada tiene, por cada entrada, un registro de UTXO de testigo y un registro de testigo final, que es lo que una aplicación coordinadora va pasando de un lado a otro mientras una transacción multisig reúne firmas.

Datos de testigo frente a script de testigo

Los datos de testigo son toda la pila; un script de testigo es un elemento dentro de ella. En un gasto P2WSH, el último elemento de la pila es el script cuyo hash la salida fijó, y todo lo que va antes existe para satisfacer ese script. La relación copia exactamente el patrón antiguo, en el que un script de canje es el último elemento de un script de desbloqueo P2SH. Así que todo script de testigo forma parte de los datos de testigo, mientras que la mayoría de los datos de testigo, incluidos los de cualquier gasto ordinario de una sola clave, no contienen ningún script de testigo.