MuSig2 permite que várias pessoas criem juntas uma assinatura Schnorr, que demonstra a aprovação de uma mensagem específica sem revelar suas chaves privadas. O procedimento de BIP327 usa duas rodadas de comunicação. Reúne as chaves públicas em uma chave agregada e as contribuições em uma assinatura compatível com BIP340. O modelo básico é n-of-n: todos os signatários devem contribuir.
Imagine uma tesouraria em que Alice e Bob precisam aprovar cada pagamento. Uma assinatura digital comprova a autorização de um pagamento por meio de uma chave privada, um valor numérico secreto, sem revelar essa chave. Um Multisig tradicional baseado em script pode revelar várias chaves e assinaturas na transação. Com MuSig2, cada pessoa mantém sua chave privada e contribui para uma assinatura conjunta. A rede verifica um único resultado. A economia está no armazenamento e na verificação na blockchain; a coordenação entre participantes continua necessária. Jonas Nick, Tim Ruffing e Yannick Seurin apresentaram o protocolo num artigo publicado em outubro de 2020. [3] [2] [10]
MuSig2, sozinho, não é uma configuração 2-of-3 em que qualquer dupla pode substituir o terceiro signatário ausente. No modelo n-of-n, cada integrante do grupo precisa contribuir. Um participante indisponível ou que se recuse pode interromper a colaboração. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Se a carteira precisa funcionar também nessa situação, deve prever outra forma de gasto ou mecanismo de assinatura; o nome MuSig2 não oferece isso automaticamente. [1] [8]
Antes de assinar, os participantes constroem uma chave pública agregada. A chave pública serve para verificar assinaturas e não precisa ficar secreta. Na primeira rodada, trocam nonces públicos, contribuições de uso único para preparar a assinatura. Na segunda, criam e enviam assinaturas parciais para a mesma mensagem e o mesmo contexto, reunindo-as no resultado final. Conforme as condições do protocolo, a primeira rodada pode ser preparada antes de conhecer o pagamento. Mas, antes de criar sua assinatura parcial, cada participante deve conferir a transação concreta, sobretudo destinatário, valor e taxa. Preparar não significa aprovar um pagamento desconhecido; conferir depois de assinar é tarde demais. [1] [3]
Uma soma ingênua permitiria que um atacante escolhesse sua chave pública para explorar as chaves dos demais. MuSig2 usa pesos numéricos, chamados coeficientes, derivados da lista de chaves. KeyAgg também considera a ordem; a aplicação pode usar KeySort para padronizá-la. Todos precisam adotar a mesma lista e as mesmas regras, ou não calcularão a mesma chave agregada. [1] [5]
Aqui, nonce não é um contador de mineração. É material de assinatura de uso único: pubnonce é compartilhado, enquanto secnonce fica com o signatário. Um nonce secreto nunca deve ser reutilizado em outra chamada a Sign. Duas assinaturas parciais produzidas com essa reutilização podem revelar a chave privada. Mudar a mensagem ou repetir um pagamento aparentemente idêntico não é uma exceção segura. [1] [7]
Um cálculo criptográfico correto não basta se, após reiniciar, a aplicação restaura um secnonce usado de um backup ou o entrega a duas tarefas simultâneas. Libsecp256k1 invalida o nonce secreto sobrescrevendo-o durante a assinatura, mas uma cópia fora de seu controle pode contornar a proteção. A gestão do estado deve evitar reutilização em erros, recuperação e execução concorrente. A chave privada de assinatura pode ser usada repetidamente; o nonce é o componente de uso único. [7]
Um coordenador pode coletar nonces públicos e assinaturas parciais para facilitar a troca. Com o protocolo usado corretamente, isso não permite assinar no lugar de um participante honesto, embora possa impedir a conclusão. Cada signatário precisa conferir o que está assinando. A verificação de assinaturas parciais ajuda no diagnóstico, mas exige as contribuições públicas originais e o contexto correto; o nonce agregado, sozinho, não identifica o responsável. [1] [7]
O resultado é uma assinatura BIP340 de 64 bytes. A key path do Taproot é uma forma de gasto em que a rede verifica uma assinatura para a chave registrada na saída, sem revelar um script alternativo. Se o modo padrão não for usado, um byte de tipo sighash aparece depois da assinatura. Ele define quais partes da transação estão vinculadas à assinatura: alterá-las a tornaria inválida. A assinatura sozinha não revela o número de participantes nem suas chaves individuais. MuSig2 não esconde, porém, os valores, todas as relações do pagamento ou a comunicação entre as partes. Também não reúne automaticamente assinaturas de entradas diferentes, que apontam para saídas recebidas anteriormente e gastas nessa transação. [5] [6]
Além da key path conjunta, Taproot pode incluir condições de script, como outra combinação de chaves ou um bloqueio temporal. Esse bloqueio disponibiliza um caminho apenas após determinado tempo ou altura de bloco; não substitui as assinaturas necessárias. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. A altura de um bloco indica sua posição na cadeia. As condições devem ser fixadas criptograficamente quando a saída, um valor com regras de gasto, é criada. Não podem ser acrescentadas depois da perda de um signatário. A script path é o gasto por esse script: revela as condições correspondentes e pode custar mais. A recuperação exige, portanto, detalhes do esquema escolhido, não apenas as chaves secretas individuais. [6] [1] [9]
BIP327 descreve o protocolo; a biblioteca e a carteira definem a interface, os backups e os procedimentos reais. Confira versão, vetores de teste, tratamento de nonces e revisão da transação assinada. Suportar assinaturas Schnorr não significa oferecer suporte completo a MuSig2 em toda carteira. A assinatura conjunta usa as regras existentes de BIP340 e Taproot; MuSig2, por si só, não exige um novo opcode de consenso. [4] [7] [2]
Para ter uma visão mais completa, leia este verbete junto com Schnorr Signature, Taproot, Multisig, PSBT. Também há referências a este verbete em Schnorr Signature, Submarine Swap, FROST, PTLC.