Discussion autour de la RFC5 (devenue fygg)

protocole

#121

Dans le protocole actuel on a le nonce qui affecte la signature, j’ai fait de même.
Ca me dérange un peu d’avoir le BlockUID en dehors de l’arbre, mais à voir.

Par contre très bonne idée de jouer sur les params “N-R-P” qui pourraient dépendre de l’état de la blockchain au moment du changement, ce qui fait qu’on ne peut pas concevoir d’ASICs a l’avance.


#122

Oui, je ne sais plus pourquoi @cgeek avait décidé de faire comme ça mais il avait une bonne raison.

Faudrait qu’il réexplique quand il aura le temps :slight_smile:


#123

Il pensait que ed25519 était un minimum ASIC-resistent, et du coup avoir le nonce dans la signature signifie qu’il faut appliquer ed25519 pour chaque nonce.


#124

J’ai lancé le sujet avec aeris : https://framapiaf.org/@inso/99534373656173495


#125

Oui, il y a pas mal d’ASIC pour scrypt dans la nature, à l’origine pour litecoin et ses dérivés. Il vaut mieux utiliser quelque chose comme scrypt-N ou scrypt-jane qui sont a priori plus résistants.


#126

D’après aeris c’est plus subtil, je t’invite à lire le fil : https://social.imirhil.fr/@aeris/99534489057325277


#127

Argon2 semble être aussi intéressant à ce titre. Il a même été conçu pour ça : https://www.cryptolux.org/images/c/cd/Egalitarian.pdf

@nanocryk : je t’invite à lire le chapitre “MTP” (merkle tree proof)


#128

Je me pose aussi la question « qu’est-ce qu’on veut éviter en étant ASIC/GPU-résistant » ? Parce que côté CPU, il y a aussi la possibilité du bot-net qui est tout aussi dangereuse (cf vertcoin). Mais dans duniter, ce qui change tout, c’est l’identification du calculateur, et en tant que tel c’est une très bonne protection contre les attaques (avec l’ajustement de la difficulté pour chaque membre calculant). En fait, quelqu’un qui ferait un ASIC pour duniter se verrait pénalisé et ne calculerait au final pas beaucoup plus de blocs que les autres.
Le seul danger que je vois est qu’un membre ayant une difficulté faible (typiquement, minant avec un raspberry) mette tout d’un coup sur le réseau une puissance de calcul d’un ordre de grandeur n’ayant plus rien à voir, en espérant calculer plusieurs blocs d’affilée (admettons, avec juste quelques clés membres) pour espérer faire des doubles dépenses par exemple, avant que sa difficulté personnalisée ne remonte trop. Mais à moins d’utiliser sha avec ses ASIC extrêmement rapides, ça ne me semble pas possible, même avec du scrypt simple. J’ai raté quelque chose ?


#129

Si les écarts sont trop élevés entre membres calculant, ça posera quand même des problèmes malgré la difficulté personnalisée (On parle ici d’une échelle de 1/10^12 de puissance entre différents membres…)

Rien que parce que la difficulté personnalisée ne s’applique pas instantanément, il faut essayer d’empêcher les membres d’avoir potentiellement une telle différence de puissance.

Ainsi sur le double SHA utilisé par bitcoin, on a (je cite aeris) :

  • 2-10MH/s CPU
  • 300-700MH/s GPU
  • 6-14TH/s ASIC

Avec scrypt, la différence est beaucoup plus atténuée :

  • 25-50kH/s sur CPU
  • 300-700kH/s sur GPU
  • 1-2GH/s sur ASIC

Donc ça limite aussi les différences gigantesques qu’on peut avoir entre 2 membres.

Outre le changement d’algorithme de hash, on peut aussi envisager de changer le la règle de PoW (voir le chapitre “Proof of work” ci-dessous) :

Dans ce document, ils proposent d’utiliser un scheme de PoW qui :

  • A un cout élevé en CPU et en RAM pour ceux qui forgent les preuves
  • A un cout faible en CPU et en RAM pour ceux qui vérifient les preuves

Ce qui me parait intéressant pour permettre aux raspberry de continuer à calculer des blocs tout en vérifiant les blocs reçus, évitant ainsi les attaques de type DDOS sur les verifiers.
A voir dans le fond du papier l’intéret, il semble qu’il existe quelques vecteurs d’attaque, il faut voir quelles contre-mesures ils proposent.

Le scheme MTP est décrit sur le site de zCoin : https://zcoin.io/ufaqs/what-is-mtp/
Et les vecteurs d’attaque ont été étudiés ici : http://blog.zorinaq.com/attacks-on-mtp/
Un article qui en parle : https://steemit.com/cryptocurrency/@zvnowman/hash-no-not-that-kind-the-crypto-kind

MTP a l’air encore très expérimental. Je ne recommanderai donc pas d’aller dans cette direction pour la V11 du protocole. Mais ça reste intéressant…

A court terme, une simple migration vers scrypt avec une cible d’usage de RAM de 16 mo devrait suffire pour calmer les mineurs ASIC.

EDIT : Un peit complément vis à vis de l’usage RAM qu’il faut cibler pour les paramètres NRP :

Côté Litecoin, ils utilisent ça :

With the scrypt parameters used in litecoin’s implementation (N = 1024; p = 1; r = 1), each thread needs about 64-128 KB depending on the lookup_gap and thread_concurrency settings when mining with a GPU

Ces paramètres ont été choisie pour que ça puisse être rapide sur CPU (cohérent avec le cache CPU), tout en empéchant une accélération trop élevée sur GPU/ASIC.

Je propose de viser une valeur similaire. Le cache CPU des raspberry pi est de : L1 32KB, L2 512KB. On peut donc viser quelque chose de proche. Il faudrait expérimenter les différentes valeurs et comparer…


#130

Oui mais pas seulement : s’il n’y a pas signature dans la mécanique de PoW, alors tu peux déléguer la preuve à un tiers.


#131

Bien sur, mais dans son exemple il y avait bien une signature mais qui ne dépendait pas du nonce, j’expliquait donc la raison :wink:


#132

Bon, j’ai pas mal réfléchi au concept d’adresses que l’on a imaginé et il me semble que ça reste moins intéressant que de stocker les sorties non dépenses.

En effet :

  • En stockant uniquement le montant pour chaque adresse, il y a possibilité de rejeu des transactions
  • On peux contrer cette possibilité en ajoutant un “index” qui est incrémenté à chaque transaction, mais qui doit être stocké indéfiniment pour toutes les adresses qui ont été utilisées, ce qui est un énorme problème, surtout si on voudrait utiliser des HD wallets pour faire des adresses à usages unique (augmentant l’anonymisé et la fongibilité)

Par contre, suite à ces idées nous pouvons envisager quelque chose de plus simple tout en évitant de devoir stocker toute la blockchain :

  • On garde le système de transactions où l’on stocke les sorties non dépensées (UTXOs)
  • On stocke dans l’arbre de Merkle l’ensemble des UTXOs, les transactions en détruisant et créant de nouvelles. Si l’évènement correspondant stocke les UTXOs dépensés, alors elles sont complètement réversibles et seul le dernier état doit être stocké. Cet ensemble pèse un peu moins de 3 Go pour Bitcoin et peut perdre en taille, contrairement à tout l’historique qui est beaucoup plus lourd et que ne fait que s’alourdir.

Avec cette solution, les anciennes sources sont supprimée de l’arbre et il n’y a aucun risque de rejeu vu qu’on spécifie les UTXO sources. Quand au DU, on peut toujours stocker la somme non dépensée de chaqu’un des membres, et on peut en utiliser une partie en source spéciale de nouvelles transactions.

Enfin pour le format d’adresse qui à été défini, il peut toujours être utilisé pour générer les scripts comme prévu.

Qu’en pensez-vous ?


#133

En gros, tu veux garder le système actuel ? Oui, c’est vrai qu’on avait pas vu dans un premier temps le problème du replay de transaction à cause de l’historique pruné.

Mais est-ce que pour la même raison ça n’ouvre pas la porte au rejeux de transaction à partir d’un DU ?


#134

Ou alors on garde l’ancien comportement pour les DU également, et pour éviter d’avoir une explosion du nombre d’UTXO/UUDO, on ajoute la règle : une transaction ne peut avoir plus de sorties que d’entrées.

C’est radical, mais au moins ça résout pas mal de problèmes. Et grosso modo, le nombre de sources nouvelles par jour = N, le nombre de membres.

Et aussi, en mettant une limite max au nombre d’entrées, de fait on force les sources à s’associer à mesure que les montants à transférer augmentent.


#135

On garde l’ensemble des UTXOs, mais celui-ci est stocké dans une arbre de Merkle dans chaque bloc, donc pas besoin de télécharger et appliquer tout l’historique des transactions.

Pour les DU on garde le système proposé avec les indexes. Du coup le nombre d’indexes est proche du nombre de membres et est borné par la taille de la toile de confiance, et non par le nombre de clé qui est plus qu’astronomiquement grand.

Pour la consommation du DU, on peut dire que le DU est entièrement consommé quand il est fourni en source. Quand un membre est revoqué et qu’il récupère ce qui lui reste de dividende, ça vide entièrement cette entrée et on peut l’effacer. Du coup l’ensemble des UUDOs ne sera jamais beaucoup plus grand que le nombre de membres.

Ce qui est énorme quand le nombre de membre est plus grand. Un nombre, un compteur anti-rejeu et la consommation totale à l’utilisation est beaucoup plus économe :wink:

Ce qui limite énormément les possibilités, voir rend inutilisable la monnaie. En effet si je n’ai qu’une source et que je ne vais pas la “dépenser entierement”, il faut que j’envoi le reste autre part. On a donc du 1 -> 2. Par contre les noeuds pourraient préférer faire passer les transactions qui utilisent des UTXOs anciennes et qui créés le moins de nouveaux UTXOs, sans pour autant les interdire.


#136

Fort heuresement :smiley:

Donc la révocation = une transaction qui convertit la source DU en UTXO ?

Oui c’est très bien ça aussi comme mécanisme anti-spam.

D’ailleurs une annexe à ce sujet serait bien : ça permettrait d’éclaircir une bonne fois pour toute le pourquoi c’est une monnaie no-fees :

  • Pourquoi ?
    • Neutralité du réseau technique vis à vis de l’économie
  • Comment ?
    • En priorisant les transactions suivant les facteurs “date de l’UTXO” , “ratio outputs/inputs”, etc
    • Avec une base de donnée limitée en taille (output de taille minimum relative au DU, DU limité par le nombre de membre, nombre de membre limité)

#137

Ow, je n’avais pas pensé à ça, mais c’est une très bonne idée. Ça pourrait permettre à une personne qui perd sa clé membre de récupérer son DU. Quand il est membre, il peut décider de générer un nouveau document de révocation contenant le nouveau script lock. Et du coup le nombre d’entrée de DU est strictement égal au nombre de membres actifs ou exclus non révoqués. Ca peut aussi servir pour automatiquement envoyer l’argent à la famille/heritier après la mort/disparition du membre… Gros +1

Edit : comment on fait dans le cas d’une revocation automatique ? On a un document qui précise le lock script dans ce cas là ? Le document Membership peut-être ?

Je vais essayer de faire ça. A l’origine je n’était pas convaincu de ce côté no-fees, mais vu que l’on a cette possibilité de 1 humain = 1 vote, tant que l’on a une majorité de personnes honnêtes on peut appliquer des règles non obligatoires pour fluidifier le réseau. Tout le monde ne les appliquera pas, mais la majorité le feront et c’est largement suffisant.

Bon, je go modifier cette RFC.


#138

Oui ça me semble correct. A chaque renouvellement de membership, on peut changer la clé destinataire en cas d’expiration totale de l’identité.

Quand on va publier ça, ça risque de faire du bruit, l’univers des crypto y croit pas du tout au no-fees :wink: Il en existe que 2 il me semble. Dont une orientée IoT.


#139

Parce-qu’ils sont beaucoup plus sensibles aux attaques sibylles :stuck_out_tongue: Duniter va continuer de m’émerveiller pendant longtemps je pense !

IOTA, qui n’utilise pas une blockchain mais une “Tangle”, qui est en fait un DAG des transactions qui possèdent chaqu’une leur propre PoW. Pour nous ce n’est pas utilisable, vu que l’on a besoin des blocs pour les évènements liés aux membre (DU, expiration des documents). C’est quoi la 2ème ?

Edit : du coup en plus avec ce système très peu de fonds restent liés à clé privée de membre, ce qui limite les risques de faire tourner un nœud. La plupart des DU seront déjà dans des UTXOs, et le reste sera récupéré avec l’expiration/révocation de l’identité.

Edit 2 : RFC mise à jour. Dites moi si j’ai oublié de corriger un endroit ou si ça introduit de nouveaux problèmes :slight_smile:


#140

NEO : https://en.wikipedia.org/wiki/NEO_(cryptocurrency)

Mais c’est (de ce que j’ai compris) du à sa nature “actionnariale” et non “monétaire” (les parts ne sont pas divisibles, il en existe donc un stock très limité en bdd).

Je regarde ça ce soir ! :slight_smile:

EDIT : Ah et ya Steem aussi apparemment : https://steemit.com/steem/@chitty/steem-has-no-fees-repeat-no-fees