Schnorr Signature

Alice veut envoyer des bitcoins à Bob. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Son portefeuille construit la transaction et signe avec sa clé privée les données imposées par le mode de signature choisi. Un nœud vérifie ensuite la signature et toutes les autres conditions de dépense. Un nœud est un logiciel qui vérifie les transactions et les blocs et communique avec les autres participants du réseau. Une signature valide ne prouve pas à elle seule l’identité civile d’Alice, le choix du bon destinataire ou l’existence de fonds non dépensés suffisants : ce sont des questions distinctes. Un paiement signé peut encore être une erreur involontaire. [5] [3] [10] [11]

BIP340, de Pieter Wuille, Jonas Nick et Tim Ruffing, définit précisément la signature Schnorr de Bitcoin. BIP341 l’intègre aux règles de dépense de Taproot, activées sur le réseau principal de Bitcoin (Mainnet) au bloc 709632 en 2021. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Il s’agit de deux niveaux : l’algorithme de signature et les conditions de dépense. Les anciennes sorties et SegWit v0 utilisent toujours ECDSA, l’algorithme de signature antérieur ; la mise à jour n’a pas remplacé leurs signatures rétroactivement. [1] [2] [11]

L’octet est une unité courante de mesure des données. La variante Bitcoin utilise la courbe elliptique secp256k1, une structure mathématique servant aux calculs sur les clés et les signatures. BIP340 impose un format de signature fixe de 64 octets. La clé publique est représentée par les 32 octets de la coordonnée x ; x-only ne signifie pas qu’un contrôle de sécurité est omis. Les règles déterminent aussi sans ambiguïté quelle version du point de la courbe doit être utilisée pour la vérification. Un format réduit et précisément défini facilite le travail du logiciel, mais ces deux nombres ne donnent pas à eux seuls la taille d’une transaction entière. [1] [12]

Le portefeuille ne signe pas un vague « je suis d’accord ». Le mode sighash détermine quelles données de transaction forment le message signé. SIGHASH_DEFAULT protège des informations sur toutes les entrées et sorties, comme SIGHASH_ALL : quels fonds précédemment reçus sont dépensés et quels nouveaux montants assortis de conditions de dépense sont créés. Modifier une donnée couverte invalide la signature. Cela ne signifie pas signer chaque octet, par exemple les autres signatures. Les autres modes autorisés ont une portée différente. La signature occupe 64 octets ; un mode autre que celui par défaut ajoute un octet de type, portant cet élément à 65 octets. Ce n’est toujours pas la taille de l’entrée ou de la transaction entière. [2]

La signature fait intervenir une valeur secrète appelée nonce. Sa réutilisation pour des messages différents avec la même clé peut révéler la clé privée. BIP340 décrit donc précisément sa dérivation et recommande des données aléatoires auxiliaires pour mieux protéger l’implémentation. L’utilisateur ne choisit pas son nonce et ne l’inscrit pas dans sa sauvegarde. Une bibliothèque de signature éprouvée le gère ; improviser ici peut compromettre une cryptographie par ailleurs correcte. [1] [9]

La structure mathématique des signatures Schnorr permet des protocoles où plusieurs personnes s’accordent sur un message et produisent une signature commune. MuSig2, défini dans BIP327, en est un exemple. Dans la forme de base de ce protocole, chaque membre du groupe choisi doit contribuer. Il exige une coordination, un traitement correct des clés et sa propre procédure sûre pour les nonce. Additionner n’importe quelles signatures déjà produites ne suffit pas. La prise en charge de Schnorr Signature ne signifie donc pas, à elle seule, qu’un portefeuille permet cette collaboration. [8]

Taproot offre plusieurs voies de dépense. Avec la key path, le réseau vérifie une signature par rapport à la clé publique inscrite dans la sortie. Cette clé peut représenter une personne ou un groupe qui coopère. Avec la script path, le script choisi est révélé : un programme contenant les conditions que le paiement doit satisfaire. Tapscript est la version de ce langage utilisée par Taproot. Son instruction OP_CHECKSIGADD vérifie une signature et, en cas de succès, ajoute un à un compteur. La répéter permet d’évaluer plusieurs signatures distinctes et de vérifier le nombre requis. Ce Multisig par script diffère d’une signature agrégée. Pour chaque portefeuille, vérifiez qui doit coopérer, ce qui devient public et quelle récupération reste possible si une clé est perdue. [7] [2]

Dans un réseau sans arbitre central, un nœud ne doit pas accepter une signature qu’un autre rejette parce qu’il interprète différemment ses octets. BIP340 définit donc en détail les clés valides, les signatures et la procédure de vérification. Il permet aussi la batch verification, c’est-à-dire la vérification groupée de plusieurs signatures pour économiser des calculs. Cela ne réécrit pas leurs enregistrements dans la chaîne et ne fusionne pas les signatures d’entrées différentes. [1]

Une signature commune par key-path peut ressembler à celle d’une seule clé. La signature seule ne révèle donc pas forcément combien de personnes se sont mises d’accord. Les montants, les liens entre entrées et sorties et le moment de la transaction restent toutefois généralement observables. Schnorr Signature ne chiffre pas le paiement. La confidentialité dépend aussi de l’usage de Taproot, du comportement du portefeuille et du contexte du paiement. [2] [3]

Pour l’utilisateur, l’essentiel est un portefeuille qui affiche correctement le destinataire, le montant et les frais et permet une récupération fiable. Le développeur doit aussi vérifier la prise en charge exacte de BIP340, les vecteurs de test, la gestion des nonce et le comportement en cas d’erreur. Le nom d’un algorithme ne garantit pas tout le produit. Une bonne bibliothèque, telle que libsecp256k1, réalise le calcul cryptographique ; elle ne décide pas si la personne doit réellement approuver le paiement affiché. [4] [9] [6]