Scripts padrão: P2PKH e P2SH

Curiosidade

1. Por que o Bitcoin bloqueia as moedas em um hash em vez da própria chave?
2. Como um script de quatro linhas verifica tanto a propriedade quanto a autorização em uma única execução?
3. O que fez do P2PKH o formato de endereço padrão por mais de oito anos na história da rede?

Explorar

Parte IPay-to-public-key-hash (P2PKH)

1. O bloco de gênese continha apenas saídas do tipo Pay-to-Public-Key (P2PK). Esses scripts colocavam a chave pública completa (em 2009, uma chave descompactada de 65 bytes) diretamente na saída, visível antes de qualquer gasto, o que fazia com que as saídas ficassem grandes. O P2PKH, também presente no software original de 2009 e usado para pagamentos em endereços comuns, armazena um hash de 20 bytes em vez disso, escondendo a chave até que as moedas sejam gastas.
2. O script de bloqueio é `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG`. A execução começa com os dados do gastador na pilha: a assinatura, e em seguida a chave pública no topo. O mecanismo duplica a chave, calcula seu hash usando RIPEMD-160(SHA256(chave)) e compara o resultado com o hash armazenado. Se eles corresponderem, `OP_EQUALVERIFY` é aprovado; caso contrário, a execução é interrompida imediatamente.
3. Uma vez que a verificação do hash é bem-sucedida, `OP_CHECKSIG` verifica a assinatura ECDSA em relação à chave pública revelada e aos dados da transação. Esse mecanismo duplo garante que apenas o detentor da chave privada correspondente possa desbloquear os fundos. O script de saída tem um tamanho total de 25 bytes, uma estrutura compacta que se tornou a base para endereços legados que começam com ‘1’.
4. O P2PKH foi o tipo de saída mais comum para pagamentos ordinários durante a maior parte da história do Bitcoin, e manteve-se assim por anos após a ativação do SegWit em agosto de 2017, no bloco 481.824, pois a adoção do SegWit nativo foi gradual. Seu sucesso se devia à simplicidade e compatibilidade; não exigia atualizações no consenso além das regras originais do protocolo. Cada nó podia validar esses scripts de forma independente, sem necessidade de rastreamento complexo de estados, o que o tornou o tipo de saída mais robusto para transferências de uso geral durante o crescimento inicial do Bitcoin.
5. O formato do endereço utiliza a codificação Base58Check, que inclui um checksum de quatro bytes para detectar erros de digitação. Um único caractere digitado incorretamente quase certamente fará com que o checksum falhe, fazendo com que a carteira recuse o endereço. Essa redundância tornou o P2PKH amigável ao usuário, apesar de sua complexidade técnica bruta, preenchendo a lacuna entre segurança criptográfica e usabilidade humana.
6. Abra um explorador de blocos e localize qualquer transação com uma entrada que faça referência a um endereço '1'. Examine o campo `scriptSig`: ele contém a assinatura seguida pela string hexadecimática da chave pública. Compare essa chave pública com o hash de 20 bytes em `scriptPubKey` da saída referenciada. Executando SHA-256 e, em seguida, RIPEMD-160 nessa chave, será possível reproduzir o hash armazenado, confirmando a ligação.

Parte IIPay-to-script-hash (P2SH)

7. Antes de 2012, usar um script complexo como uma multisignatura de cinco elementos exigia que todo o código de bloqueio fosse inserido diretamente no output. Isso fazia com que o output ficasse grande, e o remetente tinha que pagar a taxa correspondente. Além disso, isso expunha as chaves públicas de todos os participantes e os requisitos específicos de assinatura para qualquer pessoa que observasse a cadeia. O remetente precisava conhecer a estrutura exata do destino antes de enviar, o que criava dificuldades para tesouros corporativos ou exchanges que necessitavam de configurações de segurança flexíveis.
8. Gavin Andresen propôs o BIP16 no início de 2012 para resolver isso. Ele permitia que uma saída contivesse apenas o digest HASH160 de um script, em vez do próprio script. O script de saída passou a ter 23 bytes, ligeiramente menor do que os 25 do P2PKH. O remetente não precisava mais conhecer as condições de gasto; ele simplesmente pagava para um hash. A complexidade foi transferida inteiramente para a pessoa que gastava as moedas.
9. A ativação do BIP16 em abril de 2012 foi controversa. Luke Dashjr propôs uma alternativa, o BIP17, que utilizava um opcode e um esquema de codificação diferentes. O debate sobre qual proposta adotar intensificou-se significativamente dentro da comunidade de desenvolvedores. O BIP16 foi ativado em abril de 2012 após os mineradores demonstrarem apoio, e tornou-se o método padrão para encapsular scripts complexos.
10. Gastar uma saída pay-to-script-hash é um processo em duas etapas. Primeiro, o gastador empilha seu script de resgate completo na pilha. O nó verifica se o HASH160 desse script corresponde ao hash presente na saída. Se não houver correspondência, a execução falha imediatamente. Se houver correspondência, o nó então executa o script de resgate revelado com os dados restantes na pilha para verificar as condições reais de gasto.
11. O design possui uma aresta afiada: ninguém pode verificar o script de resgate antes do pagamento, pois apenas seu hash está on-chain. Se o software do destinatário criar um script defeituoso, ou se o script for perdido, as moedas pagas para esse endereço podem ficar impossíveis de gastar para sempre.
12. Quando o SegWit foi ativado em agosto de 2017, o P2SH funcionou como uma ponte de compatibilidade. Os usuários podiam envolver novos scripts witness dentro de um envelope P2SH, criando endereços “aninhados” que ainda começavam com “3”. Carteiras antigas que não conseguiam lidar com os endereços bech32 mais recentes ainda podiam enviar dinheiro para usuários do SegWit, enquanto os destinatários que utilizavam o SegWit recebiam desconto nas taxas ao fazer transações. Atualmente, embora o SegWit nativo seja preferido por sua eficiência, o P2SH continua sendo um mecanismo essencial para contratos complexos e para manter a compatibilidade com sistemas antigos.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• Bitcoin Developer Guide, 'Transactions' documentation (bitcoin.org)
• Satoshi Nakamoto, original Bitcoin client source code (2009-2010 commits)
• Gavin Andresen, BIP16: Pay to Script Hash (2012)
• Luke Dashjr, BIP17: OP_CHECKHASHVERIFY (CHV) (2012)
• Bitcoin Developer Guide: Transactions and Scripts