Script de assinatura

Toda entrada de uma transação aponta para uma saída anterior e precisa provar que tem permissão para gastá-la. O Bitcoin Core chama esse campo de scriptSig; em uma entrada legada pay-to-public-key-hash ele carrega uma assinatura de 71 ou 72 bytes e uma chave pública de 33 bytes, aproximadamente 107 bytes. Desde o SegWit essa prova geralmente fica em outro lugar, e é nisso que está a maior parte do motivo pelo qual um saque para um endereço bech32 custa menos.

Como funciona

O script de assinatura é executado primeiro e deixa seus resultados na pilha para o script da saída consumir. Os dois não são executados como um único programa unido: são executados em sequência, com a pilha passando de um para o outro, uma separação introduzida em 2010 depois que o desenho original se mostrou explorável.

A política de retransmissão exige que esse campo não contenha nada além de inserções de dados. Nenhum condicional, nenhuma aritmética, nenhum opcode que faça algum trabalho. A restrição existe porque quem gasta controla esses bytes por completo, e deixar um atacante executar lógica na entrada reabre problemas que a rede fechou há muito tempo. O pay-to-script-hash transforma a regra em um requisito de consenso e não em uma preferência, já que o script de resgate precisa chegar como a última inserção simples.

Seu tamanho depende inteiramente do que ele desbloqueia. Uma entrada legada de chave única carrega uma assinatura e uma chave. Uma entrada SegWit aninhada carrega exatamente 23 bytes, uma única inserção do programa de testemunha de 22 bytes, e empurra todo o resto para a testemunha. Uma entrada bech32 ou bech32m nativa não carrega nada: o campo serializado é um único byte de comprimento zero.

Há uma entrada cujo script de assinatura não é prova de nada. A única entrada de uma transação coinbase não tem saída anterior para desbloquear, então o campo é reaproveitado como espaço livre entre 2 e 100 bytes, e desde o BIP-34 ele precisa começar pela altura do bloco. Mineradores assinam mensagens, votos e piadas ali desde 2009.

Onde você o vê

Decodifique qualquer transação e cada entrada mostra um objeto scriptSig com uma visão em assembly e uma visão em hexadecimal. Em uma entrada SegWit nativa ou Taproot, ambas são strings vazias, enquanto um campo de testemunha separado guarda os dados, e essa assimetria visual é a maneira mais rápida de saber de relance qual formato de endereço uma transação antiga usou.

Ele também explica um episódio histórico amplamente mal interpretado. Como o scriptSig fazia parte do ID da transação, um terceiro podia recodificar uma assinatura sem invalidá-la e mudar o ID de uma transação já transmitida. A Mt. Gox suspendeu os saques em fevereiro de 2014 e culpou exatamente esse comportamento, embora uma análise acadêmica posterior da blockchain tenha constatado que o volume de transações com maleabilidade era pequeno demais para explicar os bitcoins desaparecidos. O SegWit encerrou a discussão em agosto de 2017 ao tirar os dados de desbloqueio do cálculo do ID por completo.

Script de assinatura vs dados de testemunha

Um script de assinatura e os dados de testemunha carregam o mesmo tipo de prova, e o SegWit transferiu a tarefa de um para o outro sem mudar o que uma assinatura significa. As diferenças que importam para você são preço e permanência. Os bytes da testemunha são cobrados a uma unidade de peso cada um, enquanto os bytes do script de assinatura custam quatro, então o mesmo gasto de chave única ocupa aproximadamente 148 bytes virtuais quando a prova viaja no scriptSig e aproximadamente 68 quando viaja na testemunha. Os dados de testemunha também ficam fora do ID da transação, então o identificador de um gasto não pode ser alterado em trânsito. Uma entrada legada ainda usa o campo antigo, e é por isso que bitcoins parados em um endereço que começa com 1 custam mais para serem movidos, silenciosamente, a cada vez que você os move.