Cashu est un protocole ouvert d’e-cash à signatures aveugles, souvent utilisé avec Bitcoin via Lightning Network. Le portefeuille détient des preuves émises par un émetteur précis, sans pouvoir signer pour sa réserve de bitcoins.
Cashu n’est pas un émetteur commun unique. Le jeton identifie son émetteur, son unité et son jeu de clés de signature ; un montant numérique identique ne signifie pas une même monnaie ou obligation. Les jetons d’un émetteur ne sont pas automatiquement remboursables chez un autre. Le format V4 utilise CBOR et contient les preuves d’un seul émetteur. [Cashu — NUT-00: Protocol and tokens] [Cashu — NUT-02: Keysets and fees] [Cashu — Project introduction]
Le protocole de base utilise BDHKE sur secp256k1. Le portefeuille crée un secret et aveugle son point, l’émetteur le signe, puis le portefeuille retire l’aveuglement. Les coupures ont des clés distinctes : l’émetteur connaît les valeurs des preuves émises, même s’il ne doit pas connaître leur future forme non aveuglée. [Cashu — NUT-00: Protocol and tokens]
Un jeton ordinaire sans condition peut être copié. Le destinataire l’échange par swap contre de nouvelles preuves avec ses propres secrets ; l’émetteur invalide les anciennes entrées. UNSPENT est un état instantané, pas une réservation pour le destinataire. PENDING indique un traitement en cours, SPENT une preuve déjà utilisée. [Cashu — NUT-03: Swap tokens] [Cashu — NUT-07: Token state check]
L’extension facultative NUT-12 ajoute une preuve DLEQ liant la signature à la clé publique de l’émetteur. Avec les données nécessaires, le destinataire peut la vérifier hors ligne. Cela ne révèle ni si quelqu’un a dépensé le jeton entre-temps, ni si l’émetteur répond ou possède des réserves. La vérification hors ligne ne remplace donc pas la réception par swap. [Cashu — NUT-12: Offline signature validation]
NUT-02 distingue active=false du champ facultatif final_expiry. Un jeu inactif ne crée plus de nouveaux jetons, mais ses preuves restent acceptées en entrée ; après l’expiration finale, la spécification n’oblige plus l’émetteur à les honorer. Les frais d’entrée input_fee_ppk sont additionnés selon le nombre et le tarif des preuves, puis arrondis vers le haut. [Cashu — NUT-02: Keysets and fees]
Lors d’un melt, le portefeuille fournit des preuves pour un paiement externe, souvent via Lightning Network. Le devis précise montant, unité, validité et éventuelle réserve de frais ; des frais d’entrée peuvent s’y ajouter. HTTP 200 avec PENDING ne confirme pas le paiement. Il faut distinguer résultat définitif et acceptation de la demande. [Cashu — NUT-05: Melting tokens]
L’aveuglement n’efface ni montants, ni horaires, ni informations de connexion. NUT-03 recommande de trier les coupures demandées pour que leur ordre ne révèle pas la séparation entre paiement et monnaie rendue. Les demandes de l’expéditeur sur l’état des preuves transmises peuvent aider l’émetteur à relier expéditeur et destinataire. [Cashu — NUT-03: Swap tokens] [Cashu — NUT-07: Token state check]
NUT-13 dérive secrets et facteurs d’aveuglement depuis la seed selon le jeu de clés et le compteur. La version 01 utilise HMAC-SHA256, l’ancienne 00 BIP32. La restauration exige les jeux originaux et les signatures obtenues via NUT-09, puis une vérification des dépenses. Sans coopération de l’émetteur, la seed ne garantit ni récupération des signatures ni retrait des réserves. [Cashu — NUT-13: Deterministic secrets] [Cashu — NUT-09: Restore signatures]
Pour une vision complète, lisez aussi Fedimint, Chaumian eCash, Blind signature, Lightning Network, Counterparty risk, Satoshi. Cette entrée est également citée par Chaumian eCash, Blind signature, Fedimint, Fiduciary Media.