Script de resgate

O BIP-16 permitiu que um remetente pagasse a um hash de 20 bytes em vez de a um contrato inteiro, e o script de resgate é o contrato que esse hash representa. Ele precisa caber em um único elemento da pilha, então 520 bytes é o teto absoluto. Perca esses bytes e suas chaves privadas não valem nada, o que faz do script de resgate parte do seu backup, e não do seu software.

Como funciona

Um script de resgate é invisível enquanto os bitcoins ficam parados. A saída que os guarda contém apenas um hash e um padrão que o consenso reconhece, aplicado em toda a rede desde 1º de abril de 2012, no bloco 173.805. Ninguém que paga a você fica sabendo nada sobre as condições, e um explorador de blocos também não.

A revelação acontece no gasto. O script de assinatura empilha os argumentos de que o contrato precisa e termina com o próprio contrato serializado. Um nó que valida pega esse último item, calcula seu hash, compara o resultado com o hash da saída e só então desserializa o item e o executa como código sobre o restante da pilha. As duas etapas precisam passar, e como o campo que o transporta não pode conter nada além de inserções de dados, o próprio script não consegue introduzir comportamento antes de ser verificado.

O script de resgate mais comum que existe não é um contrato. A partir de 2017, as carteiras que queriam a economia do SegWit sem deixar de receber pagamentos de software antigo envolveram um programa de testemunha em um hash de script, então o script de resgate tem 22 bytes: um byte de versão e um hash de chave de 20 bytes, sem nada a executar. Milhões de endereços de saque de corretoras que começam com 3 escondem exatamente isso e nada mais.

Onde você o encontra

O Bitcoin Core entrega um a você sempre que você cria um endereço de script, e seu comando decodescript converte o hexadecimal de volta em assembly legível. Em um descritor, o script é escrito explicitamente como sh(wpkh(...)) ou sh(multi(...)), que é a forma moderna de registrá-lo, porque as carteiras de descritores chegaram no Bitcoin Core 0.21.0 em janeiro de 2021 e tornaram obsoleto o velho hábito de importar endereços isolados.

O modo de perda é real e específico. Uma frase de recuperação regenera chaves. Ela não regenera um script arbitrário e não pode informar as chaves públicas dos outros coassinantes, então um arranjo 2-de-3 em que cada participante guardou apenas sua própria frase de recuperação é impossível de gastar. Pessoas já perderam bitcoins mesmo tendo um conjunto completo de chaves privadas e nenhum registro do script no qual aquelas chaves foram organizadas. Guarde o descritor junto com cada backup de frase de recuperação e restaure a partir dele uma vez, com um valor pequeno, antes que o endereço contenha algo que você sentiria falta.

A outra coisa a saber é o limite de tamanho. Quinze chaves públicas comprimidas, mais seus prefixos de inserção e os opcodes ao redor, somam 513 bytes, o que cabe por pouco; uma décima sexta não cabe. É esse teto, e não alguma regra sobre multiassinatura, que limita um endereço de script a quinze coassinantes.

Script de resgate vs script de testemunha

Um script de resgate e um script de testemunha ocupam o mesmo lugar conceitual em duas eras diferentes, e a diferença está em onde os bytes viajam e como são fixados. Um script de resgate é fixado com um hash de 160 bits e viaja no script de assinatura a quatro unidades de peso por byte. Um script de testemunha é fixado com um SHA-256 completo de 256 bits e viaja na testemunha a uma unidade de peso por byte, e por isso a mesma política custa cerca de um quarto para gastar. Um arranjo aninhado usa os dois ao mesmo tempo: o script de resgate é o programa de testemunha de 34 bytes e o script de testemunha é o contrato de fato. Se você estiver registrando um backup para uma multiassinatura SegWit envolvido, precisa dos dois por escrito, não de um só.