O que é Taproot, a regra de gasto do Bitcoin que só revela a condição usada

Taproot é o novo tipo de saída do Bitcoin definido pelo BIP 341, um documento de especificação de camada de consenso com status implantado, assinado por Pieter Wuille, Jonas Nick e Anthony Towns e que depende do BIP 340. A proposta é um tipo de saída SegWit versão 1 cujas regras de gasto se baseiam em três peças: Taproot, assinaturas Schnorr e ramos de Merkle. A motivação declarada é melhorar a privacidade, a eficiência e a flexibilidade dos scripts do Bitcoin sem acrescentar novas premissas de segurança.

O que já vale não é plano: o BIP 341 foi implantado junto com o BIP 342. Na mainnet e na testnet3 a ativação foi feita por version bits com o nome taproot, usando o BIP 9 modificado com um limiar menor e com um parâmetro de altura mínima de ativação. Na mainnet o limiar exigido foi de 1.815 blocos, ou 90 por cento, em vez dos 1.916 blocos de 95 por cento do BIP 9 padrão, e a altura mínima fixada foi o bloco 709632. A janela de sinalização começou à meia-noite de 24 de abril de 2021, em UTC, e o prazo terminava à meia-noite de 11 de agosto de 2021. O documento afirma que a implantação ativou de fato na altura 709632 da mainnet e na altura 2.011.968 da testnet3; na signet esses BIPs estão sempre ativos.

A saída em si tem uma forma simples. Um output Taproot é uma saída SegWit nativa, com número de versão 1 e um programa de testemunha de 32 bytes. Esse programa é uma chave pública Q, calculada como Q = P + hash(P||m)G, em que P é a chave interna e m é a raiz de uma árvore de Merkle cujas folhas são um número de versão e um script. Um detalhe em relação às construções anteriores é que a chave pública é colocada diretamente na saída, em vez de apenas um hash dela.

A partir daí existem dois caminhos de gasto. No caminho por chave, sobra um único elemento na pilha de testemunha, interpretado como a assinatura: 64 bytes de assinatura Schnorr, conforme o BIP 340, com um byte de sighash opcional. Se esse byte for omitido, a assinatura tem 64 bytes e o modo SIGHASH_DEFAULT fica implícito. No caminho por script, sobram dois elementos ou mais: o penúltimo é o script e o último é o bloco de controle, que precisa ter 33 + 32m bytes, com m inteiro entre 0 e 128. Nesse caminho a transação revela a chave interna, o script, a versão da folha, as entradas que satisfazem o script e o caminho de Merkle que prova que Q foi comprometida com aquela folha.

A economia de privacidade vem de duas decisões de projeto. Ramos de Merkle permitem revelar à blockchain apenas a parte do script que foi efetivamente executada, em vez de todas as maneiras pelas quais o script poderia ser executado. E o Taproot funde as políticas antes separadas pay-to-pubkey e pay-to-scripthash: todas as saídas passam a ser gastáveis por chave ou, opcionalmente, por script, e ficam indistinguíveis entre si. Enquanto o caminho por chave é usado, não é revelado se um caminho por script existia. A especificação também registra os limites disso: um gasto por caminho por script entrega que existe um caminho por script e que o caminho por chave não era aplicável, e a profundidade do script na raiz de Merkle vaza informação, incluindo a profundidade mínima da árvore, o que sugere qual software de carteira criou a saída e ajuda a agrupar transações. Por isso a recomendação do documento é nunca reutilizar chaves entre saídas.

As assinaturas Schnorr também são o que torna esse desenho prático. Elas permitem agregar chaves: uma chave pública pode ser construída a partir das chaves públicas de vários participantes e exige cooperação de todos para assinar, e chaves e assinaturas de múltiplas partes são indistinguíveis das de uma parte só. Com isso a maioria das aplicações pode usar o caminho por chave, que é ao mesmo tempo eficiente e privado. O mesmo mecanismo generaliza para políticas arbitrárias de M-de-N, já que as assinaturas Schnorr suportam assinatura por limiar, ao custo de protocolos de configuração mais complexos. Schnorr ainda permite validação em lote, em que várias assinaturas são conferidas juntas de forma mais eficiente do que uma a uma.

A parte da assinatura também mudou. O novo algoritmo de hash da assinatura corrige a verificação de dispositivos de assinatura offline ao incluir o valor e o scriptPubKey na mensagem assinada, o que impede um dispositivo de ser enganado sobre a taxa. O algoritmo evita cálculos de hash desnecessários, usa hashes com tag para separação de domínio e define um byte de sighash padrão. Cada script da árvore carrega uma versão, de modo que novas versões de script possam ser introduzidas por soft fork permanecendo compatíveis com o BIP 341. O campo annex, hoje sem uso dentro da testemunha, está reservado para extensões futuras: até que outro soft fork defina seu significado, o documento manda não incluí-lo nas transações, sob pena de perda permanente de fundos.

Por fim, a compatibilidade. Como soft fork, o software antigo continua operando sem modificação, mas nós não atualizados passam a tratar todos os programas de testemunha SegWit versão 1 como scripts de gasto por qualquer pessoa, razão pela qual a atualização é fortemente encorajada. Carteiras não atualizadas continuam recebendo e enviando por programas SegWit versão 0 e pelo tradicional pay-to-pubkey-hash, e podem inclusive enviar para programas versão 1 se implementarem os endereços Bech32m do BIP 350. A escolha da forma da árvore é definida pelo software de carteira e não faz parte do consenso: o documento sugere uma árvore balanceada quando as condições são igualmente prováveis e uma árvore de Huffman quando as probabilidades são conhecidas.