Peut être que ta question était “comment le couple fait pour se certifier” ?
Si c’est le cas, il suffit par exemple de crypter l’heure de la réunion avec la clé privé d’un des membres, puis de crypter avec la clé privé de l’autre membre.
Ainsi on peut vérifier avec les clés publiques du couple, que seul ce couple était capable de générer cette certification.
D’accord, mais dans ce cas tout cela me fait penser à :
Comprends-tu ? Si tu pars du principe que tu fais face à des attaquants, alors autant dire qu’ils vont passer complètement à côté de cette “barrière” de réunions vidéo ! L’attaquant aura tout simplement 5 complices et voilà tout.
Sauf à ce que tu “codes” la réunion dans la blockchain, mais comme tu dis c’est extrêmement compliqué.
Ton raisonnement est faux…
Il faut trouver deux groupes distinct A et B de 5 membres que l’on notera A1, …,A5 et B1, …, B5 de sorte que pour tout couple Ai,Bi il n’existe aucun lien de connaissance Ai → Bi ou Bi → Ai.
Sachant que membre M qui doit trouver ces deux groupes doit être connu de chacune des 10 personnes, puisque qu’on parle ici d’un cas de tromperie de la part de M sans complicité de la part des certificateurs.
On a donc 10 liens : 5 liens Ai → M et 5 liens Bi → M.
La probabilité dont il est question dépendra de la taille de la wot, prenons la wot maximale : 1 millions de membre. Supposons que chaque membre connaisse en moyenne 50 autres membres (ce qui est une estimation basse).
Le problème est mathématiquement beaucoup plus compliqué que ce que tu a posé, sachant qu’il faut prendre en compte l’effet de proximité, le moyen le plus simple d’approcher la réponse est de faire des simulations 
Non justement, car ils ne peuvent pas choisir le membre avec lequel ils doivent faire la réunion.
Autrement dit, même si 20% des membres sont corruptibles, ils vont devoir passer 5 vérifications pour chaque faux compte membre qu’ils veulent créer.
Donc en moyenne ils vont devoir le faire 1/0.2^5=3125 fois les 5 réunions, par compte, pour espérer créer un faux compte.
Qui choisi dans ce cas, et comment ?
"En gros voilà techniquement comment je verrais là chose :
Imaginons qu’il y est une réunion le 01/02/2019 à 12h (l’heure et la périodicité des réunions devrait être choisit dans le protocole)
Alors le hash du premier bloque créé après le 01/02/2019 après 10h, va déterminer un “seed”.
Toutes personnes qui fait acte de présence dans la block-chain entre 10h et 11h40, est considéré comme participant à la réunion.
À partir du seed et d’un protocole déterministe, on crée des couples de personnes."
Autrement dit, c’est le hash d’un bloque particulier de la blockchain, déterminé à l’avance par le protocole, qui va faire ce choix.
Je répète : l’attaquant se fiche de la réunion. Il a trouvé 5 membres correctement distants et prêts à le certifier, il devient membre.
Alors, imaginons qu’ils trouvent 5 membres complices.
Ces 5 membres ne peuvent pas le certifier, car seul l’autre membre du couple dont il fait partie lors de chaque réunion le peut.
Il faudrait donc qu’il tombe sur un de ces 5 membres, à chacune des 5 réunions du mois.
Dans mon système, un membre de peut pas en certifier un autre pour une réunion donné, le seul membre qui le peut, c’est celui choisit aléatoirement, par un bloque particulier de la blockchain.
Donc tu veux dire que la notion “couple de réunion” fait partie intégrante de la blockchain ?
Exactement, impossible de choisir avec qui tu vas te retrouver. C’est choisit en fonction des membres qui font acte de présence avant la réunion, et d’un hash de blockchain utilisé comme un seed. C’est ce qui permet la solidité de ce système.
Voilà et ça ce n’est pas bon, ça ne peut pas marcher, outre la complexité technique, il faudrait que les groupes locaux soit super méga rigoureusement bien organisés et que suffisamment de personnes se rendent disponibles aux horaires décidez par al blockchain, et en plus ils seront sanctionner s’il en se rendent pas dispo, un tel système serait très très mal perçu par les utilisateurs finaux, en plus d’être hyper contraignant, en outre c’est vraiment très très dur a coder, qui le ferai alors que déjà nous manquons cruellement de codeurs ?!?
Tu devrait vraiment méditer sur le principe du rasoir d’Ockham :
Ton système est vraiment beaucoup beaucoup trop compliqué pour les utilisateurs finaux …
Je réfléchie à ton contre-argument, et te répond dès que c’est suffisamment clair pour moi.
Cependant si tu as déjà fait les calcules, je les veux bien.
Effectivement, mais cela ne fait que diminuer la probabilité de tomber sur les mauvaises personnes pour un attaquant, car il pourra prendre en compte cette effet de proximité, et choisir des groupes qui ne sont pas proche les uns des autres.
Cependant oui, pourquoi par faire une “simulation”, ça me semble gérable, je peux essayer de faire ça.
j’ai déjà fait des simulations, et @cgeek aussi de son coté, mais je pense effectivement que tu a besoin de faire tes propres simulations pour te rendre compte par toi même que tu sur estime fortement les risques de la wot actuelle :
Je ne suis pas sûr de comprendre ce que tu veux dire, de mon point de vue ça semble assez simple.
Il suffit juste d’avoir l’heure de la création du bloque, dans le bloque lui même.
Si jamais un client duniter crée un bloque avec une heure se situant avant l’heure du dernier bloque, ou après l’heure où il est reçus, il est considéré comme invalide.
À partir du moment où on a une heure approximative dans les bloques, et avec une bonne relation d’ordre, il suffit de choisir les bloques important en fonction de cette heure.
Après ça, ça n’est plus une question de groupe locaux, la blockchain fonctionne à partir d’un fuseau horaire particulier, et c’est ce fuseau horaire qui donne les heures de réunion.
Chaque membre à la responsabilité de participer à une des réunions dans le mois, dont il connaît l’horaire. Si il en loupe une, il peut participer à une des autres.
Donc tu codes bien aussi la notion de réunion, la notion de présence, etc.
Certes, tu peux arriver à un système avec extrêmement peu de sybilles. Mais avec aussi extrêmement peu de membres j’en ai bien peur, vu la complexité induite.
Mais cette idée d’ajouter de l’aléatoire avait déjà été suggérée quand @elois avait rencontré des doctorants je crois, la discussion est cité par @jytou un peu plus haut.
@dionisos a tu déjà contribuer au code d’une crypto-monnaie ?
Si la réponse est non alors c’est normal que cela te paraisse simple.
La réalité c’est que l’Informatique c’est compliqué, et c’est encore plus vrai quand on parle de code. Tu n’imagine pas ce qu’est déjà l’extrême complexité du protocole actuel pour appliquer des règles pourtant bien plus simples que ton système !
Si ton système est “simple” comme tu le prétend alors le protocole actuel l’est encore plus, lie le et si tu le trouve simple on en reparle
https://git.duniter.org/nodes/typescript/duniter/blob/master/doc/Protocol.md
Ok, il va maintenant me falloir un peu plus de temps pour continuer ce débat, particulièrement intéressant.
Je vais dans un premier temps revoir mes calcules, et tenter une simulation, pour vérifier mes dires sur la faiblesse de la tdc actuelle. (car c’est inutile d’aller plus loin si je me trompe sur ce sujet, ou si je n’arrive pas à vous convaincre de ses faiblesses).
Je vous répondrais une fois cela fait, sur ce sujet.
Si il s’avère que je ne me trompe pas, j’essayerais de modifier le protocole actuel, pour y inclure le mien, et ainsi montrer que c’est faisable. (ou au contraire, me rendre compte que ça ne l’est pas, pour une raison que je ne vois pas actuellement)
Ce qu’il faut aussi prendre compte c’est qu’il faut que ces règles soient simplement vérifiables par tout un chaqu’un, sans qu’il n’y ai aucune confiance entre chaqu’un des nœuds du réseau. Le système que tu propose peut être intéressant mais est extrêmement lourd, prendrait beaucoup de place dans la blockchain, demanderais beaucoup de développement, et rendrais la procédure d’entrée dans la toile de confiance beaucoup plus compliquée que ce qu’elle est actuellement, alors que beaucoup de personnes trouvent déjà ce système complexe.
Aussi, vu les problème de scalabilité inhérents aux blockchains, je vois mal ce genre de protocole fonctionner avec des millions d’utilisateurs. On a pour l’instant quelque chose qui reste assez léger (qui pourrait selon moi l’être encore plus, mais ce n’est pas le sujet) et qui peut être utilisé sur des petites machines. On est vraiment bien placé au niveau de la décentralisation, et un système aussi complexe ne pourrait sûrement pas être vérifié par toutes les machines.
Voilà mon premier essaye de simulation
On peut voir que je trouve à peu près la même chose par le calcul, que par empirisme (j’ai testé avec différentes valeurs). Ou au moins, je reste dans les mêmes ordres de grandeur.
Je trouverais ça donc surprenant que je me sois complètement trompé dans les deux cas.
En fait je suis d’accord avec ta manière de modéliser le problème (c’est d’ailleurs la manière dont je l’ai modélisé dans mon programme).
Sauf qu’il me semble que mon calcule reste valide avec cette modélisation.
J’ai choisit 20 connaissances par personne, et 10000 membres, dans ma simulation. (car d’après moi, si il faut demander à plus de 20 personnes à chaque fois qu’on veut certifier quelqu’un, ça devient vraiment fastidieux, même si c’est possible de connaitre plus de 20 personnes).
Cependant avec 50 connaissances et 10000 membres, la probabilité de se faire détecter reste faible. (par calcule et par empirisme).
Ça serait encore plus faible avec 1 million de membres, mais fait ramer mon pc.
Dis moi si tu vois une grosse erreur dans mon programme.
J’ai aussi regardé ta simulation, mais il me semble que ce que tu analyses, ça n’est pas la difficulté de créer un double compte, mais plutôt la difficulté de détruire complètement le système avec une attaque sybil, tu me diras si je me trompe.
@dionisos tu n’a pas compris l’énoncé, tu pioche 2 groupes de 2à personnes au hasard aprmis 10000 et tu regarde sic es 2 groupes ont une intersection, ce qui ne correspond pas au problème posé.
Ce qu’il faut simuler c’est un graphe de toile de confiance a l’instar du module wotb et générer plusieurs toiles aléatoires puis analyser ses toiles puis vérifier combien de membres ont été certifier par deux groupes de certificateurs complétements isolés dans le graphe.
Tu peut faire cette étude avec la wot G1 actuelle et tu te rendra compte que c’est le cas pour zéro membres.
Ensuite 2ème étape : ce placer dans le cas d’une attaque volontaire d’un membre, qui chercherai donc a contacter volontairement 2 groupes de 5 personnes qui ne se connaissent pas entre eux, mais encore faut t’il qu’il connaissent l’attaquant (nous sommes dans une hypothèse sans complicité). Pour simuler cele on pourrait superposer deux graphes : on premier graphe des connaissances sociales puis on deuxième des certifications, ou seulement une faible partie des liens sociaux réels sont certifiés.
Oui c’est exact, et c’est le seule chose qui nous intéresse. Car même avec le système le plus parfait au monde il y aura toujours de la fraude, nous ne cherchons pas a rendre la fraude impossible, juste a la rendre suffisamment marginale pour qu’elle n’est pas d’impact significatif sur la monnaie.
Il y a un autre point essentiel que tu ne prend pas en compte dans tes suppositions sur les risques de la toile : la non omniscience de l’attaquant et la pression sociale.
L’attaquant qui choisirai deux groupes de 5 membres qu’il connait et dont il crois que ces deux groupes non aucun lien entre eux, en réalité il n’en sais rien, il prend un risque énorme, il est fort probable qu’il existe des liens entre ces deux groupes dont il n’a pas connaissance, et comme dit plus haut la plupart des liens sociaux ne sont pas forcément traduit en certifications, donc une analyse de la toile actuelle ne peut pas aider l’attaquant a trancher, dans tout les cas il prend un risque énorme, et s’il est découvert les gens ne voudrons plus le certifier, il perdra la confiance de la communauté sans parler de sa réputation qui vas dégringoler.
S’il y a bien une chose a laquelle sont attaché les humains, plus encore que l’argent : c’est leur place sociale, le fait d’être reconnu par les autres.
Encore un dernier point : 5 certifications ne suffisent pas, l’attaquant vas se voir demander des deux cotés d’émettre ou recevoir de nouvelles certifications au fur et mesure du temps, et donc la probabilité d’une personne face le lien entre les 2 vies et découvre la supercherie tend inexorablement vers 1 a mesure que le temps passe !
