Bitcoin Script

Alice recebe 20 000 sat, vinte mil das menores unidades do bitcoin. A rede não abre uma conta em nome dela. Cria uma saída de transação: uma quantia e uma condição para a gastar mais tarde. Enquanto não for gasta, essa saída chama-se UTXO. Num pagamento habitual, a condição exige uma assinatura com a chave correspondente. Quando Alice paga mais tarde, a carteira seleciona essa saída, referencia-a numa nova entrada de transação e cria uma assinatura digital. Usa para isso a chave privada sem a enviar a ninguém; os outros verificam a assinatura com a chave pública. Conhecer o endereço de receção de Alice não basta. As condições da saída original estão no campo scriptPubKey, e Bitcoin Script determina como verificar o seu cumprimento. Um nó não é um funcionário que reconhece Alice: é um computador que verifica regras. Além da assinatura, tem de verificar, por exemplo, se a mesma saída já foi gasta. A transação só é válida quando cumpre todas as regras aplicáveis. [4] [2]

Nos pagamentos correntes, a carteira constrói as condições. Siga as suas instruções de cópia de segurança: uma recuperação normal a partir das palavras numa carteira compatível não exige automaticamente guardar cada script à mão. Numa configuração mais complexa, como Multisig, que exige várias assinaturas, as palavras de um só participante podem não descrever todo o mecanismo de gasto. No uso habitual, convém recorrer a uma carteira com procedimentos comprovados, em vez de construir scripts manualmente em notação hexadecimal. Os descritores de saída descrevem o tipo de script, as chaves e a sua derivação, ajudando a determinar o que uma carteira restaurada deve procurar. A chave privada, por si só, pode não bastar para recuperar uma configuração mais complexa. É preciso guardar também os scripts necessários e os dados de origem das chaves, ou seja, de onde e como foram derivadas, e verificar as vias de gasto previstas. [11]

Os capítulos seguintes mostram como as condições são codificadas dentro da transação; não precisa de conhecer estes detalhes para pagar no dia a dia. O campo scriptSig e a parte chamada witness fornecem dados de verificação. Um hash é uma impressão digital dos dados; um bloqueio temporal impede o gasto antes de um limite definido. Pode imaginar a pilha como elementos empilhados que se manipulam a partir do topo. Script processa dados através de uma pilha: coloca valores nela e as instruções, chamadas opcodes, retiram-nos, comparam-nos ou processam-nos de outras formas. As instruções de assinatura verificam assinaturas; nem as chaves privadas nem a criação de assinaturas fazem parte dessa verificação. A linguagem permite combinar assinaturas, condições baseadas em hashes e bloqueios temporais. Não tem ciclos de uso geral e não é Turing-completa: não permite expressar todos os cálculos possíveis numa linguagem de programação universal. O nó tem de aplicar as regras exatas do tipo de saída e da versão do script em causa. [1] [3]

Em P2PKH (Pay to Public Key Hash), a saída tem habitualmente a forma OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. A entrada fornece uma assinatura e uma chave pública no seu scriptSig. A verificação confirma que o hash da chave pública corresponde ao valor na saída e verifica depois a assinatura. Conhecer o endereço ou a chave pública não basta, por isso, para efetuar esse gasto. A chave privada é usada pela carteira que assina, não pelo nó que verifica a transação. [1]

P2SH, definido em BIP16, guarda na saída o hash de um script. A entrada que a gasta fornece o redeemScript correspondente, ou seja, o script revelado no momento do gasto, juntamente com os dados necessários. O seu scriptSig só pode conter instruções que coloquem dados na pilha. O nó verifica primeiro a correspondência do hash e avalia depois o redeemScript com os restantes elementos da pilha. Um hash correto não basta por si só: as condições desse script também têm de ser satisfeitas. [5]

Em SegWit versão 0, os dados de verificação passam para a parte da transação chamada witness. Esta é uma lista de elementos de dados, não um script em si mesma. P2WPKH usa uma assinatura e uma chave pública; P2WSH inclui também um witnessScript cujo hash SHA256 tem de corresponder à saída. Em SegWit nativo, scriptSig está vazio. Quando é encapsulado em P2SH, contém apenas a instrução que coloca na pilha o programa witness correspondente; os dados de verificação continuam em witness. [6]

A verificação de uma assinatura trabalha com uma mensagem derivada da transação segundo um procedimento definido. O modo SIGHASH determina quais as partes protegidas contra alterações por essa assinatura. Não se pode, por isso, afirmar que todas as assinaturas abrangem sempre a transação inteira. Nas operações de assinatura de SegWit versão 0, BIP143 inclui sempre o montante da saída que está a ser gasta. A carteira tem de conhecer os dados corretos e o modo escolhido; durante a verificação, Script não avalia a intenção humana de quem assina. [7]

Taproot, definido em BIP341, permite gastar uma saída P2TR (Pay to Taproot) de duas formas. A via da chave verifica uma assinatura Schnorr com a chave pública da saída, sem revelar um script. A via do script revela, em contrapartida, o script escolhido e um bloco de controlo, chamado control block, que comprova a sua ligação à saída. Os restantes scripts da árvore não precisam de ser revelados. As regras do script revelado dependem também da versão da folha correspondente. [8]

BIP342 define Tapscript para folhas de Taproot da versão 0xc0. As instruções de assinatura usam aqui assinaturas Schnorr, e OP_CHECKSIGADD permite construir uma condição que exija várias assinaturas. A antiga instrução OP_CHECKMULTISIG está desativada: se for executada, a validação falha. Não são herdados o antigo limite de 10 000 bytes por script nem o limite de 201 opcodes contados segundo as regras anteriores. As operações de assinatura são limitadas por um orçamento calculado a partir do tamanho de witness; continuam a existir limites para a pilha. Os limites de uma versão não devem, por isso, ser apresentados como propriedades gerais de todo o Script. [9]

As regras de consenso determinam se um gasto é válido num bloco. O caráter padrão, ou standardness, designa regras locais adicionais de um nó para aceitar transações não confirmadas no seu Mempool e retransmiti-las; não é um processo de normalização. Uma transação válida segundo o consenso pode, portanto, não ser retransmitida habitualmente. OP_SUCCESSx requer atenção especial em Tapscript: depois de passarem as verificações anteriores, o seu reconhecimento durante a descodificação faz a verificação do script terminar com sucesso, antes da execução normal e das verificações da pilha. É um mecanismo reservado para futuras extensões, não uma condição de gasto segura para o uso corrente. [10] [9]