Glossário / Referência do desenvolvedor
OP_CHECKSIG
- O que é OP_CHECKSIG?
- OP_CHECKSIG retira da pilha uma chave pública e uma assinatura e verifica que a assinatura se compromete com esta transação, que é a checagem que de fato prova que você é dono dos bitcoins.
Quase todo bitcoin já gasto passou por este único opcode, o byte 0xac. Ele monta um resumo da transação de acordo com o byte de sighash colado ao fim da assinatura, confere a assinatura contra a chave pública e coloca true ou false na pilha. Se colocar false, o gasto não acontece, e é nisso que consiste, em código, ser dono de bitcoin.
Como funciona
OP_CHECKSIG retira dois itens da pilha, a chave pública primeiro e a assinatura logo abaixo dela, e depois executa três tarefas distintas que as pessoas costumam reduzir a uma só.
Primeiro ele decide o que foi assinado. O último byte de uma assinatura não faz parte da assinatura: é um indicador que diz quais partes da transação o resumo cobriu. O valor mais comum de longe é 0x01, que significa todas as entradas e todas as saídas, de modo que alterar qualquer parte da transação depois de assinada a invalida. A receita para montar esse resumo foi substituída duas vezes, pelo BIP-143 para gastos de SegWit versão 0 e de novo pelo BIP-341 para o Taproot, nas duas vezes para impedir que o custo de calcular o hash crescesse com o quadrado do tamanho da transação.
Segundo ele confere a codificação, e o bitcoin é incomumente rigoroso nesse ponto. Uma assinatura legada precisa ser DER válido, com no máximo 72 bytes incluindo o byte do indicador, com o valor S na metade inferior da ordem da curva. A regra de codificação estrita chegou como BIP-66 em julho de 2015, e a transição deixou seis blocos órfãos em uma única tarde porque vários pools grandes estavam construindo sobre cabeçalhos de bloco que não tinham validado. Continua sendo a demonstração mais clara de que minerar e validar são tarefas diferentes.
Terceiro ele verifica. Gastos legados e gastos de SegWit versão 0 usam ECDSA sobre secp256k1. O Tapscript usa em vez disso uma assinatura Schnorr de 64 bytes sob o BIP-340, exige que uma checagem que falhe coloque na pilha um item vazio e não qualquer outra coisa, e cobra do orçamento do script 50 unidades de peso por cada assinatura verificada.
Onde você o encontra
OP_CHECKSIG encerra quase todo script que existe. Uma saída legada termina com ele, um gasto SegWit nativo de chave única executa o mesmo modelo com o mesmo opcode final ainda que esses bytes nunca apareçam na blockchain, e os scripts de compromisso da Lightning terminam com ele depois de seus ramos de timelock e de revogação.
A exceção vale a pena conhecer quando você consulta um explorador de blocos. Um gasto por caminho de chave do Taproot não executa script nenhum: o nó confere uma única assinatura diretamente contra a chave de 32 bytes da saída. Não há assembly a exibir nem opcode a apontar, e é exatamente por isso que esse tipo de gasto é o mais barato e o mais privado disponível, e por isso um endereço bc1p gasto apenas pelo seu dono parece idêntico on-chain a qualquer outro.
OP_CHECKSIG vs OP_CHECKSIGADD
O OP_CHECKSIGADD existe porque o OP_CHECKSIG não pode ser contado. Em um script de várias partes é preciso saber quantas das assinaturas apresentadas eram boas, e o projeto antigo respondia a isso com um único opcode que engolia de uma vez uma lista inteira de chaves e assinaturas. O Tapscript o substituiu por um opcode que verifica uma assinatura e soma um ao total acumulado na pilha, de modo que uma política de 2 de 3 se torna uma sequência curta que termina em uma comparação com 2. A mudança não é cosmética: contar uma assinatura de cada vez é o que permite verificar assinaturas Schnorr em lotes, e da verificação em lotes vem a velocidade de validação do Taproot.