Glossaire / Protocole et mises à jour
MuSig2
Aussi appelé Agrégation de clés.
- Qu'est-ce que MuSig2 ?
- MuSig2 permet à plusieurs signataires de combiner leurs clés publiques en une seule et de produire une signature Schnorr unique de 64 octets, de sorte qu'une dépense de groupe paraît identique on-chain à une dépense en solo.
Spécifié dans BIP-327.
L'agrégation de clés est toute l'astuce : plusieurs participants détiennent chacun une clé privée, et les mathématiques additionnent leurs clés publiques en une clé agrégée que nul d'entre eux ne contrôle seul. Le BIP-327 a fixé le schéma à deux tours de communication, contre trois dans le MuSig d'origine. Pour un portefeuille partagé, cela signifie des frais plus faibles et aucune preuve publique que le portefeuille était partagé.
Comment cela fonctionne
MuSig2 se déroule en deux passages sur le groupe, et seul le second passage doit savoir ce qui est signé.
Au premier passage, chaque signataire génère deux nonces secrets et publie la paire de points correspondante. Le coordinateur additionne ces paires en un nonce combiné à l'aide d'un coefficient dérivé en hachant l'ensemble du jeu. Ce coefficient est l'élément d'ingénierie précis qui a permis au schéma d'économiser un tour sans rouvrir les attaques qui avaient cassé les conceptions antérieures à deux tours.
Au second passage, chaque signataire produit une signature partielle sur le hachage de signature de la transaction et renvoie un nombre unique. Additionnés, ces nombres forment une signature de 64 octets qui se vérifie contre la clé agrégée de 32 octets selon les règles ordinaires du BIP-340. Un nœud qui valide le bloc ne peut pas savoir combien de personnes étaient impliquées, ni même que quiconque l'était.
Deux propriétés de sécurité méritent d'être nommées explicitement. L'agrégation de clés applique un coefficient par clé afin qu'un participant ne puisse pas fabriquer une clé publique qui annule celle des autres, l'attaque dite de la clé malveillante que permet la simple addition des clés. Et les nonces sont strictement à usage unique : signer deux messages différents avec le même nonce révèle votre clé privée purement et simplement, c'est pourquoi les implémentations correctes effacent le nonce secret dès qu'il est consommé et refusent une seconde signature dans la même session.
Où le rencontre-t-on
MuSig2 se situe derrière une dépense par le chemin de clé Taproot, si bien que ce que vous voyez réellement est une adresse bc1p qui se comporte comme n'importe quelle autre.
L'argument de taille est concret. Une entrée Taproot par chemin de clé coûte 57,5 vbytes qu'une seule personne l'ait signée ou cinq, tandis qu'une dépense par script témoin deux sur trois doit révéler trois clés publiques et deux signatures et dépasse largement le double. Les sorties Taproot sont devenues dépensables au bloc 709 632 le 14 novembre 2021, la capacité est donc présente sur la chaîne depuis des années et le goulot d'étranglement a été le logiciel de portefeuille.
Le BIP-373 fournit la tuyauterie, en ajoutant des champs PSBT pour les nonces publics, les clés des participants et les signatures partielles, afin qu'un appareil matériel puisse participer à une session de signature sans que chaque fabricant invente un format de message. L'adoption dans les portefeuilles grand public reste limitée. Le déploiement le plus concret est le travail sur les canaux taproot simples dans Lightning, où les deux pairs financent le canal dans une seule sortie MuSig2.
MuSig2 vs multisig
MuSig2 est en tout-ou-rien par construction ; le multisig classique peut avoir le seuil que vous voulez.
Cette différence décide si cela a sa place près de votre épargne. Un deux sur trois basé sur un script continue de fonctionner quand une clé est perdue, car le script nomme trois clés et en demande deux. Une clé agrégée exige la présence de chaque participant, et un signataire qui disparaît emporte les bitcoins avec lui, à moins que la même adresse n'engage aussi un chemin de script contenant une branche de récupération. De véritables seuils sous une clé agrégée nécessitent un autre protocole, comme FROST, que le BIP-327 ne spécifie pas.
Le second compromis est délibéré. Le multisig par script est auditable par quiconque dispose d'un explorateur de blocs, et MuSig2 ne l'est pas, ce qui est un gain de confidentialité pour un foyer et un obstacle pour un trésorier qui doit démontrer qu'un paiement exigeait deux responsables.