Opcode

Ana quer pagar a Pedro. Sua carteira prepara a transação e as assinaturas necessárias; os nós verificam se ela podia gastar as moedas escolhidas. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Um nó é um programa que verifica transações e blocos e se comunica com outros participantes da rede. Bitcoin Script descreve parte dessas verificações. Um opcode é uma instrução, como verificar uma assinatura. Ana não escreve instruções manualmente para um pagamento comum. Mas um nó não pode confiar no nome do dono ou na palavra “assinado”: precisa avaliar as condições. Um script válido é apenas parte da validação da transação inteira. [1] [4]

Uma representação legível pode mostrar OP_DUP ou OP_CHECKSIG. São nomes para humanos; no script, são representados por códigos de um byte. Byte é uma unidade comum para medir dados. Outras partes contêm dados, como uma chave pública. A chave pública serve para verificar assinaturas e não precisa ficar secreta. As instruções da família OP_PUSHDATA indicam quantos bytes seguintes devem ser inseridos como dados. Esses bytes não são novamente executados como instruções. Pense na diferença entre “adicione sal” em uma receita e o ingrediente colocado na tigela. [1] [2]

Imagine uma pilha de bilhetes da qual você retira o de cima. Assim funciona a pilha de trabalho básica do script. OP_DUP copia o item superior; OP_DROP o remove. Executar OP_DUP e depois OP_DROP em uma pilha não vazia devolve seu conteúdo original. Você não duplicou moedas, apenas dados de trabalho. Se faltar um item necessário, a execução pode falhar. A ordem e a representação exata também importam. [1]

OP_EQUAL pega os dois itens superiores, compara seus bytes e os substitui pelo resultado. OP_EQUALVERIFY falha imediatamente se forem diferentes; se forem iguais, continua sem deixar esse resultado na pilha. Nenhuma dessas duas operações verifica, sozinha, uma assinatura. Qualquer pessoa pode apresentar duas cópias iguais de uma chave pública. É necessária a verificação de assinatura correspondente para demonstrar que alguém conseguiu assinar a mensagem exigida. [1] [4]

OP_CHECKSIG verifica uma assinatura com uma chave pública e uma mensagem formada a partir da transação, sem revelar a chave privada. A chave privada é um valor numérico secreto usado para criar essa assinatura. O parâmetro sighash determina quais partes a assinatura cobre; nem todo modo assina tudo. Scripts antigos e SegWit versão 0 usam ECDSA, um algoritmo de assinatura. Tapscript, as regras de scripts do Taproot, usa outro algoritmo, Schnorr, para as chaves comuns de 32 bytes. O nome da instrução não basta sem esse contexto. [1] [3]

Uma condição pode permitir o gasto normal ou um caminho alternativo de recuperação. OP_IF e OP_ELSE escolhem um ramo com base em um valor da pilha; OP_ENDIF encerra a parte condicional. Bitcoin Script não tem laços gerais de programação que se repitam arbitrariamente. Isso não permite ignorar tudo em um ramo não executado. Algumas instruções são verificadas já na leitura do script; seu tipo e a versão das regras importam. [1] [3]

CLTV, a instrução OP_CHECKLOCKTIMEVERIFY, pode impor um limite absoluto, como uma altura de bloco determinada, isto é, sua posição na cadeia. CSV, OP_CHECKSEQUENCEVERIFY, junto com as regras de idade, impõe uma espera relativa desde a confirmação da saída gasta. Uma saída é uma quantia recebida anteriormente com condições de gasto. Essas instruções verificam campos da transação; não iniciam um cronômetro, não enviam dinheiro nem substituem uma assinatura. Cada aplicação deve combinar a trava de tempo adequada com as demais condições. [7] [8] [9]

Antes de ler um exemplo técnico, identifique se ele usa scripts antigos, SegWit ou Tapscript. Tapscript acrescenta OP_CHECKSIGADD para combinar verificações de assinaturas. Já OP_CHECKMULTISIG falha quando executado; suas regras o ignoram em um ramo não executado. Os nomes não se contradizem: os ambientes de verificação diferem. Uma lista de opcodes não é um conjunto de peças que podem ser transferidas livremente entre formatos. [1] [3] [6]

BIP 342 reserva a família OP_SUCCESSx para extensões futuras do Tapscript. Após as verificações anteriores passarem, encontrar uma dessas instruções na decodificação pula com sucesso as verificações de script seguintes, mesmo em um ramo não executado. Um byte igual dentro de dados inseridos não conta. Isso abre espaço para mudar as regras; não é uma nova proteção já ativada. Uma condição baseada em um significado futuro indefinido pode não proteger os fundos como seu autor espera. [1] [3]

Um Full Node verifica regras de validade por conta própria, mas pode ser mais rigoroso ao aceitar e compartilhar transações não confirmadas. Bitcoin Core v29.0, por exemplo, rejeita por padrão a retransmissão de transações que usam uma instrução OP_SUCCESSx em Tapscript, embora o consenso possa permiti-las em um bloco. Ao ler um exemplo, identifique versão, dados iniciais, cobertura da assinatura e casos de falha. Sintaxe legível não comprova uma carteira segura; no uso comum, você confia esse trabalho a software revisado. [1] [5]