MuSig2 permet à plusieurs personnes de créer une seule signature Schnorr, qui atteste l’approbation d’un message précis sans révéler leurs clés privées. La procédure de BIP327 comporte deux tours de communication. Elle agrège les clés publiques et rassemble les contributions en une signature compatible avec BIP340. Le modèle de base est n-of-n : chaque signataire doit contribuer.
Imaginons une trésorerie dont Alice et Bob doivent tous deux approuver les paiements. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Un Multisig classique fondé sur un script peut révéler plusieurs clés et signatures dans la transaction. Avec MuSig2, chacun conserve sa clé privée et contribue à une signature commune. Le réseau vérifie un seul résultat. L’économie porte sur le stockage et la vérification dans la blockchain ; la coordination entre participants reste nécessaire. Jonas Nick, Tim Ruffing et Yannick Seurin ont présenté le protocole dans un article publié en octobre 2020. [3] [2] [10]
MuSig2 seul n’est pas une configuration 2-of-3 dans laquelle deux personnes quelconques peuvent remplacer un troisième signataire absent. Dans son modèle n-of-n, chaque membre du groupe doit contribuer. Un participant indisponible ou réticent peut bloquer la coopération. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Un portefeuille devant fonctionner malgré cela doit prévoir un autre chemin de dépense ou mécanisme de signature ; le nom MuSig2 ne le fournit pas automatiquement. [1] [8]
Avant la signature, les participants construisent une clé publique agrégée. La clé publique sert à vérifier les signatures et n’a pas besoin de rester secrète. Au premier tour, ils échangent des nonces publics, contributions à usage unique pour préparer la signature. Au second, ils produisent et transmettent des signatures partielles portant sur le même message et le même contexte, puis les réunissent. Sous les conditions du protocole, le premier tour peut être préparé avant de connaître le paiement. Mais avant de créer sa signature partielle, chacun doit vérifier la transaction concrète, notamment le destinataire, le montant et les frais. La préparation ne vaut pas accord sur un paiement inconnu : vérifier après avoir signé est trop tard. [1] [3]
Une addition naïve permettrait à un attaquant de choisir sa clé publique pour exploiter celles des autres. MuSig2 utilise donc des pondérations numériques, appelées coefficients, dérivées de la liste des clés. KeyAgg tient aussi compte de leur ordre ; une application peut utiliser KeySort pour établir un ordre commun. Tous doivent employer la même liste et les mêmes règles, faute de quoi ils ne calculent pas la même clé agrégée. [1] [5]
Nonce ne désigne pas ici un compteur de minage, mais un élément de signature à usage unique : pubnonce est partagé, tandis que secnonce reste chez le signataire. Un nonce secret ne doit jamais être réutilisé pour un autre appel à Sign. Deux signatures partielles ainsi produites peuvent révéler la clé privée. Changer le message ou répéter un paiement apparemment identique ne constitue pas une exception sûre. [1] [7]
Un calcul cryptographique correct ne suffit pas si l’application restaure un secnonce déjà utilisé après un redémarrage ou le confie à deux tâches simultanées. Libsecp256k1 invalide le nonce secret en l’écrasant pendant la signature, mais une copie hors de son contrôle peut contourner cette protection. La gestion de l’état doit empêcher la réutilisation lors des erreurs, restaurations et opérations concurrentes. La clé privée de signature peut servir plusieurs fois ; c’est le nonce qui est à usage unique. [7]
Un coordinateur peut recueillir les nonces publics et les signatures partielles pour faciliter l’échange. Si le protocole est correctement appliqué, cela ne lui permet pas de signer à la place d’un participant honnête, mais il peut faire échouer le processus. Chaque signataire doit vérifier ce qu’il signe. La vérification des signatures partielles peut aider au diagnostic, mais exige les contributions publiques originales et le bon contexte ; le seul nonce agrégé ne permet pas d’identifier le responsable. [1] [7]
Le résultat est une signature BIP340 de 64 octets. La key path de Taproot est un mode de dépense où le réseau vérifie une signature pour la clé inscrite dans la sortie, sans révéler de script de secours. Si le mode par défaut n’est pas utilisé, un octet indiquant le type sighash suit la signature. Il précise quelles parties de la transaction sont engagées par la signature : les modifier rendrait celle-ci invalide. La signature seule ne révèle ni le nombre de participants ni leurs clés individuelles. MuSig2 ne cache toutefois pas les montants, toutes les relations autour du paiement ou les échanges entre les parties. Il ne rassemble pas non plus automatiquement les signatures d’entrées différentes, lesquelles désignent les sorties reçues auparavant que la transaction dépense. [5] [6]
Outre la key path commune, Taproot peut inclure des conditions de script, par exemple une autre combinaison de clés ou un verrou temporel. Celui-ci rend un chemin accessible seulement après une durée ou une hauteur de bloc déterminée ; il ne remplace pas les signatures requises. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. La hauteur d’un bloc désigne sa position dans la chaîne. Les conditions doivent être engagées cryptographiquement dès la création de la sortie, un montant assorti de règles de dépense. Elles ne peuvent pas être ajoutées après la perte d’un signataire. La script path consiste à dépenser par ce script : elle révèle les conditions concernées et peut coûter davantage. La restauration demande donc les détails du dispositif choisi, pas seulement les clés secrètes individuelles. [6] [1] [9]
BIP327 décrit le protocole ; la bibliothèque et le portefeuille déterminent l’interface, les sauvegardes et les procédures réelles. Vérifiez la version, les vecteurs de test, la gestion des nonces et le contrôle de la transaction signée. La prise en charge de Schnorr ne signifie pas que chaque portefeuille prend entièrement en charge MuSig2. La signature commune utilise les règles existantes de BIP340 et de Taproot ; MuSig2 ne nécessite pas à lui seul de nouvel opcode de consensus. [4] [7] [2]
Pour une vision complète, lisez aussi Schnorr Signature, Taproot, Multisig, PSBT. Cette entrée est également citée par Schnorr Signature, Submarine Swap, FROST, PTLC.