Witness Data

Ana recibió Bitcoin y ahora quiere pagar a Pedro. El pago anterior creó una salida: un registro de una cantidad y de las condiciones para gastarla después. La nueva transacción hace referencia a esa salida mediante una entrada. No basta con afirmar que las monedas pertenecen a Ana. En un pago habitual, la cartera crea una firma verificable sin revelar la clave privada. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. La clave privada es un valor numérico secreto con el que se crea esa firma. Con SegWit, esos datos se presentan como witness de la entrada. Que haya una firma todavía no significa que sea correcta. [1] [4] [5]

Piensa en la diferencia entre «presentar un documento válido» y el documento que realmente se presenta. En Bitcoin no decide una persona: las reglas comprueban la relación. El witness program forma parte de la condición registrada en la salida anterior; su versión determina cómo se evalúa. La nueva transacción que la gasta aporta el witness. Técnicamente, es una lista ordenada de datos para cada entrada. No es automáticamente un programa ejecutable ni una copia de todas las monedas sin gastar. [1] [7]

Witness puede revelar una firma, una clave pública o el script utilizado, el programa que describe las condiciones de gasto. La clave pública sirve para verificar firmas y no tiene que mantenerse en secreto. No es un buzón cifrado. La clave privada se queda contigo: sirve para firmar, no para enviarla a la red en lugar de la firma. Ni witness ni una firma publicada sustituyen a la Seed Phrase, las palabras que permiten recuperar una cartera. Si pierdes las claves y la copia de seguridad, el historial público no te devuelve por sí solo la capacidad de firmar nuevos pagos. [1] [3] [4]

Un explorador de bloques es una aplicación para consultar transacciones y bloques de una red concreta. Un explorador puede mostrar wtxid junto a txid. Ambos son hashes, huellas breves calculadas sobre una representación exacta de los datos aplicando SHA-256 dos veces. txid usa el formato sin witness; wtxid incluye el formato completo con witness. No son direcciones de destino ni dos pagos diferentes. Si no hay witness, se utiliza el formato original y ambos identificadores coinciden. En Bitcoin Core v29.0, decoderawtransaction muestra el identificador completo en hash; los datos witness de una entrada aparecen en txinwitness. [1] [7] [8]

Una transacción puede referirse a otra antes de que esta se confirme. Si alguien cambiara su identificador modificando únicamente los datos de firma, la referencia dejaría de coincidir. Cambiar solo witness no cambia txid, lo que ayuda a protocolos con transacciones dependientes, como Lightning Network. Eso no hace inmutable toda la transacción. Otros campos o entradas antiguas sin SegWit pueden seguir afectando a txid, y un witness modificado debe cumplir las reglas de verificación correspondientes. [1] [6]

Witness viaja con la representación completa de la transacción y pasa a formar parte de los datos del bloque al incluirse. No es almacenamiento gratuito fuera de la cadena. Un byte añadido por la serialización witness aporta 1 WU al peso, frente a 4 WU de un byte básico; WU significa unidad de peso. Un Full Node comprueba las reglas por sí mismo y necesita los datos pertinentes para validar el gasto. Un peso menor no permite omitir comprobaciones ni significa que los datos no ocupen almacenamiento. [1] [7]

En el formato antiguo, las pruebas para gastar se escribían en scriptSig. SegWit nativo de versión 0 exige que ese campo esté vacío: las pruebas están en witness. Existe también una variante encapsulada en P2SH, la forma anterior de pagar a una condición identificada por el hash de un script. En ella, scriptSig debe contener exactamente la inserción del witness program correspondiente, sin instrucciones adicionales arbitrarias. Las pruebas siguen en witness. El mismo propósito puede tener distintas representaciones; el nombre del campo no basta para interpretarlo. [1] [5]

P2WPKH presenta una firma y una clave pública. El nodo comprueba que el hash de la clave coincide con la condición original y que la firma es válida. P2WSH permite una condición identificada por el hash de un script completo. Su último elemento witness es witnessScript, cuyo hash debe coincidir con el programa de la salida. Los elementos anteriores aportan los datos iniciales de ejecución, como firmas. BIP 143 define cómo se construye el mensaje firmado para esta versión, incluido el valor de la salida gastada. Leer los datos correctamente no demuestra que las condiciones se cumplan. [1] [2] [5]

Taproot usa witness nativo de versión 1 y permite gastar por una ruta de clave o de script. Antes de decidir la ruta se aparta el annex, si existe: es un campo adicional cuyos datos siguen contando para el peso y estando cubiertos por la firma. Si queda un solo elemento, se interpreta como la firma de la ruta de clave. La ruta de script revela el script utilizado y un control block, datos que prueban su vínculo con la salida anterior, no un nuevo bloque de la cadena. Los elementos previos, si los hay, aportan datos al script. No se pueden trasladar sin más las reglas de la versión 0. [3] [5]

Un compromiso criptográfico (commitment) es una huella que vincula unos datos con su contenido concreto. Cuando se requiere ese compromiso con los datos witness, BIP 141 los vincula al resto del bloque mediante la Coinbase Transaction, la primera transacción destinada a la recompensa del minero. Un árbol de hashes wtxid produce una raíz que resume los datos incluidos. Para la transacción de recompensa se usa un wtxid nulo en ese árbol. La raíz se combina con un valor reservado de 32 bytes y se aplica el hash dos veces para obtener el compromiso registrado en su salida. Si ninguna transacción tiene witness, el compromiso es opcional. Vincula pruebas públicas; no respalda claves ni sustituye a la verificación. [1]