oui c’est la clef principale qui doit pouvoir révoquer la clef déléguée.
La clé principale doit permettre de révoquer la clé déléguée en la changeant. Mais pour insister les membre à ne pas faire n’importe quoi, la clé déléguée permet aussi de révoquer le compte. Ça évite que les membres puisse donner leur clé déléguée à n’importe qui pour qu’il calcule à sa place.
Le bonus aléatoire, super idée, mais pas besoin d’intégrer des fonctions lourdes et du zéro knowledge, nous avons déjà un générateur de nombres aléatoires qui fait toujours consensus : le hash du bloc courant (non prévisible graçe au nonce).
Il suffit de transformer le hash en nombre entier et de calculer le modulo (le reste de la division euclidienne) par la taille de l’échantillon, c’est trè s facile a coder et donnera le même résultat, et tout cas je saurais coder ça sans problème 
Je suis d’accord pour le bonus aléatoire à partir du hash du bloc.
Par contre plus tard je pense qu’il sera bon d’intégrer des VRF et du zero-knownledge pour permettre de nouvelles choses.
Je préfère que Duniter reste léger, le zéro-knowledge c’est gourmand en ressource, et pour l’instant je ne vois pas en quoi sa serait nécessaire. Il vaut mieux que le coeur reste exclusivement dédié aux fonctionnement de la monnaie !
1 Like
Tu peux aller au bout de ton idée afin de comprendre qui obtient quel bonus ?
1 Like
Je suis de l’avis d’Inso, va au bout de ta réflexion Eloïs car la VRF apporte vraiment le gros plus du tirage aléatoire personnel et non connu publiquement, jusqu’à ce que son bénéficiaire le prouve.
En effet il ne faudrait pas que tout un chacun sache par avance qui va bénéficier du bonus, sous peine de se faire attaquer par DoS pour surcharger le serveur, ce qui contrecarrerait le bonus.
Mais aussi, on ne voudrait pas qu’il suffise de trouver “un bon nonce” qui nous avantagerait, car alors les grosses configs sont avantagées elles aussi.
En parallèle de nos réflexions sur des protections pour la clé déléguée, on peut aussi ajouter des règles concernant l’écriture. Car finalement, c’est bien le point qui nous importe en plus de sécuriser le compte membre : on ne souhaite pas qu’un attaquant prenne le contrôle.
Qu’ai-je à vous proposer comme sécurité ? Je pense à l’inertie ! Car sur quels champs un écrivain de bloc Duniter a-t-il la main ?
- l’heure
- les champs multilignes (identités, certifications, adhésions, révocations, transactions, délégations)
Concernant l’heure, celle-ci est bornée pour limiter les abus. Concernant les champs multilignes en revanche, un attaquant peut très bien mettre la quantité de données qu’il veut, notamment zéro lignes, ce qui est emmerdant. Je propose donc la règle simple suivante : tout bloc doit contenir, pour chaque champ multilignes, +/- 20% du nombre moyen de lignes de l’ensemble des blocs de la fenêtre courante. Donc si nous avons 30 écrivains dans la fenêtre courante (comme sur la Ğ1 en ce moment), nous avons une fenêtre de 151 blocs sur lesquels faire nos moyennes.
Attention, je vois bien qu’il y a des limites à la marge, par exemple si la moyenne est de 1 certification par bloc, comment un nouveau peut-il être intégré (il lui faut au moins 5 certifications écrites simultanément) ? Mais vous voyez l’idée générale : un attaquant, même s’il prend la main un certain temps sur la blockchain, ne peut pas empêcher l’écriture des transactions/certifications/etc.
Cela ne doit pas se substituer à la difficulté personnalisée, il est vraiment important de forcer la rotation de l’écriture pour empêcher tout abus.
Et du coup s’il n’y a pas de certification dans la mempool, impossible de proposer un bloc ?
Relire le passage :
Notamment, s’il y a 50 certifications en moyenne par bloc, avec des limites à +/- 20%, alors la probabilité d’en avoir aucune dans la pool pendant 5 minutes est pratiquement nul, et au pire il suffit d’attendre.
Ce n’est pas un problème, au contraire cela nous incitera a mettre en place des mécanismes anti ddos sur toutes les api et incitera les membres calculant a faire attention a l’anonymat de leur noeud.
Il n’est de toute façon pas bon a terme de garder les nœuds membres identifiables trop facilement, cela facilite grandement les attaques sur un membre en particulier pour raisons personnelles par exemple (ça finira forcément par arriver a long terme).
J’ai déjà prévu de permettre facilement aux membres qui le souhaitent d’utiliser un trousseau de clé réseau différent du trousseau de clé membre, j’ai expliquer ça dans le ticket #1182. Cette possibilité ne demande aucun changement de protocole et n’a aucun rapport avec les concepts de clé déléguée.
Et via WS2P, il est impossible lorsque l’on reçoit un document block de savoir par quel noeud il a été trouvé.
je ne vois pas le rapport, qu’appelle tu “un bon nonce” ? je propose de ce fixer sur le hash du bloc courant pas sur le nonce, et il n’y a pas de lien prédicitible entre un nonce et le hash final du bloc…
Qui plus est on est libre du choix du panel de tirés au sort, on peut choisir de ne tirer au sort que parmi les membres de la 3ème tranche par exemple, ce qui favoriserait encore plus la rotation des calculateurs 
Au prix du zero-knownledge qui est un process cryptographiqiue très lourd et gourmand en ressources, incompatible avec l’idée de pouvoir tourner duniter h24 sur un raspi voir plus petit encore…
Oui ça c’est une bonne idée, différencier la clé du nœud de la clé de calcul. Ça réglerait plusieurs problèmes d’un coup.
J’imaginais le cas où “la loterie” était basée sur le hash du bloc en cours de calcul, mais en fait tu parlais d’un tirage fait sur le hash du bloc courant, donc oublie ma remarque.
Je ne sais pas si les VRF sont du zero-knowledge, c’est nanocryk qui prétend cela, mais même si c’est le cas je ne constate pas de grosse consommation sur ma machine après avoir codé les fonctions de signature et de preuve en C++.
Je reste convaincu que c’est un mécanisme très intéressant et pas si coûteux, après ce n’est pas prioritaire du tout. On peut débuter le tirage aléatoire de la façon dont tu l’évoques et avec différenciation clé nœud / clé calcul, ça sera déjà une très bonne première approche. Plus tard, il serait possible de modifier la méthode de tirage si besoin.
Tu produits une preuve du résultat sans donner comment tu l’as eu. C’est donc zero-knownlege proof 
Je le déduis, mais je l’ai lu aussi dans un des documents que j’avais trouvé sur les VRF.
1 Like