Étude d'impact d'attaques Sybil V5 - Stratégie d'attaque plus rapide!

elois · 6 December 2016 20:50

Tableur dernière version (v5) : simu_impact_sybil_v5.ods (11,0 Mo)

EDIT v5: Nouvelle stratégie de propagation des comptes sybil beaucoup plus rapide

tableur version (v4) : simu_impact_sybil_v4.ods (11,1 Mo)

Chers Duniterriens

Je me suis lancer dans des simulations numériques sur tableur de l’impact que pourrais avoir une attaque sybil sur notre 1ère monnaie de prod.

Définition des termes utilisés :
sigQty : nombre de certifications nécessaire pour devenir membre
sigStock : réserve totale de certifications
stepMax : distance maximale aux membres points de contrôle pour être accepter comme membre
stepAttackers : distance des attaquants aux membres points de contrôle

Je me base sur l’hypothèse de sigQty attaquants entrant dans la monnaie légitimement puis co-créer alors le plus de faux comptes possibles le plus rapidement possible !

La formule de calcul de la taille max de la région sybil est :

Démonstration de cette formule ici >> demonstration_formule_sybil.odt (61.9 KB)

Vous pouvez très facilement tester une autre formule, il suffit de modifier la cellule C9 de la feuille params

Prise en compte d’un % de transfert de la masse Monétaire MS vers ML ainsi que d’une possible perte du statut de membre de la part des comptes sybil. + les dates et ampleur des attaques sybil simulés sont désormais réglable directement dans la feuille param.
Tout cela m’a pris du temps et j’ai donc choisi de me concentrer exclusivement sur la formule du DU actuellement implémentée dans Duniter (a savoir DUG2)

Les paramètres que j’ai choisi pour chaque simulations sont indiquer dans le tableau à gauche du graphe.
Pour tester d’autres paramètres, il suffit de modifier les valeurs directement les valeurs du tableau dans la feuille params, toutes les autres feuilles de calcul font directement référence aux valeurs de la feuille params pour les calculs,

Hypothèses de travail :

J’ai fixer un plafond à 1millions de membres, au delà, N cesse de croître et je considère que l’on arrive alors a une situation ou il y a globalement autant d’entrants que de sortants.
Je considère que lors d’une attaque sybil, les membres malveillants vont créer directement le plus de faux comptes possibles jusqu’à ne plus pouvoir en créer (atteinte de stepMax).

Pour chaque simulation, le graphique affiche ce que j’appelle le « % du DU légitime », c’est le rapport (DU/DUL) entre le DU effectivement versé et le DU légitime que je note DUL.
/!\ ATTENTION ce que je nomme DU légitime (DUL) peut avoir deux définitions différentes selon le contexte /!
Définition 1 (lorsque transfert MS->ML vaut zéro, pas de flux de monnaie entre les membres sybil et les membres légitime) :
DU légitime (noté DUL) = c’est le DU qui aurait été perçu s’il n’y avait pas eu d’attaque sybil.
Définition 2 (lorsque transfert MS->ML est strictement positif, flux de monnaie des membres sybil vers les membres légitime) :
DU légitime (noté DUL) = c’est le DU qui serait versé en considérant la masse monétaire moyenne observée dans la communauté légitime (ML/L). Du fait de l’injection de nouvelle monnaie par les membres sybil, la masse monétaire totale en circulation dans la communauté légitime (ML) est plus élevée que s’il n’y avais pas eu d’attaque sybil.

I. Impact de l’année de l’attaque:

Jaune : création de 134850 comptes sybil à 1 ans
Bleu : création de 134850 comptes sybil à 3 ans
Orange : création de 134850 comptes sybil à 10 ans
Vert : création de 134850 comptes sybil à 35 ans
Marron : création de 13.485.000 comptes sybil à 35 ans (100 fois plus !)
Dans cette simulation le plafond du million de membres légitimes est atteint à 33ans.
Les attaque sybil sur une communauté encore en croissance se décompose en 4 phases :
phase 1 : augmentation soudaine de N donc baisse de M/N donc ralentissement soudain de la croissance du DU, d’ou le petit creux vers le bas des courbes bleu et oranges (jaune aussi mais on ne le vois pas avec cette échelle).
phase 2 : les membres sybil génèrent leur DU, leur nombre étant considérable ils augmente fortement la masse monétaire totale M, donc forte croissance de M/N, donc forte croissance du DU versé. (du fond du petit creux jusqu’à la « pente » maximale des courbes)
phase 3 : le ratio DU/DUL est proportionnel à (ML) / (NML) or la forte croissante des membres légitimes fait que L devient proche de N donc le ratio DU/DUL devient proche de M/ML. ML commence à augmenter plus vite que M, donc la croissance du ratio DU/DUL ralentie.
phase 4 : Stabilisation. L et N ne variant plus, le rapport M/ML finit par se stabiliser à une valeur fixe.

Les attaques sybil sur une communauté à N stable (à 35 ans) ne comporte que 2 phases. Baisse du DU du fait de l’augmentation soudaine de N par l’attaque puis stabilisation.

Ce qu’il faut retenir, c’est que plus la communauté est importante au moment de l’attaque, plus l’impact de l’attaque est faible. C’est donc au lancement qu’une monnaie est plus fragile.

II. Simulation de l’effet du taux de croissance (attaque à t=2ans) :

Jaune : taux de croissance des membres légitimes de 50%/ans (x1,5 chaque année).
Bleu : taux de croissance de 100%/ans (x2 chaque année).
Orange : taux de croissance de 150%/ans (x2,5 chaque année).
Vert : taux de croissance de 200%/ans (x3 chaque année).

On vois bien que plus la communauté légitime croît rapidement, plus l’impact de l’attaque sybil sur le DU est faible.

III. Impact du reversement dans la communauté légitime de toute la monnaie créée par les comptes sybil (MS->ML) :
_Attaque sybil de 134850 faux comptes à t=1ans.
Paramètre variant : taux de croissance des membres légitimes :
1,3/jaune, 1,5/bleu, 2/orange, 2,5/vert, 3/marron

Une bonne stratégie pour des membres malveillants souhaitant détruire la monnaie, serait de reverser dans la communauté légitime toute la monnaie créer par les DU des comptes sybil.
Ainsi, la croissance soudaine de ML (Masse monétaire en circulation dans la communauté Légitime) va augmenter brutalement ML/L donc DUL donc chute vertigineuse du rapport DU/DUL.
Expliqué autrement, la masse monétaire moyenne des membres légitimes ML/L sera beaucoup plus élevée que la masse monétaire moyenne M/N donc le DU effectivement versé à tous paraîtra bien plus faible (4 à 10 fois plus faible). Il y aura alors une forte asymétrie spaciale entre les individus riches proches de la source monétaire (qui est issue des DU perçu par les membres sybil) et tout les autres membres loin de cette source.

Sur ce graphique j’ai émis l’hypothèse que les membres sybil restent membre pendant les 120 ans… Dans la réalité, on peut raisonnablement supposé que les auteurs de l’attaque seront démasques et ne seront plus certifiés, et qu’ainsi les comptes sybil perdrons la qualité de membre au bout de quelques années.

Testons ce scénario (avec les mêmes paramètres que précedemment) :
on suppose que tout les membres sybil perdent le statut de membre ) à t=3ans (2ans après l’attaque). taux de croissance des membres légitimes : 1,3/jaune, 1,5/bleu, 2/orange, 2,5/vert, 3/marron

etude_impact_sybil_simu5_reversement_ms_dans_ml.png1206×672 70.2 KB

Que se passe t’il à t=3ans ? Les membres sybil perdent le statut de membre, la source monétaire asymétrique ne produit plus. le DU versé remonte très vite vers le DU légitime, il faut quand même plusieurs décennies pour que la situation revienne à la normale (et tout ça pour 1 seule attaque sybil !).
J’espère qu’un telle attaque ne se produira pas, mais c’est théoriquement possible.
Sous réserve que les calculs soient justes (il y a peut etre encore des errreurs qui trainent), il semblerait que les paramètres stepMax=6,sigQty=5 soient effectivement trop « souples ».

Téléchargez le tableur et testez donc avec d’autres paramètres monétaires

Ma motivation première est de vérifier quel sont les paramètres monétaires qui résistent le mieux aux différentes attaques possibles.
Ma motivation seconde est de voir quels sont les réponses possibles de la communauté légitime en terme de comportement collectif.
Je vois notamment 2 comportements collectifs possibles en réponse :
Plusieurs membres différents peuvent publier la liste des membres qu’ils pensent être les auteurs de l’attaque sybil, ainsi que la liste des comptes sybil (qu’ils auront trouver en scannant la wot par différents algos) et inciter tout les membres légitimes qu’ils connaissent à :
1/ ne pas/plus certifier ces auteurs présumés. Les auteurs de l’attaque ainsi que leurs comptes sybil finirons par perdre le statuts de membre.
2/ refuser toute transaction émanant des comptes sybil pour limiter le versement MS->ML.

J’ai commencer par simple curiosité, puis une fois lancer je me suis dit autant en faire profiter tout le monde

Ça vaut ce que ça vaut et c’est clairement perfectible, si vous avez des idées sur des hypothèses de travail qui seraient plus pertinentes que celles que j’ai choisi, exprimez-vous.

Des pistes pour aller plus loin ?
Oui
Je n’ai pas étudié l’impact du paramètre xpercent, % de membres pouvant ne pas respecter stepMax ? J’avoue que je ne maîtrise pas bien la définition de ce paramètre, c’est pourquoi je ne l’ai pas étudié.

Inso · 6 December 2016 21:14

Analyse intéressante. Je vais laisser les autres vérifier la validité des mesures mais sur le principe ça me parait cohérent.

A noter une chose importante :

En début de WoT, le facteur limitant les entrées n’est pas stepMax mais sigQty. C’est même en début de WoT que le stepMalveillant peut être le plus faible car tout le monde est très proche des autres
Par contre, en début de WoT, on peut se dire une chose : il faut récupérer des signatures valides auprès d’un petit groupe ou pas mal de monde se connait. C’est ce groupe qui doit être vigilant, c’est uniquement leur sigQty qui jouera sur l’arrivée de personnes malveillantes pouvant profiter d’un stepMalveillant faible.

Après je suis quand même plutôt agréablement surpris de la résistance du DU à ces attaque sybilles une fois les toiles proches de leur stepMax. Dans mes quelques essais, c’est lorsque le stepMalveillant est faible (<= 3) que j’ai pu vraiment tuer la monnaie.

C’est presque contre-intuitif, j’aurais cru que c’est lorsque la toile est trop grande et qu’on ne peut plus faire confiance à la communauté que les attaques sybilles auraient pu être les plus destructrices. Comme quoi… rien ne remplace l’analyse

Autre point qui est très intéressant : une WoT de stepMax 5 résiste beaucoup mieux à une attaque de stepMalveillant <=3 qu’une wot de stepMax 6. Beaucoup mieux d’une échelle de 1 pour 1000 !

cgeek · 6 December 2016 21:35

Je ne comprends pas du tout cette formule.

Déjà le levier de nouveaux membres par membre c’est plutôt sigStock/sigQty, pas sigStock-sigQty. Ensuite je ne vois pas pourquoi tu multiplies par sigStock, et encore moins pourquoi l’exposant contient un “+1” alors que précisément s’agissant de la distance des sybil relativement aux points de contrôle, on est déjà forcément à une distance de 1, et donc on verrait plutôt stepMax-1 (le potentiel de distance), pas +1.

Bref je veux bien quelques explications avant d’étudier les chiffres.

Galuel · 6 December 2016 21:41

C’est bien, bonne approche, c’était le sens de ma remarque sur le calcul du DU. Je n’ai pas vérifié les détails, mais l’intérêt de la démarche et le sens des calculs est pile poil dans ce qu’il convient de réfléchir sur ce sujet.

Il faut en effet comparer deux évolutions avec et sans Sybilles (DU “légitime”), afin de comprendre ce qui se passe.

Remarque : pour mieux comparer tes “impacts”, tu devrais utiliser une échelle entre 50% et 200%, + éventuellement comparer sur un même graphe plusieurs formules possibles du DU en plusieurs couleurs.

elois · 6 December 2016 22:11

ok,

supposons que sigQty complices malveillants se font passer pour des humains de bonne foi et devienne membre en donnant à chacun autant de certifications qu’ils n’ent ont reçu pour devenir membres (par politesse et pour ne pas soulever de doutes dans la communauté avant d’obtenir le statut de membre). Il reste reste donc à chacun complice (sigStock-sigQty) certifications.

Ils peuvent donc créer (sigStock-sigQty) faux comptes. Chacun groupe de sigQty de ces faux comptes pourront à leur tour créer sigStock faux comptes.
Et ce cycle peut se répéter au plus stepMax-stepMalveillants-1 fois.

donc (sigStock-sigQty)*((sigStock/siQty))^(stepMax-stepMalveillants-1)

Pour le +1 c’est une erreur de frappe, j’ai bien fait les calculs avec -1.
En revanche, j’ai effectivement omis de diviser par sigQty, j’ai donc simuler une attaque créaant 21000 faux comptes au lieu de 4350 !

Je viens de corriger les tableurs et les graphes
Après correction, l’impact d’une attaque sybil est effectivement bien moins alarmant que ce j’ai trouver au départ, tant mieux ^^

Galuel · 6 December 2016 22:15

cf ma remarque au dessus sur plusieurs modes de calcul du DU. La formulation DU = cM/N ne convient pas en environnement où N varie, ce n’est même pas la peine de l’envisager…

elois · 7 December 2016 01:41

Ce qui est intuitifs est relatifs a chacun, car au contraire cet aspect là me semble intuitifs là ou beaucoup d’autres aspects ne me le semblent pas.
Plus les membres malveillants sont loin des membres points de contrôle, plus ils sont proches de stepMax donc moins ils ont de “place” dans la toile pour créer des faux comptes.
En revanche, il est vrai que plus stepMax est grand plus les attaques sybilles peuvent êtres destructrices. Pour avoir une bonne vision des choses, je pense qu’il faut dissocier taille de la toile comme contenant (déterminée par les paramètres stepMax et sigQty entre autres) et taille du remplissage de la toile par son contenu N(t).

cgeek · 7 December 2016 07:46

Exact …

Ils peuvent donc créer (sigStock-sigQty) fausses certifications.

Ils peuvent donc créer sigStock/sigQty faux comptes (c’est ce que j’appelle le levier de membres par membre), auxquels il faut en plus retrancher 1 pour pouvoir faire rentrer les sigQty sybilles initiales. Le 1er cercle de sybilles peut donc faire rentrer au mieux (sigStock/sigQty) - 1 faux comptes.

Non, pas sigStock, mais sigStock/sigQty.

En plus, comme je le disais, s’agissant d’une attaque, le cercle initial de sybilles est forcément à une distance de 1 des points de contrôle.

La formule est alors plutôt la suivante :

(sigStock/sigQty-1)*(sigStock/sigQty)^(stepMax - 2 - stepMalveillants)

Ou alors pour une formule plus simple et à peu près équivalente :

(sigStock/sigQty)^(stepMax - 1 - stepMalveillants)

Ce qui donne des résultats encore plus faibles.

Il faudrait aussi que j’aille regarder les fichiers, mais je le ferai plus tard.

elois · 8 December 2016 01:08

@cgeek,
dans mon hypothèse de travail il y a au départ sigQty complices, ce sont des vrais comptes pas des sybil. Simplement ils sont les auteurs de l’attaque sybil.
ils ont chacuns (sigStock-sigQty) certifications une fois devenus membres.
Mais comme ils sont sigQty individus, ils ont au total (sigStock-sigQty)^sigQty certifications.
Il peuvent donc immédiatement créer (sigStock-sigQty) faux comptes à un pas de 1 d’eux.

Prenons un exemple concret avec sigQty=3 et sigStock=12 :
3 complices malveillants rentrent chacun dans la monnaie normalement en consommant 3 certifications. Ils leur reste à chacun 9 certifications sur 12. L’un d’eux créer 9 identités et certifie chacune de ces 9 identités. Les 2 autres complices certifient également ces 9 identités, qui obtiennent alors chacune les 3 certifications requises. Les 3 complices de départ ont donc bien créer 9 comptes sybil dés le 1er cycle.
Dans le second cycle, chaque des trois groupes de 3 sybil pourra faire de même, d’ou :
Nombre de Sybil au cycle 1 = (12-3)
Nombre de Sybil créer au cycle 2 = ((12-3)/3)12
Nombre de Sybil créer au cycle 3 = (((12-3)/3) * 12 / 3 * 12 = (12-3)(12/3)^2
Nombre de Sybil créer au cycle n = (12-3)*(12/3)^(n-1)

En remplaçant 12 par sigStock et 3 par siqQty ont à bien :
(sigStock-sigQty)(sigStock/sigQty)^(n-1)
Or, le nombre de cycle n correspond au nombre de pas entre la position des complices auteur de l’attaque et stepMax, d’ou n=stepMax-stepMalveillants, d’ou la formule :
(sigStock-sigQty)(sigStock/siqQty)^(stepMax-stepMalveillants-1)

Ceci dit j 'ai oublier de compter les comptes sybil créer sur les cycles précédents

La formule complète est donc :
Nombre de sybil créer au total = (sigStock-sigQty)*[(sigStock/ sigQty)+(sigStock/ sigQty)^2+…+(sigStock/ sigQty)^(n-1)]
(avec n=stepMax-stepMalveillants)

Que l’on peut réécrire ainsi :
(sigStock-sigQty)*[(1-(sigStock/ sigQty)^(stepMax-stepMalveillants))/(1-(sigStock/ sigQty))-1]

Ce qui va donner des résultats plus élevés que mes simulations actuelles !!
EDIT : en fait la différence est faible. Dans ma simulation, j’obtiens 134850 comptes sybil au lieu de 130500.

Ceci dit j’ai aussi intégrer ta formule dans le tableur (cellule C31), tu à juste a faire un copier/coller dans la cellule C9 pour l’appliquée

cgeek · 8 December 2016 08:17

OK, il faut en effet sigQty complices pour démarrer l’attaque.

Je pense qu’il y a une typo ici : c’est plutôt (sigStock-sigQty)*sigQty.

C’est bizarre comme raisonnement, pourquoi n’as-tu pas plutôt écrit (12-3)*(12-3), par symétrie de la situation au cycle 1 ?

Avec sigQty attaquants, il y a au plus (sigStock-sigQty)^(n-1) sybils.

Bon sinon, je refais mon raisonnement différemment pour être plus clair.

Chaque membre, sybil ou pas, et peu importe qu’il se coordonne avec d’autres membres, ne peut individuellement faire entrer que sigStock/sigQty autres membres (en admettant qu’il n’existe pas de règle « un membre ne peut recevoir plusieurs certifications du même membre » l’empêchant de le faire; ce qui simplifie le cas).

Et donc considérons les sybil créés à partir de ce membre : il y en a au plus (sigStock/sigQty)^stepMax.

Le fait qu’il y ai sigQty attaquants fait que :

On doit ajouter un facteur sigQty au début de formule
On doit retrancher 1 au stepMax étant donné que les sigQty attaquants implique déjà la consommation d’une step

La formule max est alors : sigQty*(sigStock/sigQty)^(stepMax-1)

Dans la simulation (je viens de regarder les chiffres), étant donné stepMalveillants (que j’avais mal compris dans ma formule plus haut où j’introduisais un “-2”), cela donne au plus :

sigStock = 150, sigQty = 5, stepMax = 6, stepMalveillants = 3
sigQty*(sigStock/sigQty)^(stepMax-1-stepMalveillants) = 4500

On est très très loin des 130.000 comptes annoncés (et loin aussi des 850 de ma formule avec n-2) … toutefois on peut atteindre ce nombre avec des stepMalveillants réduits :

stepMalveillants = 5 : nombre de sybils max = 5
stepMalveillants = 4 : nombre de sybils max = 150
stepMalveillants = 3 : nombre de sybils max = 4.500
stepMalveillants = 2 : nombre de sybils max = 135.000 (tiens, le voilà)
stepMalveillants = 1 : nombre de sybils max = 4.050.000

Donc il me semble bien que les formules actuelles présentes dans les fichiers de simulation ne reflètent pas la réalité possible, et que la potentielle intrusion est grandement surestimée.

Commentaire :

Le cas stepMalveillants = 1: peu probable, car il correspond au cas où sigQty membres initiaux directement certifiés étaient juste là pour torpiller la monnaie. A ce stade, il est possible de rapidement recréer une monnaie sans ces membres.
Le cas stepMalveillants = 2: probable en phase de lancement si l’on certifie n’importe qui, dont des personnes malveillantes.
Les autres cas : étant donné les conclusions pour 130.000, je me dis qu’on est plutôt tranquilles.

Sachant que je ne sais pas si la simulation tiens compte du fait qu’un membre doit attendre un délai sigPeriod entre chaque certification qu’il émet, et donc par exemple pour sigPeriod = 1 semaine, on est pas loin des 3 ans pour réaliser l’attaque complète, ce qui n’est pas anondin.

En plus, rien n’empêche les membres de configurer leur nœud pour refuser d’intégrer les certifications venant de tel ou tel membre, on peut donc ralentir l’attaque dès qu’elle est détectée, voire même la stopper à moyenne échéance.

En tous les cas, je vais étudier les fichiers plus en détails dans … quelques jours ! Mais merci pour ce travail quand même, ça permet de se faire une idée précise d’impact d’attaque.

elois · 8 December 2016 23:43

@cgeek, je persiste et signe tu fait erreur !

ta formule,

est fausse… tout autant que les 3 autres formules que tu m’a donner. Il suffit de prendre un seul contre-exemple pour le constater :

Prenons l’exemple d’une attaque avec les paramètres suivants :
sigStock = 8, sigQty = 2, stepMax = 6, stepMalveillants = 3

Les 2 attaquants ont chacun 6 certifications en stock au lancement de l’attaque, donc 12 certifications à eux deux.
Ils peuvent donc créer et certifier 6 comptes sybil. Ces 6 comptes sybil ont alors tous encore toutes leurs certifications (8).
Chacun des 3 groupes de 2 comptes sybil peut donc de la même manière créer 8 comptes sybil.
Comme il y a 3 groupes, ils créer alors au total 3*8 =24 comptes sybil.

Chacun des 12 groupes de 2 comptes sybil font de mêmes. Chaque groupe créer 8 comptes sybil. Ils créer donc au total 12*8 = 96 comptes sybil.
STOP, nousa vons atteint stepMax.

Au total nous avons 6 + 24 + 96 = 126 comptes sybil.

Ta dernière formule donne 2*(8/2)^(6-1-3) = 2*4^2 = 32.
Tes 3 autres formules donnent respectivement 64, 12 et 36.

Or, j’ai calculer manuellement avec une feuille de papier et un crayon que les 2 attaquants produisent alors 126 comptes sybil, résultat exactement prédit par ma dernière formule (j’ai éditer mon 1er post en y ajoutant la démonstration téléchargeable).

SI j’applique maintenant les paramètres réels avec ma formule :
sigStock = 150, sigQty = 5, stepMax = 6
stepMalveillants = 5 : 145
stepMalveillants = 4 : 4495
stepMalveillants = 3 : 134995
stepMalveillants = 2 : 4.049.995
stepMalveillants = 1 : 121.499.995

J’aimerais vraiment me tromper, mais si j’ai effectivement raison les risques réels sont élevés !
@Galuel qu’en pense tu ? J’aimerais avoir ton avis sur cette affaire

Tu marque un point, et j’y est penser ce matin justement. Je n’a pas encore intégrer le paramètre sigPeriod, il semblerait qu’il soit avec stepMax, l’un des remparts principal contre une attaque sybil. Rien qu’avec un sigPeriod de quelques jours, ça ralenti déjà fortement de déploiement de l’attaque.
Je prévois d’ajouter la prise en compte du paramètre sigPeriod dans le Week-End, j’ai envie d’aller au bout de cette étude et d’avoir une mesure précise de l’impact réel qu’aurais une éventuelle attaque.

Rien n’empêche les membres attaquants et leurs faux comptes sybil de tourner plein de nœuds membres pour écrire eux-même dans la blockchain leurs certifications… Voir pire, refuser d’écrire nos transactions et ainsi perturber fortement le fonctionnement de la monnaie.
Non le seul remède, c’est de retrouver les membres de bonne foi qui ont certifier les attaquants de départ et de faire comprendre a ces membres de bonne foi qu’ils ne doivent pas recertifier ces personnes.
D’où l’importance d’avoir des algos de scan de la WoT qui puissent juger a posteriori si des comptes sont sybil ou pas. Je pense qu’on ne peut pas tout détecter a priori.

Galuel · 9 December 2016 08:16

La WoT doit en effet être surveillée par les membres de la WoT. Toutefois c’est au delà de Duniter comme perspective.

Tortue · 9 December 2016 08:40

Oui, mais quelles sont les actions possibles, après avoir détecté des faux comptes?

Mettre en place une base de données centralisée répertoriant les comptes probablement non légitime?
Dans laquelle les logiciels client iraient piocher avant certification pour prévenir l’utilisateur?
Cela est-il réellement fonctionnel dans le cas d’une attaque sybil?

Ou encore un système de certification pour bannissement?
Cela n’est-il pas dangereux pour les comptes légitimes?

Galuel · 9 December 2016 08:58

Ne pas renouveler les certifications des attaquants, passée leur période en cours, et ceci pendant tout le temps correspondant à la création de faux dividendes, de manière à rétablir la situation.

Tortue · 9 December 2016 09:45

Oui donc, une base de données centralisée gérée par la police de la WOT, répertoriant les membres probablement non légitimes.
Où chaque utilisateur irait consulter avant certification, afin de vérifier la légitimité du compte. (ou réalisé directement par les logiciels client)

C’est triste de passer par là, mais si c’est la seule solution…

cgeek · 9 December 2016 09:52

Pas totalement, lis la suite …

Oui en effet, l’exposant est incorrect. Par exemple si je compte en cycles plutôt que de prendre (stepMax - 1 - stepMalveillants), et que tu as réalisé 3 cycles, j’ai alors : 2*(8/2)^3 = 2*4^3 = 128 comptes sybil.

Donc une 1ère correction consiste à retirer le -1 de la formule : (sigStock/sigQty)^(stepMax-stepMalveillants)

J’ai sorti les miens aussi pour vérifier :

(step 3) 4^3 = 64  **************** **************** ... 
(step 2) 4^2 = 16  **** **** **** ****
(step 1) 4^1 = 4   * * * * 
(step 0) attaquant *

=> 4 + 16 + 64 = 84
=> x2 attaquants = 168

Ce qui montre clairement que ma formule, même corrigée du -1 pour stepMax, est incomplète ! Il me manque l’intégration de chaque palier (que tu as par ailleurs déjà réalisée plus haut).

Allez, une dernière pour la route :

sigQty*[ (sigStock/sigQty)^(stepMax-stepMalveillants) + … + (sigStock/sigQty)^1 ]

Je retrouve exactement les mêmes valeurs que ton tableau @elois, à sigQty près. Par contre les 126 sybils faites au crayon, ça m’a l’air faux. C’est peut-être lié au fait que tu retires sigQty certifications aux attaquants, ce que je ne trouve d’ailleurs pas justifié.

Certes, mais ça ne dit pas ce que c’est que “plein de nœuds”. Par exemple 30 paraît beaucoup devant 50 mais ça l’est moins devant 5.000.[quote=“elois, post:12, topic:1495”]
Non le seul remède, c’est de retrouver les membres de bonne foi qui ont certifier les attaquants de départ et de faire comprendre a ces membres de bonne foi qu’ils ne doivent pas recertifier ces personnes.
[/quote]

Cela me gêne, car on utilise là les certifications non plus comme un moyen de dire “cet individu est bien un humain vivant”, mais de dire “j’ai confiance dans le fait qu’il n’agira pas comme ceci ou comme cela”.

C’est justement une chose que je veux éviter. Alors, peut-être manque-t-il un étage à la fusée Duniter …

Galuel · 9 December 2016 10:03

Mais le fait de participer à une monnaie libre est une liberté. Or une liberté est un principe symétrique. Il ne s’agit pas de dire “ce compte est lié à un être humain vivant” c’est insuffisant, mais de dire “ce compte est lié à un être humain vivant qui accepte de participer d’une monnaie libre”. Créer de faux comptes est bien une rupture de contrat.

Certifier des êtres humains qui n’acceptent pas de coproduire la monnaie libre n’est ainsi pas correct. Une monnaie libre ne s’impose pas.

Galuel · 9 December 2016 10:07

Non, pas centralisée, pourquoi centralisée !? Il n’existe pas d’algorithme d’aide à la décision qui soit unique, et chaque membre de la WoT peut analyser la WoT comme il l’entend, sans centre nulle part.

Tortue · 9 December 2016 10:22

Oui, bien sûr il peut en avoir plusieurs, comme les RBL pour les mails de spam.
Mais chaque liste RBL est centralisée, voilà pourquoi j’ai utilisé ce terme.

Où alors il faut directement ajouter les algo de détection dans les logiciels client.
Lourd et probablement moins efficace.

Mais ce n’est pas Madame Michu qui va contrôler la WOT toute seule dans son coin.

Galuel · 9 December 2016 10:37

Mais une fois une monnaie libre en production, le fait de proposer des services qui permettent d’aborder tel ou tel aspect selon telle ou telle croyance de sécurité reste tout à fait possible.

Inclure dans le noyau tout ce qui n’est pas le noyau ne fait que compliquer l’approche pour de très mauvaises raisons et repousser toute application à des dates ultérieures indéfinies. Le noyau d’un système quel qu’il soit doit rester le plus simple et le plus fondamental possible, permettant son exécution de base. Tout enrichissement sur la base du noyau n’a pas à être intégré par lui.