Assinatura múltipla

Curiosidade

1. Por que um script que requer duas assinaturas retira três itens da pilha?
2. Como uma string de bytes vazia pode ser uma regra de consenso e não apenas uma convenção?
3. O que muda quando dez chaves se agregam em uma assinatura que parece indistinguível da de um único signatário?

Explorar

1. Os scripts de assinatura múltipla exigem que pelo menos m assinaturas sejam válidas em relação a n chaves públicas listadas. O script de bloqueio lista m, as n chaves públicas e n; OP_CHECKMULTISIG verifica n, as n chaves, m e, em seguida, as m assinaturas, que devem corresponder às chaves na ordem listada. Se forem fornecidas menos do que m assinaturas válidas, a despesa é inválida.
2. Um erro de codificação na implementação original faz com que o OP_CHECKMULTISIG retire um item extra da pilha além das assinaturas necessárias. Esse elemento “falso” é ignorado durante a verificação criptográfica, mas precisa estar presente; se ausente, a pilha fica sem espaço suficiente e a transação falha. Os usuários iniciais utilizavam o OP_0 como esse preenchimento, uma convenção que persistiu por anos porque os nós aceitavam qualquer valor nessa posição.
3. O BIP147 (NULLDUMMY), ativado com o SegWit em agosto de 2017, transformou esse vetor de maleabilidade em uma regra de consenso. O elemento fictício agora deve ser um array de bytes vazio. Qualquer valor diferente de vazio, mesmo um único byte zero, faz com que o script falhe. Isso eliminou a possibilidade de alterar os IDs das transações trocando o conteúdo do elemento fictício, estabilizando o hash da transação para todas as confirmações subsequentes.
4. As regras de padronização determinam quais scripts multisig os nós transmitem. Por padrão, no Bitcoin Core, as saídas de assinatura múltipla são limitadas a três chaves. Quando envolvidos em P2SH, os multisig podem utilizar até 15 chaves (limitado pelo script de resgate de 520 bytes); em P2WSH, até 20. Essa distinção permite que estruturas corporativas complexas funcionem sem sobrecarregar a camada básica de transações.
5. Duas ferramentas mais recentes substituem os padrões multisig antigos. MuSig2 (BIP327, 2023), um protocolo separado desenvolvido com base nas assinaturas Schnorr do Taproot, agrega várias chaves públicas em uma única chave e gera uma assinatura Schnorr padrão; na cadeia, o gasto é indistinguível de um gasto comum com uma única chave no Taproot. O Tapscript, que faz parte do próprio Taproot, adiciona o OP_CHECKSIGADD, o que permite a verificação incremental de assinaturas sem o bug de retirada da pilha ou o limite de 20 chaves dos opcodes legados.
6. Para inspecionar essas mecânicas, abra um explorador de blocos e localize uma transação multisig simples pré-SegWit. Observe o scriptSig: ele começa com OP_0, seguido por assinaturas. Compare-o com um gasto multisig P2WSH, no qual o “witness” contém um item vazio, as assinaturas e o script do “witness” que lista as chaves. Note como as contagens de bytes diferem, refletindo o custo de incorporar a lista completa de chaves na saída em comparação com a entrada.

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
• BIP147: Dealing with dummy stack element malleability
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• BIP342: Validation of Taproot Scripts