OK, le sujet revient tellement régulièrement que je ne peux plus l’ignorer.
Beaucoup sont effrayés par l’idée d’une attaque Sybille, comme vous pouvez rapidement le voir à travers cette recherche : https://forum.duniter.org/search?q=sybil
Une proposition qui revient souvent est de pouvoir révoquer un individu, l’éjecter de la toile, de sorte que celui-ci ne puisse plus nuire sur 3 aspects :
ne puisse plus certifier
ne puisse plus produire de DU illégitimes
ne puisse plus participer de l’écriture de la blokchain
Je suis très clairement contre le fait de retirer ces 3 droits fondamentaux, c’est une forme de peine de mort, et il est possible de se tromper. Je n’en veux pas et ne coderai pas l’éjection forcée d’un individu.
Toutefois … nous pouvons classer ces 3 droits par ordre de gravité :
ne puisse plus certifier (grave - propage l’infection)
ne puisse plus participer de l’écriture de la blokchain (très grave - détruit la monnaie)
ne puisse plus produire de DU illégitimes (?)
Or pour les 3ème paramètre, nous avons ici une étude qui montre les différents impacts de DU illégitimes générés par des attaquants. Celle-ci n’est pas encore terminée, mais elle en dit déjà beaucoup. Notamment, on pourrait se permettre de déclarer ceci :
ne puisse plus produire de DU illégitimes (gravité qui dépend de la magnitude)
Or, parmi ces 3 droits fondamentaux, si ce dernier paraît le moins grave à l’échelle globale, il est potentiellement le plus grave à l’échelle de l’individu.
Proposition
Donc, si tant est qu’on implémente une fonction active permettant d’endiguer une attaque Sybille, en plus des divers mécanismes qui nous protègent déjà, je n’y serai pas opposé tant que cela n’impacte pas la possibilité de créer sa part de monnaie.
J’imagine donc la possibilité de développer un nouveau document, la “neutralisation”, qui à l’instar d’un anticorps vient bloquer la propagation et l’action d’un virus, sans le détruire pour autant. Le neutraliser, en lui retirant les 2 premiers droits tant qu’une action de neutralisation opérera contre lui.
Eventuellement, celui-ci perdra son statut de membre par le jeu des certifications, comme tout le monde.
Il reste à définir les mécanismes d’activation, à savoir à quel seuil la neutralisation opère (neutraQty ?), ou s’il s’agit d’un rapport (nombre de liens entrants / nombre de neutralisations), la durée de vie d’une neutralisation, le stock, etc.
L’anticorps pourrait attaquer les membres sains. Toute complication du protocole de base ne fait qu’éloigner du principe de parcimonie, qui doit générer le code le plus simple possible. Une fois une monnaie libre en production le fait de créer des logiciels supplémentaires qui établissent des règles sur la base des règles fondamentales reste tout à fait possible, mais penser compliquer le fond n’est en soi qu’une cause repoussant la production d’une monnaie libre à 50 ans, 100 ans ou 200 ans dans le futur.
De ce point de vue d’ailleurs même l’UID est superflu.
Je considère que l’utilisation de Duniter doit se faire avec des règles précises, énoncées qui dicte le droit (d’utilisation), mais il n’a pas à inclure en son sein de code pénal.
Si il y a mésusage du droit par un utilisateur d’une manière ou d’une autre, l’attaque Sybille semblant en faire partie, ce n’est pas à Duniter de juger et encore moins de punir. La justice doit rester une affaire humaine.
Ces considérations doivent être pensées autour de Duniter, par la communauté, mais certainement pas dans Duniter, par un truchement d’algorithmes.
Pas uniquement par la communauté, mais par la justice en général, tout comme la justice peut tout à fait et a déjà condamné un mauvais usage de la GPL.
C’est à celui qui est extérieur à la communauté humaine de le dire. Mais la communauté humaine générale est supérieure ou égale à la communauté humaine souhaitant adopter une monnaie libre.
Le problème est que si le socle comporte des failles, les couches supérieures les subiront. Cf les histoires de failles Openssl, Bash, etc, ou ce sont les logiciels bâtis sur eux qui ont subi les failles.
De plus, tant que la monnaie libre n’est pas reconnue, si il est aisé de la détruire par une attaque récursive de création de sybilles, elle n’aura même pas le temps d’être considérée par la communauté humaine de niveau supérieure.
Après, il est possible de neutraliser les attaquants d’une autre manière, par non renouvellement des certifications. Mais il faut alors peut-être une valeur de période de renouvellement distincte de la période d’émission de nouvelle certification.
Que veux-tu dire par là?
Qu’une personne ne peut certifier qu’une seule fois un compte pendant une période donnée?
Je n’ai pas encore d’avis tranché pour le moment, mais même si rien n’est intégré pour neutraliser un compte dans Duniter aujourd’hui. En cas d’attaque Cybil majeure, reconnue et identifiée, on peut toujours sortir une version de Duniter qui empêchera l’émission des certifications des comptes Cybil identifiés. Ça va Forké, mais si tt le monde installe la nouvelle version, ça peut fonctionner.
Oui c’est pas top niveau maintenabilité… Mais c’est possible.
De toute évidence, le problème de l’attaque récursive apparait si l’attaquant peut créer des nouvelles identités plus rapidement que l’expiration de ses certifications.
En effet, si le temps que l’attaque sybille démarre, la communauté a le temps de se rendre compte de l’attaque, et que par simple arrêt du renouvellement le compte de l’attaquant est expulsé, il n’y a pas d’attaque possible. Je pense donc qu’il n’y a pas besoin de nouveaux documents qui complexifierait le protocole, mais simplement de bien choisir quels paramètres on doit définir autour des documents et règles existantes.
L’attaque Sybill dont profitent les créateurs de monnaie asymétrique dans le système monnaie dette est bien plus grande que celle possible dans une monnaie libre.
Je trouve qu’on discute trop de ce sujet et qu’on se détourne du sujet principal.
Lançons une monnaie libre, ça réduira fortement l’attaque Sybil qu’on connais depuis un moment (~2 000 ans ?).
Est-ce que le coût de créer une attaque Sybil pour créer un second DU est plus grand que de créer des valeurs économiques et de les échanger contre de la monnaie ?
Demander la certification de cinq-six personnes pour deux identités et le risque de se faire une mauvaise réputation vaut-il le coup par rapport à la création de valeurs économiques ?
D’après les simulations que je fait. Je confirme que le meilleur moyen d’endiguer une attaque sybil est de retirer aux comptes sybil le pouvoir de certification.
Je ne me prononcerai pas en revanche sur le retrait du droit d’écrire dans la blockchain, je penche plus vers un non car c’est une perte grave en cas d’erreur de neutralisation d’un membre légitime.
Pour le DU je suis de ton avis, il ne doit pas exister de possibilité de retirer le droit de créer sa part de monnaie.
Au final, une neutralisation, qui se contenterai de retirer le droit de certifier et ceux uniquement pendant le memberShip courant, me parait largement suffisante pour le but rechercher tout en étant pas si grave en cas de neutralisation d’un innocent.
En effet, l’innoncent pourra certifier de nouveau s’il obtient un nouveau membership, alors que le membre sybil n’obtiendra très probablement pas de nouveau membership car les auteurs de l’attaque auront perdu leur statut de membre entre temps.
Bonnes questions. Je n’ai pas la solution, alors je vais émettre quelques propositions sur lesquelles je vous invite à réfléchir :
Pour éviter les abus, nous pouvons limiter le pouvoir de neutraliser un membre aux seuls comptes qui ont plus de 5Q liens entrants par exemple. (5Q=5*siqQty).
Ces membres là pourrait alors émettre des neutralisations, en quantité illimitée, c’est nécessaire pour endiguer une région sybil.
Un membre ne serait neutraliser que s’il reçoit un nombre de neutralisations supérieurs au nombre de certifications qu’il à reçu.
Je propose que la neutralisation n’est pas de durée de vie, mais qu’elle expire seulement quand le membre devient effectivement neutralisé. Et qu’il soit alors neutralisé pour 1 et 1 seul memberShip. Il suffirait par exemple de rajouter un paramètre offSet dans la table memberShip.
Enfin il y a peut être moyen de faire plus simple, d’autres idées ?
@Galuel, comme dit dans l’autre sujets, mais je préfère le dire deux fois qu’une, cette question de neutralisation des membres sybil concerne directement l’intégrité de la WoT et donc le cœur de Duniter.
De plus, il vaut mieux retarder le lancement d’une monnaie libre, que de lancer une monnaie libre qui se fera facilement détruire par les profiteurs de la monnaie-dette.
Au final, nous perdrions peut-être plus de temps à nous relever de l’échec d’une 1ère monnaie trop fragile que de réfléchir sérieusement dés à présent à des mesures de protection efficaces.
C’est beaux de croire autant en la Justice Humaine. Hélas les faits nous montre bien que dans de nombreux cas la justice humaine est loin d’être juste… Et puis même si les auteurs de l’attaque sybil sont condamnés, ça ne nous rendra pas une monnaie détruite !
l’idée des neutralisations n’est pas de punir des membres mais de nous protéger en neutralisant des membres dont ont est a peu près certain qu’ils sont faux.
Je plussois. On est loin d’être certain que la Justice fera correctement son travail, et même si elle le fait, ça ne nous protégera en rien de l’attaque…
C’est une idée intéressante mais qui demanderai pour être efficace une période de renouvellement très très courte, ce qui pénaliserai fortement l’ utilisateur lambda. L’idée de la neutralisation est considérablement plus efficace et n’impacte pas l’utilisateur lambda.
C’est vrai mais inenvisageable. Q attaquants peuvent créer 1 nouveaux faux compte à chaque sigPeriod lors du premier cycle puis au second cycle (S-Q)/Q nouveaux faux comptes par sigPeriod puis au 3ème cycle (S-Q)*S/Q²… bref ça va très vite.
Pour que ton idée fonctionne, Il faudrait des certifications qui expirent en moins de sigPeriod, ce qui est impossible…
Moul c’est hors-sujet. Tu parle ici d’une attaque sybil dont la motivation serait l’enrichissement dans la monnaie, et la effectivement le jeux n’en vaut pas la chandelle.
Non, la vrai question c’est comment se protéger d’une attaque sybil dont la motivation est de tuer la monnaie, c’est très différent !
Et honnêtement j’ai beaucoup de mal a croire que les banques privées vont nous laisser mettre en place une Monnaie Libre sans rien faire. A un moment ou un autre nous subiront des attaques…
Il y a le risque ici de refaire tout ce qui a pu être déjà fait concernant des WoT en général comme ce qui peut exister avec OpenPGP par exemple.
Ce qui pose la question de la séparation entre la gestion de la WoT d’une part, et la gestion de la monnaie d’autre part, au risque sinon de refaire donc ce qui a pu être déjà fait.
@Galuel , oui il est vrai qu’arriver à modulariser/séparer ce qui concerne la WoT de ce qui concerne la monnaie en soit serait l’idéal, mais ce n’est pas le chemin qui à été pris par Duniter jusqu’à présent.
Certes la WoT n’est pas indispensable aux transactions dans la monnaie, mais elle est indispensable à l’obtention du statut de membre donc indispensable à la création de la monnaie.
Ainsi, je ne crois pas qu’il soit possible d’adopter plusieurs formas de WoT différents dans une même monnaie.
Le plus petit dénominateur commun entre TOUT les membres d’une monnaie libre, c’est de se mettre d’accord pour co-produire une valeur. Mais cela implique implicitement de ce mettre d’accord sur ce qu’est “être membre” et “ne pas être membre”, c’est pourquoi je pense que les règles qui régissent la WoT et sont intégrité sont indissociables du cœur de la monnaie.
Les règles de la WoT sont indépendantes de celles de la monnaie. Tout comme pour construire une maison, briques et ciments sont utilisés, mais fabriquer du ciment est un procédé parfaitement différent de la fabrication des briques.
Alors explique moi comment tu peut affirmer qu’un groupe d’individus co-produisent une valeur sans avoir préalablement défini ce groupe d’individus ?
l’exemple est mal choisi, car il ferait croire que monnaie et wot peuvent être deux modules indépendants l’un de l’autres. Or la monnaie dépend de la WoT, l’inverse étant faux.
Une comparaison plus vraisemblable serait de dire que si la Maison est la Monnaie, alors la WoT c’est le terrain. Car sans WoT pas d’individus, et sans individus pas de monnaie. la WoT créer l’espace au sein duquel on peut définir des individus qui co-produisent une monnaie.
La concrétisation d’une 1ère vrai monnaie libre sur support informatique est une 1ère pour dans l’histoire de l’humanité, et génère donc de nouveaux besoins qui n’ont jamais pré-exister. Et pour certains de ces nouveaux besoins, les outils qui y répondent n’existent pas encore ! Nous devons donc les créer a partir de zéro.
Et la WoT de Duniter tel que @cgeek l’a mis en place va totalement dans ce sens de création à partir de zéro d’un outils qui répond à un besoin inexistant auparavant.
Donc oui on doit refaire en partie, puisque l’on s’inspire de l’existant, mais nous n’avons pas vraiment d’autres choix.
Le groupe est défini. Mais sa définition est indépendante de la monnaie. Soit d(x) la définition quelconque du groupe d’individus “x”, et m(y) la définition du type de monnaie y, alors d(x) est indépendant de m(y).
La monnaie instanciée oui, les règles de la monnaie non (l’objet oui, la classe de définition de l’objet non).
On peut définir la maison indépendamment du terrain (sur un logiciel) et la maison peut-être construite sur des terrains indépendants de sa définition, sur l’eau (avec une île flottante), un sol meuble, un sol désertique, la Lune, ou même la poser dans l’espace sans gravité etc.
C’est possible, mais pas certain.
Certainement.
Pour évaluer correctement des choix il faut réaliser une espace de compréhension de dimension supérieure à celui où l’objet est envisagé.
ok, tu à raison. J’ai mélanger objet et instance.
Le fait est que certaines personnes ici souhaitent instancier une 1ère monnaie libre d’ici moins d’1 ans alors que la classe de définition de l’espace économique dans lequel des individus vont co-créer cette 1ère monnaie libre n’est peu être pas abouti.
Dans le cas de Duniter, la WoT est ce qui défini l’espace économique (les individus).
Veut tu dire que nous devrions d’abord réaliser la classe de définition d’une WoT, en réfléchissant dans un espace de compréhension supérieur au contexte de notre 1ère monnaie de prod ?
Je crois que c’est précisément, l’objet de ce topic,
Avant d’instancier la WoT (x) de notre 1ère Monnaie (y), nous devons nous demander si notre classe de définition actuelle de la WoT, tel qu’elle est défini dans le protocole de Duniter est aboutie ou non.
Alors pour revenir à l’objet de ce topic, peut-être qu’il y a d’autres moyens de protection face aux attaques sybil, que de créer un document supplémentaire dans le protocole.
Nous pourrions par exemple prévoir que chaque nœud Duniter possède une blacklist publique de clés publiques (qui sera initialement vide).
Le nœud en question refuserai tout block écrit par une clé publique de cette blacklist ainsi que toute certification émise par une clé publique de cette blacklist. Et c’est tout. Les membres blacklisté pourrons continuer à émettre tout les autres documents du protocole (transactions, etc).
Aujourd’hui, chaque fois qu’un membre lance ou relance son noeud, il se synchronise sur un noeud existant en lequel il à confiance. Nous pourrions procéder de même pour la propagation de cette blacklist.
Il suffirait que une ou deux personnes parmis nous qui ont identifié la région sybil intègrent manuellement les clés publiques correspondantes dans la blacklist de leur nœud membre puis naturellement la blacklist se propagera a tout les nœuds membres qui se synchronises sur nos nœuds membres.
Cela obligerai à un fork géant de la blockchain, il y aurait alors 2 blockchains qui évoluent en parallèle, la blockchain de la communauté légitime et la blockchain de la communauté sybil.
Le seul impact qu’aurais encore l’attaque sybil sur nous c’est d’avoir un poids dans le calcul de la difficulté commune. Est il envisageable de calculer une difficulté commune par branche plutôt que une pour tout le réseau ?
Et si d’aventure, des membres honnêtes se retrouvent blacklisté, les blacklist seront public donc il sauront quels sont les nœuds membres qui les ont blacklister et auront un droit de réponse auprès de ces membres pour faire rectifier l’erreur.
qu’en pensez vous ?
J’aimerais bien ne pas être le seul a proposer des solutions…
Oui effectivement ça ne fonctionne que lorsque la communauté légitime est encore petite et que nous sommes tous à une distance faible les uns des autres. Mon idée ne peut donc nous protéger que d’une attaque qui surviendrai au tout début de la monnaie. S’il y a 5000 noeuds membre, la blacklist ne se propagera pas. Je reviens donc sur l’idée de Cédric, de créer un nouveau document “neutralisation”.