Anexo do Taproot

O BIP-341 reservou o campo para futuros soft forks e não lhe deu nenhum significado, de modo que hoje nenhum nó lê seu conteúdo. O IsWitnessStandard do Bitcoin Core rejeita um gasto Taproot que carregue um anexo marcado com 0x50, então a transação não será retransmitida, e o BIP-341 adverte que isso pode levar à perda permanente de fundos. As carteiras não têm motivo para anexar um, então nada do que você faz ao comprar ou guardar bitcoin depende dele.

Como funciona

Um anexo do Taproot é identificado pela posição, e não por um campo nomeado no formato da transação. Se uma entrada Taproot carrega pelo menos dois elementos na testemunha e o primeiro byte do último elemento é 0x50, esse elemento é o anexo e é removido da pilha da testemunha antes de qualquer outra coisa ser examinada. Só então um nó decide o que está vendo: um elemento restante significa um gasto por caminho de chave, dois ou mais significam um gasto por caminho de script.

O BIP-341 escolheu 0x50 de propósito. As versões de folha vêm em pares, um par e um ímpar, que não devem ser confundidos com o primeiro byte de uma testemunha P2WPKH ou P2WSH, e 0x50 era um valor que ficou sem par, então custava o menor número de versões futuras de script. A regra também funciona ao contrário: uma versão de folha não pode ser 0x50, porque um bloco de controle que começasse com esse byte seria indistinguível de um anexo.

O que o anexo não faz é influenciar a validação. O BIP-341 diz que o campo "is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation." Toda mensagem de assinatura Taproot carrega um spend_type de um byte igual a (ext_flag * 2) + annex_present e, quando um anexo está presente, a mensagem também carrega sha_annex, o SHA256 de 32 bytes do prefixo de comprimento do anexo e do próprio anexo, incluindo o byte 0x50. A ausência é assinada com a mesma firmeza que a presença, então ninguém pode acrescentar um anexo à sua transação na mempool nem removê-lo dela. O BIP-341 coloca a mensagem de assinatura em 174 bytes, menos 49 para ANYONECANPAY, menos 32 para NONE, mais 32 quando um anexo está presente, com limite de 206.

Onde você o vê

Você não vê um anexo do Taproot no uso comum, e isso é o projeto funcionando. A política de retransmissão do Bitcoin Core, em src/policy/policy.cpp, verifica toda entrada de versão de testemunho 1 com um programa de 32 bytes e retorna false quando a testemunha contém dois ou mais elementos e o último começa com a constante ANNEX_TAG, definida como 0x50 em src/script/script.h. O comentário ao lado dessa verificação é toda a política: "Annexes are nonstandard as long as no semantics are defined for them." Uma transação que carregue um anexo é válida por consenso e impossível de entregar na prática: um nó padrão a descarta em vez de repassá-la.

Um anexo aparece de fato em um só lugar: em cada assinatura Taproot que você já fez, cujo spend_type carrega um bit com valor zero dizendo que não há anexo ali. Esse compromisso é o que tornaria utilizável um eventual soft fork: o BIP-341 nomeia como tarefa pretendida sinalizar o custo de validação de opcodes novos e caros sem que um nó precise buscar a saída que está sendo gasta.

Anexo do Taproot vs OP_RETURN

OP_RETURN é o espaço designado do bitcoin para publicar bytes que ninguém gastará, e o anexo do Taproot não é de modo algum um espaço de publicação. Ambos são descritos como espaço para dados que o consenso ignora, e se comportam de maneiras opostas. Os dados de OP_RETURN ficam em uma saída, fazem parte da transação que todo nó valida e anunciam um significado acordado: nada aqui é gastável. Os bytes do anexo ficam na testemunha, são removidos antes de a pilha ser lida e carregam uma advertência da própria especificação, de que "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS."

Essa advertência não é decoração. Um soft fork só pode acrescentar regras, então bytes ignorados hoje podem ser rejeitados amanhã, e sua assinatura se compromete com o anexo, então você não pode removê-lo de uma transação já assinada. Quem pré-assina gastos com anos de antecedência, como faz um cofre ou um canal Lightning, estaria travando um campo cujo significado ninguém escreveu ainda.