Gasto pelo caminho da chave

Uma saída Taproot pode ser esvaziada assinando com sua chave ou revelando um script comprometido, e a rota da chave é a discreta. O BIP-341 fixa essa testemunha em exatamente um elemento, uma assinatura Schnorr de 64 bytes sob o sighash padrão, o que faz toda a entrada ocupar 230 unidades de peso, ou 57,5 vbytes. Para um detentor, um cofre compartilhado e um pagamento individual passam então a parecer iguais on-chain.

Como funciona

Um gasto por caminho de chave assina com a chave da saída, que não é uma chave escolhida por ninguém: o BIP-341 a constrói como Q = P + int(t)G, onde P é a chave pública interna e t é um hash etiquetado de P junto com a raiz de Merkle da árvore de scripts.

Assinar, portanto, significa aplicar esse mesmo deslocamento ao lado privado. A rotina de referência nega a chave secreta primeiro quando o ponto interno tem coordenada y ímpar, porque os ajustes do taproot são aplicados a chaves x-only de 32 bytes, e depois soma t módulo a ordem da curva. O resultado assina sob o BIP-340 e vai para a pilha da testemunha sozinho.

A validação é um teste de contagem antes de ser um teste criptográfico. Um nó lê os 32 bytes do programa de testemunha, falha de imediato se a pilha da testemunha estiver vazia e retira o último elemento como anexo quando há dois ou mais elementos e esse elemento começa com 0x50. Se restar exatamente um elemento, o gasto é um gasto por caminho de chave, e esse elemento tem de ser verificado como uma assinatura do BIP-340 em relação à chave da saída. Nada nesse procedimento diz ao nó se uma árvore de scripts chegou a ser comprometida.

A assinatura tem 64 bytes quando o SIGHASH_DEFAULT, valor 0x00, está implícito, o que cobre toda a transação. Ela chega a 65 bytes quando um byte de sighash diferente é anexado, e uma assinatura de 65 bytes que carregue 0x00 nessa última posição é rejeitada de propósito: permitir isso deixaria um minerador ou qualquer nó que a retransmita preencher uma assinatura de 64 bytes até 65, mudando o wtxid e a taxa por vbyte que o remetente pretendia.

O que a assinatura cobre é no máximo 206 bytes de mensagem. Ela se compromete com a versão e o locktime da transação, com hashes do outpoint, do valor, do scriptPubKey anterior e do número de sequência de cada entrada, e com as saídas.

A aritmética de tamanho decorre disso. Sob o BIP-141, o peso da transação é o tamanho base vezes três mais o tamanho total, e o tamanho virtual é esse peso dividido por quatro, arredondado para cima no caso de uma transação inteira. Uma entrada Taproot contribui com 41 bytes base (um outpoint de 36 bytes, um byte de comprimento para um scriptSig vazio, um número de sequência de quatro bytes) e 66 bytes de testemunha (uma contagem de pilha, um prefixo de comprimento, a assinatura), o que dá 41 vezes 3 mais 107, ou 230 unidades de peso, e portanto 57,5 vbytes.

Uma recomendação do BIP-341 pega os autores de carteiras de surpresa. Uma saída sem nenhum script deveria ainda se comprometer com um ajuste, calculado como um hash etiquetado da chave interna sozinha, em vez de publicar a chave interna intacta. A especificação explica por quê: quando duas partes somam suas chaves em uma chave de saída compartilhada, uma delas pode embutir em silêncio um ajuste que esconde um gasto por caminho de script que só ela pode fazer, e a outra não tem como perceber.

Por que isso importa quando você compra bitcoin

A mensagem de assinatura do Taproot é a razão pela qual uma carteira de hardware consegue calcular sua taxa sem confiar no computador em que está conectada.

Sob o BIP-143, as regras da versão 0 do SegWit, a mensagem se comprometia com o valor gasto pela entrada assinada e nada mais. Um dispositivo que assinava uma entrada de uma transação de três entradas tinha de receber os outros dois valores e não podia verificá-los, e é essa a brecha que um computador comprometido usa para fazer você assinar com muito mais em taxas do que a tela mostrava. O BIP-341 se compromete com os valores de todas as entradas que a transação gasta, e com todos os seus scriptPubKeys anteriores, de modo que um signatário pode somá-los sozinho. Essa atualização também abrange os gastos por caminho de script, mas o caminho de chave é onde a maioria dos donos dos dispositivos das nossas 41 análises de carteiras vai encontrá-la.

Sua carteira tem de conseguir derivar as chaves antes que qualquer coisa disso se aplique, e nessas análises o quadro é irregular. A KeepKey adicionou suporte a saídas Taproot no firmware 7.10.0 em fevereiro de 2025. O próprio anúncio da MetaMask ainda lista o Taproot como algo que virá depois, então ela não pode fornecer um endereço bc1p para receber, seja qual for o resto do suporte dela a bitcoin.

As taxas se inclinam para o caminho de chave por uma pequena margem por entrada, que se acumula na direção em que a maioria dos leitores compra. A entrada P2WPKH assinada do próprio vetor de teste do BIP-143 carrega uma assinatura de 71 bytes e uma chave de 33 bytes, 107 bytes de testemunha depois de contadas a contagem de pilha e os prefixos de comprimento, o que dá 271 unidades de peso, ou 67,75 vbytes. Uma entrada por caminho de chave economiza 10,25 vbytes em relação a isso, então um poupador que acumulou 30 compras pequenas separadas e depois as consolida reduz cerca de 307 vbytes dessa única transação.

Seja claro sobre o que a privacidade realmente compra. Esconder sua política de gasto não é esconder seu histórico: se os bitcoins vieram de uma das 63 corretoras que este site analisa, essa plataforma já tem seus documentos de identidade e o endereço de saque, e nenhum formato de assinatura toca nisso. O que fica oculto é se os bitcoins estavam guardados por uma chave ou por um quórum com um ramo de recuperação de um advogado, e esse segundo fato é o que faz um endereço valer a pena como alvo.

Passando por taproot_sign_key

taproot_sign_key é a rotina de referência que o BIP-341 publica para produzir exatamente essa testemunha, e ela inteira tem nove linhas de Python.

Ela recebe uma árvore de scripts, a chave secreta interna, um tipo de sighash e a aleatoriedade auxiliar que o BIP-340 pede. Quando a árvore de scripts está vazia, ela define a entrada do ajuste como uma cadeia de bytes vazia; caso contrário, essa entrada é a raiz de Merkle devolvida pelo auxiliar da árvore. Ela ajusta a chave secreta interna com esse valor, assina o sighash, anexa o byte do tipo de hash apenas quando o tipo não é zero e devolve uma lista com um item. Esse item é toda a testemunha.

Dois detalhes merecem atenção. O ramo vazio não é o caso sem ajuste que parece, porque fornecer uma cadeia de bytes vazia deixa o ajuste como o hash etiquetado da chave interna sozinha, que é exatamente o compromisso impossível de gastar que a especificação recomenda para uma saída sem scripts. E o argumento de aleatoriedade pertence ao BIP-340 e não ao Taproot: uma vez ajustada a chave, o resultado é uma assinatura Schnorr comum, e é por isso que os gastos por caminho de chave não precisam de tratamento especial para serem verificados em lote.

Gasto por caminho de chave vs P2TR

P2TR é o tipo de saída, e um gasto por caminho de chave é uma das duas formas de esvaziar uma. Um bitcoin continua sendo um bitcoin P2TR independentemente da rota que depois o esvazie. A distinção importa quando alguém diz que os endereços Taproot são privados: receber em um deles publica uma chave de 32 bytes e nada mais de qualquer forma, enquanto a privacidade que as pessoas querem dizer chega no momento do gasto, e apenas se a rota tomada for a de chave.

Gasto por caminho de chave vs MuSig2

O MuSig2 é uma forma de produzir a assinatura que um gasto por caminho de chave precisa, e não um requisito dele. Um único proprietário assinando com uma única chave faz um gasto por caminho de chave todas as vezes que paga, sem nenhum protocolo de agregação envolvido. Os dois são confundidos porque a agregação é o caso interessante: o MuSig2 permite que várias partes cheguem a uma chave e a uma assinatura, então a liquidação delas toma a mesma rota e os mesmos 57,5 vbytes de alguém que paga um almoço. Funciona também ao contrário, já que uma chave agregada pode ficar dentro de uma folha de script, onde gastá-la é um gasto por caminho de script que por acaso usa MuSig2.