OP_CHECKSIGADD

O opcode recebe três itens da pilha, uma assinatura, uma contagem corrente e uma chave pública, e devolve a contagem sem alteração ou aumentada em um. O BIP-342 atribuiu a ele o opcode 186 e desativou o OP_CHECKMULTISIG ao mesmo tempo, de modo que toda multiassinatura em script Taproot é escrito dessa forma. O ganho prático é que uma política de limiar não para mais em 20 chaves.

Como funciona

Um limiar em tapscript é uma cadeia de verificações de assinatura com uma contagem transmitida de uma para a seguinte, e uma comparação no final.

Escrito por extenso, um dois de três fica assim: coloque a primeira chave pública, OP_CHECKSIG, coloque a segunda, OP_CHECKSIGADD, coloque a terceira, OP_CHECKSIGADD, coloque 2, OP_NUMEQUAL. A execução caminha da esquerda para a direita. O OP_CHECKSIG deixa 1 ou 0 na pilha, e cada OP_CHECKSIGADD retira uma chave pública, retira esse total corrente, retira a assinatura oferecida para essa chave e devolve o total com 1 somado se a assinatura foi verificada. A comparação final decide se assinaturas suficientes foram verificadas.

Um assinante que não participa fornece uma cadeia de bytes vazia no lugar de uma assinatura. O opcode a vê, trata a posição como não assinada e devolve a contagem intacta, o que custa um único byte na testemunha. Esse é todo o mecanismo, e ele elimina o elemento fictício da pilha que o OP_CHECKMULTISIG exigia por causa de um erro de um a mais na implementação original.

Duas consequências decorrem de verificar uma chave contra uma assinatura. A verificação passa a poder ser feita em lote: um nó pode lançar todas as assinaturas Schnorr do bloco em uma única verificação agregada em vez de testar chaves candidatas em ordem, o que é grande parte do ganho de velocidade de validação do Taproot. E o número de chaves é limitado pelo orçamento de validação do tapscript, que gasta 50 unidades de peso por assinatura verificada, e não por um teto fixo escrito no opcode.

Onde você o encontra

O OP_CHECKSIGADD aparece em qualquer script Taproot que precise de mais de um assinante, o que no software de carteira geralmente significa um descritor e não um script bruto.

O Bitcoin Core o expõe como os fragmentos multi_a e sortedmulti_a dentro de um descritor tr(), de modo que um quórum de três chaves é escrito como tr(internalkey,multi_a(2,KEY1,KEY2,KEY3)) e o software emite a cadeia de opcodes para você. O Miniscript o trata da mesma forma, e os dispositivos de hardware que aceitam políticas Taproot assinam esses scripts sem precisar conhecer a disposição de antemão.

O projeto também muda a forma como você pode montar um quórum. Em vez de uma folha que contém as três chaves, uma taptree pode conter três folhas separadas de duas chaves, uma por par possível, e um gasto revela então apenas o par que de fato assinou. Isso custa mais em folhas de script e economiza uma chave pública na testemunha, e é uma melhoria real de privacidade em relação a publicar o conjunto completo de chaves em cada gasto.

OP_CHECKSIGADD vs OP_CHECKMULTISIG

O OP_CHECKSIGADD e o OP_CHECKMULTISIG contam assinaturas contra um conjunto de chaves, e apenas um deles funciona em uma folha Taproot. O OP_CHECKMULTISIG continua perfeitamente válido em scripts legados e SegWit versão 0, então a multiassinatura bc1q que as pessoas usam há anos não é afetado e não precisa de migração.

Dentro do tapscript, o OP_CHECKMULTISIG e o OP_CHECKMULTISIGVERIFY estão desativados por completo. Além desse cenário, três diferenças importam: o opcode antigo limita um script a 20 chaves públicas e o novo não tem esse número, o antigo exige um item fictício extra na pilha, que o BIP-147 mais tarde obrigou a ser vazio como regra de consenso, e o antigo não pode ser verificado em lote porque um verificador não sabe de antemão a qual chave pertence cada assinatura.