MSG_WITNESS_TX

Peça uma transação pelo seu txid com MSG_WITNESS_TX e você recebe de volta a versão com as assinaturas anexadas. Bitcoin Core 0.21.0, lançado em 14 de janeiro de 2021, adicionou o relay por wtxid e em grande parte substituiu esta solicitação pelo MSG_WTX, que pede pelo hash da testemunha. Para quem envia bitcoins, o ganho é que uma assinatura alterada não faz mais um pagamento desaparecer do relay.

Como funciona

Toda transação segwit tem duas identidades, e o MSG_WITNESS_TX existe porque é preciso dizer a um par qual delas está sendo solicitada.

O txid é o SHA-256 duplo da transação sem sua testemunha: versão, entradas, saídas, locktime. O wtxid é o mesmo hash calculado sobre a serialização completa, incluindo o byte marcador, o byte de sinalização e as pilhas de testemunha. Para uma transação sem nenhuma testemunha, os dois são iguais. Para a transação coinbase, o BIP141 define o wtxid como 32 bytes de zero, um caso especial que existe para que a raiz de Merkle de testemunha tenha algo bem definido de onde pender.

O código da solicitação é 0x40000001: o tipo de transação 1 com o sinalizador de testemunha 0x40000000 somado por cima. Envie um getdata com o tipo 1 puro e o par responde com os bytes sem os dados de testemunha, que bastam para ver para onde o dinheiro foi e são inúteis para verificar se o gasto foi autorizado.

Essa divisão é o que acabou com o antigo problema de maleabilidade. Antes do segwit, um terceiro podia recodificar uma assinatura, mudar o txid e deixar o remetente esperando por uma transação que não existia mais sob aquele nome. Mover as assinaturas para fora do txid fechou essa porta, e fechá-la é o que tornou seguro confiar nas transações pré-assinadas dos canais Lightning.

O BIP339 então levou a lógica um passo adiante. Os pares que enviam uma mensagem wtxidrelay antes do verack anunciam transações por wtxid usando o tipo de inventário 5, e o Bitcoin Core faz isso desde o 0.21.0. O ganho está no cache de rejeição: um nó que recusou uma testemunha malformada não recusa mais uma cópia honesta da mesma transação, porque as duas têm wtxids diferentes. O MSG_WITNESS_TX sobrevive para os pares que nunca negociaram o relay por wtxid, o que na prática significa software anterior a essa versão.

Onde você vê isso

O lugar mais claro para encontrar txid e wtxid lado a lado é a saída das próprias chamadas RPC de transação do Bitcoin Core.

Chame getrawtransaction com saída detalhada em qualquer gasto segwit e você obtém um campo txid e um campo hash. Eles diferem. O hash é o wtxid, e a diferença é o único vestígio visível dos dados de testemunha em um objeto JSON de resto comum. Os exploradores de blocos indexam por txid, então esse é o número a colar em uma caixa de busca ao verificar se seu saque chegou.

Na rede, getpeerinfo conta as mensagens por tipo, e as solicitações de transação nesse detalhamento serão uma mistura em qualquer nó bem conectado: MSG_WTX para os pares modernos, MSG_WITNESS_TX para os atrasados.

Nada disso é algo que um comprador configura. Importa de forma indireta. Quando uma corretora informa que um saque foi transmitido e sua carteira não o encontra, a pergunta útil é se o txid que você recebeu chegou alguma vez à mempool, não qual serialização os pares trocaram.

MSG_WITNESS_TX vs MSG_TX

O MSG_TX nomeia a mesma transação e a devolve com todas as assinaturas removidas. Essa forma é a que os nós anteriores ao segwit entendiam, e ela ainda circula para pares que nunca anunciaram NODE_WITNESS. A distinção não é cosmética: um nó que recebe a versão sem os dados de testemunha consegue confirmar a estrutura da transação, mas não validá-la, então não pode colocá-la com segurança em uma mempool nem retransmiti-la adiante como verificada. O Bitcoin Core não envia uma transação segwit a um par que só fala a forma mais antiga.