OP_CHECKMULTISIG

O byte 0xae é o que tornou possível a custódia compartilhada: ele retira da pilha uma contagem de chaves, essa mesma quantidade de chaves públicas, uma contagem de assinaturas exigidas, essa mesma quantidade de assinaturas e, por fim, um item a mais. O consenso permite até 20 chaves em uma única chamada. É a razão pela qual uma empresa pode exigir que três de cinco diretores aprovem um saque sem que nenhum deles possa agir sozinho.

Como funciona

A verificação é uma única passagem por duas listas, não uma busca. O opcode percorre as assinaturas em ordem e testa cada uma em relação às chaves públicas sucessivas, de modo que as assinaturas precisam aparecer na mesma ordem relativa das chaves a que pertencem. Apresente um 2 de 3 válido com as duas assinaturas trocadas de lugar e o script falha, o que é uma causa rotineira de confusão quando as pessoas montam gastos de multiassinatura manualmente.

A pilha fica com um item a menos, e sempre foi assim. A implementação original retirava da pilha um elemento extra que nunca usava, um bug que não podia ser removido sem quebrar todos os bitcoins existentes. Os signatários aprenderam a empilhar primeiro um item descartável, e o BIP-147 fechou a maleabilidade resultante ao exigir que esse item fosse vazio, a partir do bloco 481.824.

A contabilidade de custo é onde isso pesa. Uma chamada simples é cobrada como 20 operações de assinatura, independentemente de quantas chaves ela realmente contém, a menos que um opcode de número pequeno a preceda imediatamente, caso em que a cobrança é esse número. Um bloco é limitado a 80.000 unidades de custo de operações de assinatura, e a política de retransmissão permite no máximo 15 delas em uma única entrada pay-to-script-hash. Esse número da política, e não o limite de 20 do próprio opcode, é a razão pela qual os endereços de script chegam no máximo a quinze cofirmantes.

O Tapscript o aposentou de vez. O BIP-342 fez o opcode e sua variante de verificação falharem assim que aparecem dentro de uma folha Taproot, porque verificar um lote de assinaturas Schnorr em relação a uma lista em uma única operação anula a verificação em lote que faz Schnorr valer a pena.

Onde você o encontra

A saída 2 de 2 que financia cada canal Lightning usa OP_CHECKMULTISIG, o que por si só coloca o opcode em uma grande parte dos gastos com script da rede. Tesourarias corporativas, arranjos de depósito em garantia em mercados ponto a ponto mais antigos e o armazenamento a frio de corretoras construído antes do Taproot também o usam, normalmente como um 2 de 3 dentro de um hash de script.

As chamadas simples, em que as chaves ficam diretamente na saída sem nenhum hash na frente delas, são padrão de retransmissão para até três chaves e quase nunca são usadas, porque o remetente paga por cada chave e todo o arranjo é público antes de um único bitcoin se mover. Em 2014 esse formato se tornou brevemente uma forma de armazenar arquivos on-chain, e é em parte por isso que os debates sobre armazenamento de dados ainda ressurgem sempre que alguém mexe na política de retransmissão.

Se você está configurando uma custódia compartilhada agora, sua carteira provavelmente produzirá um arranjo Taproot usando a alternativa contada, ou um script P2WSH se a compatibilidade importar mais do que as taxas.

OP_CHECKMULTISIG vs multiassinatura P2SH

OP_CHECKMULTISIG é uma instrução e a multiassinatura P2SH é uma forma de empacotá-la. O opcode diz como um quórum é verificado; o empacotamento diz que o quórum fica escondido atrás de um hash e é revelado no momento do gasto. A mesma instrução pode aparecer em uma saída simples com as chaves à vista, em um script de resgate atrás de um endereço que começa com 3, ou em um script de testemunha atrás de um endereço bc1q, e os três casos diferem enormemente em custo e privacidade embora executem lógica de verificação idêntica. O que você não pode fazer é usar a instrução em uma folha Taproot, e é por isso que os quóruns modernos são construídos com um opcode completamente diferente.