Dados de testemunha

Cada entrada recebe a sua própria testemunha: uma pilha de itens, na maioria das vezes uma assinatura e uma chave pública. A seção fica depois das saídas, atrás de um marcador e um indicador de dois bytes que avisam ao software que a transação está no formato mais novo. Um nó que executa software anterior à atualização de 2017 nunca a pede e nunca a vê.

Como funciona

Os dados de testemunha têm seu próprio lugar na estrutura de bytes de uma transação, definido pelo BIP-144.

Uma transação serializada no formato mais novo se lê assim: a versão, o byte marcador 0x00, o byte indicador 0x01, as entradas, as saídas, depois uma pilha de testemunha por entrada, na mesma ordem, e por último o locktime. O marcador é onde está o truque de compatibilidade, porque um valor de zero significaria zero entradas para o analisador antigo, o que não faz sentido, então o software antigo que recebe o formato novo sabe de imediato que não é para ele, e os pares legados simplesmente nunca a recebem.

Dois identificadores saem disso. O txid é um SHA-256 duplo da transação sem o marcador, o indicador e as testemunhas, e por isso nada dentro de uma testemunha pode alterá-lo. O wtxid, em vez disso, é o hash da serialização completa. Cada bloco fixa uma raiz de Merkle de seus wtxids dentro de uma saída coinbase, uma saída OP_RETURN cujo script tem pelo menos 38 bytes e começa pela etiqueta de quatro bytes 0xaa21a9ed, de modo que os dados ficam protegidos mesmo vivendo fora do compromisso mais antigo.

O custo é onde o desconto aparece. Tudo o que fica fora da testemunha é cobrado a quatro unidades de peso por byte e tudo o que fica dentro é cobrado a uma, contra um teto de 4.000.000 unidades de peso por bloco. Divida o peso por quatro e você obtém bytes virtuais, que é a unidade em que as taxas por vB são cotadas.

Onde você vê isso

Abra qualquer transação em um explorador de blocos e o tamanho, o tamanho virtual e o peso aparecerão lado a lado. Quando eles não coincidem, a diferença é a testemunha. Um pagamento sem nenhuma testemunha mostra um tamanho igual ao seu vsize; um pagamento Taproot pode mostrar um vsize de apenas um quarto do seu tamanho bruto.

Ao expandir uma única entrada em um explorador moderno, você vê a própria pilha. Em um pagamento feito de um endereço que começa com bc1q são dois itens, uma assinatura de cerca de 71 ou 72 bytes e uma chave pública comprimida de 33 bytes, e em um gasto por caminho de chave Taproot é um único item de exatamente 64 bytes. Essa contagem é toda a razão pela qual gastar a partir dos tipos de saída mais novos sai mais barato.

O campo também aparece nos arquivos que sua carteira de hardware manipula. Uma transação de bitcoin parcialmente assinada tem, por entrada, um registro de UTXO de testemunha e um registro de testemunha final, que é o que um aplicativo coordenador fica passando de um lado para o outro enquanto uma transação de multiassinatura reúne assinaturas.

Dados de testemunha vs script de testemunha

Os dados de testemunha são a pilha inteira; um script de testemunha é um item dentro dela. Em um gasto P2WSH, o último item da pilha é o script cujo hash a saída fixou, e tudo o que vem antes existe para satisfazer esse script. A relação copia exatamente o padrão antigo, em que um script de resgate é o último item de um script de assinatura P2SH. Assim, todo script de testemunha é dado de testemunha, enquanto a maioria dos dados de testemunha, incluindo os de qualquer gasto comum de uma só chave, não contém nenhum script de testemunha.