Je trouvais que les idées étaient un peu floues autour de ce calcul (pas que pour toi). J’ai simplement voulu aider en précisant les choses. Au final, ce n’est pas un calcul inaccessible, mais effectivement coûteux.
3 Likes
J’aimerais ajouter un point annexe sur l’étude précédente. Pour construire des ensembles d’éléments, j’utilise des arbres de recherche, dans lesquels l’insertion, la suppression et la recherche d’un élément parmi N est en o(log(N)). J’utilise cet outil car c’est un vrai couteau Suisse informatique, permettant la création d’ensembles de façon efficace, mais qui, en plus, les maintient en permanence triés (ou non, au choix) sans coût supplémentaire. On peut aussi concaténer deux arbres, couper un arbre en deux, trouver le rang d’un élément, etc… de façon très efficace.
Mais dans le cas étudié, on a juste besoin d’ensembles, sans plus. On peut alors utiliser, pour la recherche et l’insertion, des clés de hachage avec un temps de calcul en o(1) (en général). Cela permet d’éliminer les log des formules précédentes et rendre le calcul (un peu) plus rapide.
J’ai modifié quelques op codes et rajouté des événements.
A part les événements manquants et la plan de déploiement, le document me semble plutôt complet. Est-ce que vous voyez des éléments à rajouter ?
Est-ce qu’on intègre les clés déléguées au calcul, ou en tout cas leur stockage sans pour autant permettre de les changer ?
De même, où en est la réflexion du changement de la preuve de travail ?
J’ai un problème de rendu sur le gitlab :
Je pense qu’il faudra traiter ça plus tard.
Ce serait bien de traiter la correction de la PoW dans la V11 par contre oui.
1 Like
Corrigé.
Dac, par contre je vois mal comment le gérer en soft-fork.
Il faudra probablement une première temporaire ou les 2 modes seront compatibles et une seconde période pour seul le nouveau mode sera accepté…
En fait je m’égare un peu, au niveau des scripts c’est possible d’assurer des soft-forks, mais pour des changements de fonctionnement de la preuve de travail ça me semble plus compliqué et surtout inutile.
On pourra faire ce changement plus tard oui, après ça ne me semble pas vraiment hyper compliqué et on pourrait profiter de ce gros hard-fork pour l’ajouter.
Oui, il faut corriger la PoW dans la V11. C’est le meilleur moment vu le hardfork que ça va être… 
Alors il y a au moins 4 choses a intégrer en v11 selon moi pour la pow :
- changer la formule du handicap pour se baser sur le 2ème tiercile plutot que la médiane
- créer un bonus aléatoire attribué a plusieurs membres différents (pour éviter les attaques ciblés il faut que le bonus touche beaucoup de membres différents) parmi les membres de la fenêtre courante : ça pourrait être par exemple un tiers des calculateurs de la 3ème tranche, un tel bonus aiderait de surcroit a rester plus facilement dans la fenêtre courante tout en favorisant fortement la rotation.
- Modifier la façon dont est écris le nonce pour passer a un nonce binaire
- modifier le défi que représente une valeur de difficulté donnée pour que l’évolution soit continu : comme le suggère je crois aeris on pourrait penser tout ça en binaire directement et définir la difficulté comme étant une condition sur la valeur binaire du hash comme ça on sera sur de pas avoir de “saut”.
1 Like
@nanocryk voilà comme tu me l’a demandé j’ai ajouté les évènements de type “toile de confiance”
Il manque encore les event de type V10 pour la transition, je les ferai un autre jours 
j’ai aussi supprimer un champ dans l’état : il n’est pas nécessaire de sauvegarder le blockstamp de révocation, cette info n’est aujourd’hui pas sauvegardée et n’est d’aucune utilité pour appliquer correctement le protocole. Elle n’est utile qu’a des fin de statistiques détaillés et sera de toute façon connue des noeuds d’archives qui eux garderont en mémoire toutes les transformations des “ev” dernières années a minima.
Autre subtilité : j’ai essayer de respecter le principe de réversibilité de chaque événement à lui seul, c’est a dire qu’il n’y a pas d’événements liés comme c’est actuellement le cas en v10.
C’est pourquoi l’événement joiner synthétise a la fois l’identité, l’adhésion ET les primo-certifications.
C’est également pourquoi j’ai conçu un événement a part pour l’expiration d’une certification qui causerait l’exclusion.
Il y a un point qui n’est pas clair pour moi et que je te laisse clarifier toi même : sous quel format doivent être enregistrez les clés publiques dans l’état ? Il me semble que tu a défini un format générique indépendant de tout algo mais entre tes généric key, compact key, hash key & co je ne m’y retrouve pas !
Il suffirait de définir la difficulté comme un entier tel que le merkle root > difficulté. Je vais regarder comment marche exactement la difficulté dans Bitcoin, l’avantage c’est qu’elle reste exponentielle.
Genial, je vais regarder ça.
On peut stocker sa date pour pouvoir l’oublier après une longue periode. Ca permettrait de réutiliser les pseudos et d’élaguer les anciennes identitées. Avec une durée assez longue on peut admètre que le risque d’usurpassion est assez bas.
Au moins c’est atomique, je regarde ça et je te fais un retour.
Toujours le format décrit au début, qui est lié a une monnaie, a un checksum et stocke le type de clé (algo de crypto, hash ou brut). A part dans cette partie explicative du format de clé, toutes les clés sont dans ce format.
1 Like
Cool, c’est le seul des 4 points que je ne maitrise pas, du coup si tu peut t’en charger et nous faire une proposition de spec c’est parfait 
Autant pour moi je n’avais pas pensé a cette feature, en effet il faut donc remettre ce champ dsl. je pense qu’il durée convenable serait de l’ordre d’une demi-vie, après tout ça correspond au temps “d’oubli” des différences a la moyenne, je trouverai élégant de prendre aussi 40 ans pour l’oubli d’une révocation du coup
Ok du coup comment nomme tu ce format ? J’ai besoin de nommer chaque concept pour m’y retrouver !
Je vais regarder ça oui.
Ca me semble cohérent. Il faudrait par contre réfléchir au changement de clé sans condamner un pseudo pour 40 ans.
This format (called an address) is structured as
Après ce format permet aussi de stocker un script complet/script hash pour pouvoir directement payer dessus, c’est donc pour ça que je parle uniquement de clé dans les scripts. Mais c’est des clés au format adresses, qui contiennent l’algo de crypto.
Tu remarquera qu’il est maintenant obligatoire de passer par une pubkeyhash pour gérer en soft-fork de nouveaux algos.
Je ne vois pas trop le rapport entre une révocation et la convergence à la moyenne Pour moi la révocation devrait avoir la même durée de vie qu’une identité - ev quoi
Ca me semble quand même très long.
Long relativement à quoi ?
Sinon, je pense qu’il serait intéressant de s’assurer que les règles de la V10 sont transposables dans la V11… Ou alors il faudra les convertir. (Voir la formalisation effectuée par cgeek ici : https://git.duniter.org/nodes/typescript/duniter/blob/1.6/doc/Protocol.md#block-1 )
Pour la PoW, il serait bien de penser au changement d’algorithme pour quelque chose d’ASIC-Resistant. (cf le topic https://git.duniter.org/nodes/typescript/duniter/issues/1239 )
Long par rapport au stockage de l’information. Dès la “2ème génération” on va devoir garder 2 générations de membre en mémoire, l’actuelle et la précédente qui n’ont pas encore été oubliés. 10 ans me semble déjà plus pratique tout en empêchant les usurpations d’identité.
Je pense que je vais rajouter une partie complète sur la PoW avec :
- la fonction de PoW
- les clés déléguées
- la difficulté personnalisée
Edit : merci pour le lien, je pense que je vais partir sur une condition Hash < 2^256 - Difficulty. Cette fonction la est linéaire et monotonique.
Avec les arbres de Merkle pour l’instant c’est du SHA256(SHA256(container) + SHA256(ED25519(container)). On pourrait rajouter par dessus ça une autre fonction de hashage ASIC-resistent.
Ok, on parle d’une durée à partir de l’émission de la révocation.
Par contre, comment choisir une bonne valeur… Pas évident. 18 ans c’est le temps nécessaire pour atteindre 80% de la génération de monnaie, ça peut être tout aussi acceptable que 10 ans ou 40 ans.
Mmh, je pensais que le merkleRoot était le “container”. Quid de :
BCRYPT(SHA256(container) + ED25519(container)
EDIT : Il semble que scrypt soit un bon candidat, et on l’utilise déja pour générer les clés dans les clients et duniter : asic resistance - Are there algorithms that could have been chosen for mining that balance CPU/GPU? - Bitcoin Stack Exchange
Oui, on discute de la durée à partir de laquelle cette identité est oublie, et qu’on peut donc recréer une identité avec ce pseudo (et potentiellement la paire de clé mais ça n’a pas vraiment de sens).
En fait j’aimerais éviter d’appliquer des exceptions dans le hashage de l’arbre.
The Merkle tree is made as the following
/signature: signature of thecontainerwith the issuer public key./container: contains data signed by the block issuer.
issuer: issuer public key.nonce: nonce used in the Proof of Work mechanism.date: block forging dateprevious_root: hash of the previous block/transform: list of events discribing transformations on the previous statefinal_state: state after all transformations
Par contre on peut utiliser bcrypt/script par dessus ce Merkle root, ou alors avoir :
/container/hash = bscript(container)/signature = ed25519(hash)
Et appliquer la condition sur le Merkle root, ce qui est beaucoup plus pratique.
script me semble pas mal pour ça, mais on va tomber sur des difficultés très basses vu le nombre de sol/s. Ca ne risque pas d’être un vecteur d’attaque ?
Sinon, autre solution :
On prend l’arbre suivant :
/root
/dataroot
/container
/signature
/noonce
Et le block UID correspond à :
blockUID = SCRYPT(/root)
SHA256(/dataroot)
SHA256(/container)
SHA256(/signature)
/noonce
Bon après, le côté ASIC-Resistant de scrypt a pas l’air évident : https://themerkle.com/scrypt-vs-x11-vs-sha-256/
Il faut a priori jouer avec les paramètres “N-R-P” de scrypt pour qu’ils évoluent dans le temps, obligeant les constructeurs d’ASIC à reproduire de nouveaux circuits lorsque le réseau change de valeur de N.