MSG_WITNESS_TX

Si se solicita una transacción por su txid con MSG_WITNESS_TX, se recibe la versión con las firmas incluidas. Bitcoin Core 0.21.0, publicada el 14 de enero de 2021, añadió la retransmisión por wtxid y reemplazó en gran medida esta solicitud por el tipo MSG_WTX, que solicita por hash de testigo. Para quien envía monedas, la ventaja es que una firma alterada ya no hace desaparecer un pago de la retransmisión.

Cómo funciona

Toda transacción SegWit tiene dos identidades, y MSG_WITNESS_TX existe porque hay que indicarle a un par cuál de ellas se le solicita.

El txid es el doble SHA-256 de la transacción sin su testigo: versión, entradas, salidas y locktime. El wtxid es el mismo hash calculado sobre la serialización completa, con el byte marcador, el byte indicador y las pilas del testigo incluidos. En una transacción sin ningún testigo, los dos son iguales. Para la transacción coinbase, BIP141 define el wtxid como 32 bytes de ceros, un caso especial que existe para que la raíz de Merkle de testigo tenga algo bien definido de lo que colgar.

El código de la solicitud es 0x40000001: el tipo de transacción 1 con el indicador de testigo 0x40000000 añadido encima. Si se envía un mensaje getdata con el tipo 1 sin más, el par responde con los bytes sin datos de testigo, que bastan para ver adónde fue el dinero y no sirven para comprobar si el gasto estaba autorizado.

Esta división es lo que acabó con el viejo problema de la maleabilidad de transacciones. Antes de SegWit, un tercero podía recodificar una firma, cambiar el txid y dejar al remitente atento a una transacción que ya no existía con ese nombre. Dejar las firmas fuera del txid cerró esa puerta, y cerrarla es lo que permitió confiar con seguridad en las transacciones prefirmadas de los canales Lightning.

BIP339 llevó después la lógica un paso más allá. Los pares que envían un mensaje wtxidrelay antes del mensaje verack anuncian las transacciones por wtxid con el tipo de inventario 5, y Bitcoin Core lo hace desde la 0.21.0. Lo que se gana está en la caché de rechazos: un nodo que rechazó un testigo malformado ya no rechaza una copia honesta de la misma transacción, porque las dos tienen wtxid distintos. MSG_WITNESS_TX sobrevive para los pares que nunca negociaron la retransmisión por wtxid, lo que en la práctica significa software anterior a esa versión.

Dónde aparece

El lugar más claro para ver el txid y el wtxid lado a lado es la respuesta de las llamadas RPC de transacciones del propio Bitcoin Core.

Ejecute la llamada RPC getrawtransaction en modo detallado sobre cualquier gasto SegWit y obtendrá un campo txid y un campo hash. Son distintos. El hash es el wtxid, y la diferencia es el único rastro visible de los datos de testigo en un objeto JSON por lo demás corriente. Los exploradores de bloques indexan por txid, así que ese es el número que hay que pegar en el cuadro de búsqueda para comprobar si su retiro ha llegado.

En la red, la llamada RPC getpeerinfo cuenta los mensajes por tipo, y las solicitudes de transacciones de ese desglose serán una mezcla en cualquier nodo bien conectado: MSG_WTX para los pares modernos y MSG_WITNESS_TX para los rezagados.

Nada de esto es algo que un comprador configure. Importa de forma indirecta. Cuando un exchange le dice que un retiro se ha difundido y su billetera no lo encuentra, la pregunta útil es si el txid que le dieron llegó alguna vez a la mempool, no qué serialización intercambiaron los pares.

MSG_WITNESS_TX frente a MSG_TX

MSG_TX nombra la misma transacción y la devuelve sin ninguna de sus firmas. Esa forma es la que entendían los nodos anteriores a SegWit, y todavía circula hacia pares que nunca anunciaron el bit de servicio NODE_WITNESS. La distinción no es estética: un nodo que recibe la versión sin datos de testigo puede comprobar la estructura de la transacción, pero no validarla, así que no puede colocarla con seguridad en una mempool ni retransmitirla como verificada. Bitcoin Core no envía una transacción SegWit a un par que solo habla la forma antigua.