Cashu

Imaginons qu’Anna envoie un jeton Cashu à Petr par message privé. Elle ne diffuse pas une transaction Bitcoin sur la blockchain. Elle lui transmet des données échangeables auprès du mint concerné. Un jeton peut contenir une ou plusieurs preuves (Proof). Ce sont des enregistrements comportant notamment un montant, une valeur secrète et une signature du mint. Cashu est un protocole commun, pas un service unique doté d’une réserve commune. L’émetteur, l’unité monétaire et le jeu de clés de signature comptent tous. Un montant en sats désigne de petites unités de bitcoin ; le même nombre dans une autre unité n’a pas le même sens. Les jetons d’un mint ne sont pas automatiquement acceptés par un autre. Côté format, V4 utilise l’encodage binaire compact CBOR et contient les preuves d’un seul mint. [1] [2] [9]

Anna peut conserver une copie d’un jeton ordinaire sans condition supplémentaire de dépense. Petr a donc besoin d’un swap : son portefeuille remet les anciennes preuves au mint et en reçoit de nouvelles, associées à des secrets qu’Anna ignore. Le mint invalide les anciennes entrées. Cet échange réussi empêche Anna de dépenser à nouveau la même copie. Une simple consultation d’état ne suffit pas. UNSPENT signifie qu’aucun traitement ni aucune dépense ne sont enregistrés ; rien n’est réservé à Petr. PENDING indique un traitement en cours, SPENT une preuve déjà utilisée. Ne publiez donc pas un jeton comme un reçu : une personne disposant d’une copie utilisable pourrait l’encaisser avant vous. [3] [5]

Une Blind Signature, signature aveugle, sépare l’émission d’un jeton de son utilisation ultérieure. Le portefeuille crée un secret, masque sa représentation mathématique et demande au mint de la signer. Il retire ensuite le masquage. Le mint ne devrait pas pouvoir retrouver la demande d’émission à partir du seul jeton présenté plus tard. Cela ne cache pas tout : les différentes valeurs nominales utilisent des clés différentes, si bien que le mint connaît les catégories de valeurs émises. Ce procédé s’appelle BDHKE et utilise la courbe secp256k1. Inutile de calculer les points de la courbe pour comprendre un paiement ; l’essentiel est de savoir quel lien cette technique protège. [1]

L’extension facultative NUT-12 ajoute DLEQ, une preuve mathématique que la signature utilise la même clé privée que celle correspondant à la clé publique du mint. Avec les données complémentaires nécessaires, Petr peut vérifier la signature sans contacter le mint. Cela ne lui dit pas si une autre copie a déjà été dépensée, si le service répond ou si les réserves de bitcoins sont suffisantes. Si DLEQ est présent, la spécification impose au portefeuille de le vérifier. Cette vérification ne remplace toutefois pas un swap terminé. Le Counterparty risk, risque que l’opérateur manque à ses engagements, demeure. [7]

Petr peut préférer payer une demande Lightning Network plutôt que recevoir d’autres jetons. Cet échange s’appelle melt. Le portefeuille demande d’abord un devis : montant et unité nécessaires, durée de validité et éventuelle réserve pour les frais. Des frais par entrée peuvent s’y ajouter. Il remet ensuite les preuves et le mint effectue le paiement extérieur. HTTP 200 confirme le traitement réussi d’une requête web, pas forcément le paiement. PENDING signifie encore « en cours », tandis que PAID annonce un paiement réussi. Le portefeuille doit suivre le résultat final et l’éventuelle confirmation propre au moyen de paiement. [4]

Le mint peut renouveler son jeu de clés de signature. active=false signifie que l’ancien jeu n’émet plus de nouveaux jetons ; cela ne rend pas à lui seul les anciennes preuves inutilisables comme entrées. Le champ facultatif final_expiry est différent : passé ce terme définitif, la spécification n’impose plus au mint d’honorer ses engagements. Ne confondez pas ces situations. Les frais input_fee_ppk s’appliquent par entrée, et non simplement en pourcentage du montant envoyé. Les tarifs de toutes les preuves utilisées sont additionnés, puis la somme est divisée par 1000. Ce n’est qu’ensuite que les frais sont arrondis à l’unité supérieure. Par exemple, avec un jeu de clés utilisant l’unité sat, 3 entrées à 100 ppk donnent une somme de 300 ; après division et arrondi, les frais sont de 1 sat. Deux paiements identiques peuvent donc coûter différemment selon le nombre de preuves et les jeux de clés employés. [2]

La signature aveugle n’efface ni l’heure, ni les montants, ni les données de connexion. La façon de demander de nouvelles valeurs nominales peut elle-même révéler des informations. NUT-03 recommande de les classer par ordre croissant pour que leur ordre ne trahisse pas inutilement la séparation entre paiement et monnaie rendue. Les consultations répétées de l’expéditeur sur l’état des jetons transmis peuvent aussi faciliter son rapprochement avec le destinataire. Cashu fournit des outils pour des échanges plus confidentiels ; toutes les applications et toutes les situations ne masquent pas automatiquement tous les liens. [3] [5]

La restauration doit correspondre au portefeuille et au mint utilisés. NUT-13 décrit comment retrouver les secrets des jetons et leurs facteurs de masquage à partir de la seed, secret de départ, du jeu de clés et d’un compteur. La version 01 utilise HMAC-SHA256, l’ancienne 00 utilise BIP32. Les signatures que la seed ne peut pas créer sont récupérées auprès du mint via NUT-09 ; il faut ensuite vérifier ce qui a déjà été dépensé. « J’ai une Seed Phrase, je peux tout restaurer n’importe où » ne suffit donc pas. Vérifiez la sauvegarde, la restauration et un petit retrait avant de compter sur un portefeuille. Une sauvegarde ne fait pas répondre un mint disparu et ne reconstitue pas ses réserves. [8] [6]