Mimblewimble est un protocole de cryptomonnaie un peu atypique, où il n’y a pas de compte à une clé publique. Cela permettrait l’anonymat. Voici le dépôt, une intro détaillée et un article simplifié mais quand même détaillé.
Je n’ai pas fini de lire donc je ne sais pas précisément ce que ça apporte ni comment ça marche mais peut-être que c’est implémentable dans les conditions de dépense de DUBP.
@nanocryk m’avait déjà parlé de Mimblewinble il y a 2 ans et m’avait notamment expliqué le principe cut-through. J’avais regardé il y a 2 ans mais ça ne semblait pas très mature et j’y voyais plusieurs inconvénients.
Du coup je viens de recreuser tout ça :
C’est clairement passionnant (enfin perso la crypto ça me passionne) et très élégant, mais il faut des connaissances très solides en cryptographie sur courbes elliptiques, signature de Schnorr et range proof pour bien comprendre.
J’y vois toujours les inconvénients de l’époque, à savoir :
Le protocole Mimblewinble nécessite que les documents transactions soient complétés par toutes les parties puis finalisés par l’un des issuers, ce qui alourdis fortement le processus même pour une transaction simple avec 1 issuer et 1 receiver, on a alors 3 étapes :
C’est quand même beaucoup moins fluide et beaucoup plus longs si je veux faire un paiement quand je n’ai pas la personne en face ou que cette dernière n’a pas son tel/ordi sur elle.
Le protocole Mimblewinble n’a pas été pensé pour mélanger des transactions anonymes et des transactions en clair.
Vu les contraintes supplémentaires en termes d’étapes de validation, il me semble dommageable d’imposer que les transactions aient cette lourdeur procédurale dans tous les cas.
Un protocole mixte qui n’ajouterait de lourdeur dans la procédure d’une transaction que lorsque l’émetteur souhaite l’anonymisée me semblerait plus désirable.
Dans le protocole Mimblewinble, l’ownership d’une source est nécessairement une clé privée « temporaire » générée aléatoirement par le destinataire de cette source au moment de la génération du document transaction (c’est d’ailleurs en partie pour cela que le process de création de la transaction nécessite les 2 parties).
Ce principe ne permet pas, a priori, l’utilisation de conditions complexes de déblocages d’une source, pas au niveau de ce que propose DUBP actuellement en tout cas.
Cela rend, a priori, impossible l’implémentation des Lightning Network, qui me semblent pourtant indispensables à terme pour une utilisation massive à grande échelle.
Je précise bien « a priori » car j’ai quelques idées d’adaptations du protocole qui pourrait peut-être le rendre compatible avec les besoins des LN, mais je ne suis pas certain que cela puisse marcher. S’il y a une volonté forte d’implémenter ce protocole je creuserai peut-être plus avant les idées que j’ai pour le rendre compatible avec les LN, mais pour le moment je ne souhaite pas le faire (voir plus bas).
A moins d’être un expert en crypto, impossible de vérifier par soi-même qu’il n’y a pas de triche dans un tel protocole, cela demande donc une plus grande confiance en « ceux qui savent ».
L’avantage d’une monnaie transparente ou tout le monde voit tous les transferts et les soldes, c’est que n’importe-quel utilisateur peut constater visuellement qu’il n’y a pas de triche.
Je me souviens d’une anecdote que m’a raconté un utilisateur de la G1: il m’a raconté après coup qu’au début il était persuadé que c’était une arnaque mais avait décidé d’expérimenter quand même, il se demandait quand est-ce qu’on allait lui demander des UNL. Quand il a enfin touché son premier DU il est allé vérifier sur mon compte et celui de cgeek pour voir si on ne créait pas « plus » de DU que les autres. Ça peut nous faire sourire, mais pour lui c’était important de pouvoir constater visuellement que tout le monde était bien a égalité.
Dans une monnaie totalement anonymisée, l’utilisateur lambda ne voit passer que des données pseudo-aléatoires qui n’ont aucun sens humain, et n’a aucun moyen de constater visuellement ce qui se passe pour les autres.
Je ne dis pas qu’il ne faut donc pas d’anonymisation, je pose simplement le débat sur le fait que l’anonymisation totale n’a pas que des avantages.
L’anonymisation partielle et choisie vie des systèmes de mixage semble être un bon compromis.
De ce que je perçois des utilisateurs de la G1 à travers les apéros ML, les forums, les différents groupes ML sur les réseaux sociaux, axiom-team et autres canaux, je ne vois quasiment jamais d’utilisateur en demande de davantage d’anonymat.
Je vois plutôt que les utilisateurs demandent un client plus rapide, des transactions qui ne restent plus bloqués dans des forks, la possibilité d’avoir des gbillet ou autre moyen de paiement plus simple, etc
Personnellement, l’une de mes motivations à coder est quand même que mon code serve aux gens in finé, et j’ai l’impression que l’anonymisation totale n’est pas une demande de la communauté à l’heure actuelle en tout cas.
Vu la charge de travail colossale qu’ajouterait une anonymisation totale, les contraintes que cela ajouterait à l’utilisation, la faible demande en ce sens, les impacts sur la confiance que peut/doit accorder l’utilisateur lambda, et les très probables problèmes de compatibilité avec les LN, je ne suis pour le moment pas favorable a une implémentation dans DUBP.
Rien n’est figé dans le marbre, et je changerai peut-être d’avis à l’avenir en fonction des nouvelles informations, de l’évolution de la demande, de l’évolution de l’état de l’art en crypto, d’une éventuelle future compatibilité avec les LN, etc.
Un compromis possible, et pour lequel une éventuelle implémentation dans DUBP à moyen terme me semble beaucoup plus envisageable, c’est l’anonymisation des montants des UTXO uniquement. Cela résoudrait plusieurs problèmes cités plus haut :
Toutefois, si techniquement l’anonymisation des montants me semble faisable à moyen terme, y a t’il une réelle demande pour cela ?
L’anonymisation des montants aurait tout de même un gros inconvénient techniquement : l’explosion de la taille des documents transaction (environ 11ko pour une transaction simple !).
En effet, masquer les montant nécessite l’ajout d’une « range proof » prouvant que le montant n’est pas négatif, sinon quoi n’importe-quel utilisateur pourrait créer un détruire de la monnaie lors d’une transaction :
Si Bob à 3 unités il peut envoyer 5 unités à Carole puis se renvoyer -2 unités a lui-même. La somme des outputs est alors bien égale a la somme des inputs : 5+ (-2) = 3.
Il faut donc s’assurer que chaque output à un montant strictement positif, sans connaître ce montant, c’est ce que permettent les range proof, mais elles ont un énorme inconvénient : leur taille.
Chaque output devrait avoir sa range proof, et une range proof peut peser jusqu’à 5134 octets (~5 Ko).
Ce que fait grin pour gérer ce problème, c’est qu’ils « élague » les proof des veilles transactions, l’idée c’est qu’on a besoin de vérifier qu’une transaction est valide que lors de la réception du bloc qui la contient.
Une fois un certain temps passé (au moins égal à la fenêtre de fork), on sait que cette transaction ne sera jamais remise en cause (sauf réécriture de l’histoire par la communauté suite a un cas de force majeur style attaque très grave mettant en danger la survie de la monnaie).
Est-ce vraiment essentiel de pouvoir reprouver intégralement une transaction qui a plusieurs mois/années ?
Sachant qu’un utilisateur peut très bien stoker en local ou/et chez un prestataire les range proof de toutes les transactions qu’il a émis sans limite de durée pour pouvoir prouver ultérieurement la validité d’une transaction qu’il a émise par le passé.
Je dis juste qu’il ne me semble pas indispensable que le réseau dans son ensemble conserve cette information.
A mon avis, avant de parler anonymisation des montants, il faudrait implémenter les features de base qu’on retrouve dans bitcoin & co. C’est à dire 2 axes d’anonymisation, côté client et côté serveur :
C’est un peu de boulot suivant les axes choisis, mais infiniment moins impactant qu’une refonte protocolaire d’anonymisation au sein des transactions.
Je plussoie à 200% et le passage au format adresse fait déjà parti des nombreux changement de protocole que j’ai en tête pour l’avenir 