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.
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 
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.
J’ai lancé le sujet avec aeris : https://framapiaf.org/@inso/99534373656173495
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.
D’après aeris c’est plus subtil, je t’invite à lire le fil : https://social.imirhil.fr/@aeris/99534489057325277
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)
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 ?
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) :
Avec scrypt, la différence est beaucoup plus atténuée :
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 :
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 : Home | Firo - Privacy-preserving cryptocurrency
Et les vecteurs d’attaque ont été étudiés ici : Attacks on Merkle Tree Proof
Un article qui en parle : The Evolution of the Cryptographic Hash Function in Blockchains — Steemit
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…
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.
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 
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 :
Par contre, suite à ces idées nous pouvons envisager quelque chose de plus simple tout en évitant de devoir stocker toute la blockchain :
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 ?
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 ?
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.
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 
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.
Fort heuresement 
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 :
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.
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 Il en existe que 2 il me semble. Dont une orientée IoT.
Parce-qu’ils sont beaucoup plus sensibles aux attaques sibylles 
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
NEO : NEO (cryptocurrency) - Wikipedia
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 !
EDIT : Ah et ya Steem aussi apparemment : Steem has NO FEES, repeat NO FEES! — Steemit