Si justement ! Quand tu pars de R et que tu remontes ton fork à R+1, R+2, R+3, …, la fenêtre se déplace avec. Et donc par exemple si j’ai deux chaînes A et B avec pour numéro de point de fork R (donc A(R+0) = B(R+0)), alors je peux très bien avoir A(R+2).issuersCount > B(R+2).issuersCount, si à A(R+1) j’ai eu un nouvel auteur tandis que je n’en ai pas eu B(R+1).
Ce ne t’est peut-être pas utile dans ton algo, pourtant il me semble que ce champ donne une information intéressante en cas de fork.
oui effectivement c’est intéressant, peut être que cette information pourrait être utilisée pour départager certains cas en complément du nombre brut d’issuers différents sur la plage R+1:H, qui doit cependant selon moi rester le critère “colonne vertébrale”. Mais qu’a cela ne tienne, prouvez moi que j’ai tord, c’est comme ça que je m’améliore 
Bon maintenant que ces points sont éclaircis, d’autres :
Oui, le coup du “si on est exclu” montre une porte de sortie possible qu’on peut tout de suite suivre, de façon à calculer sur les 2 branches et donc toujours participer. Néanmoins on aura quand même priorisé sa propre branche.
J’avais mis 100 afin d’être bien au-dessus des 6 blocs de fork communément admis. Mais je n’ai pas d’avis précis sur la question.
Pourquoi pas, pourtant on pourrait profiter d’un effet d’inertie : déjà ici tu compares O(R+1:Ho) et F(R+1:Hf) entre elles, alors pourquoi pas aussi mettre ces parties en perspective du passé ? On pourrait ainsi détecter une attaque de nouveaux auteurs par exemple.
Aussi une propriété intéressante à laquelle je viens de penser : si des attaquants calculent seuls dans leur coin, un effet direct est de faire diminuer le champ issuersCount des blocs qu’ils produisent, en effet des auteurs « sortent » de la fenêtre d’auteurs puisqu’ils ne calculent plus sur cette branche pendant l’attaque. Ce peut être un moyen de détecter des forks “frauduleux”.
Autre effet d’inertie combiné à cette règle : du fait de l’exclusion d’un tiers des auteurs par la difficulté personnalisée, alors au moment de la détection du fork seul le tiers exclu du calcul va réellement switcher sur F, tandis que la majorité (les 2/3) reste sur O.
Faut que j’y réfléchisse encore, mais ça me paraît être une bonne règle ce que tu viens d’énoncer là.
Oui ça me paraît être un bon principe.
Tu sais, je n’ai pas écrit l’algo “3-3” comme une solution très long terme. C’est surtout pour nous aider dans ce début de monnaie où les forks étaient vraiment pénibles !
Mais j’espère bien que d’autres, comme tu le fais, vont trouver des solutions de plus long terme je ne demande que ça.
Oui ça me paraît important aussi. Si l’on peut faire sans vue réseau, je préférerais ce type de solution.
pour les clients, il faudrait utiliser plutot des blocs précédents, c’est ca ?
Je n’ai aucun pb avec ca, sauf pour un truc tout con: l’heure des TX (certif, etc.)… qui pourrait dérouter les utilisateurs.
A moins de trouver un principe de redressement de l’heure…
Non je pense que pour les clients ça ne pose pas de problème particulier, c’est vraiment du point de vue résolution de fork coté duniter que cette donné n’est pas fiable. Pour les clients elles l’est, l’avantage des clients c’est qu’il n’ont pas besoin de “choisir” une branche, il peuvent envoyer leurs documents sur plusieurs branches donc ce n’est pas génant de faire avec les head 
Ah oui pour le blockstamp d’un document ? Mieux vaut regarder 6 blocs en arrière quoi qu’il arrive. Car déjà aujourd’hui il arrive d’y avoir un fork à 3 blocs, au moins en en prenant 6 tu évites à l’utilisateur une fausse date d’identité / certif / adhésion. Car c’est pénible de voir son document invalidé.
Peut-être que mettre comme intitulé « horaire de référence » éviterait d’induire en erreur. Et quand une transaction est écrite, mettre « heure d’écriture ». Mais si tu comptes vraiment mettre l’heure d’émission, ça ne peut pas être une donnée blockchain.
Cela ne risque t’il pas de bloquer les petit calculateur tel que des Raspberry pi, pour résoudre un fork, quand à terme il y aura une plus grande difficulté pour trouver une solution de la POW min?
De toute façon quel que soit l’algo il y a aura toujours des effets moins désirables quelque part mais clairement si je met dans la balance d’un coté la stabilité du réseau et de l’autre la relative “facilité” de calcul d’un raspi, je penche sans hésiter pour la stabilité du réseau
De plus, il est possible de modifier les formules de calcul de la diff. perso pour atténuer ce point
Et plus globalement c’est un point noir de plus pour la pow, et je pense de plus en plus que nous devrions nous fixer comme objectif à terme d’abandonner la pow.
EDIT : En fait ce ne sera même pas un problème car je n’applique cette condition que lorsque le rolling back est inférieur à 6 blocs, dés que la branche O a 6 blocks d’avance par rapport au point de fork cette condition ne s’applique plus donc les raspi ne resterons pas coincés longtemps
c’est là que j’ai dû louper quelque chose, un regroupement de 6 membres pirates qui n’a pas calculé de bloc depuis longtemps semble très bien pouvoir réaliser l’attaque sans grandes difficultés.
quelle attaque ? Et pourquoi de 6 personnes ?
Nous forcer a forker sur leur branche qui part de 6 blocs en arrière par rapport au bloc courant ?
Faut qu’il la lance pile au bon moment leur attaque car a seulement 6 la branche principale aura tout autant d’auteurs sauf si un même auteur apparaît deux fois dans les 6 derniers bloc de la branche principale ce que le mécanisme d’exclusion de la diff. perso rend impossible.
Bref ce cas d’attaque sera dans la pratique très difficile a réaliser, ceci étant je vais tout de même intégré dans mon algo l’idée de cgeek qui permet de s’en prémunir :
Sinon moi je peux carrément inscrire dans le protocole un truc pour empêcher des nouveaux auteurs de se succéder par exemple.
Bon après réflexion l’algo du nombre d’écrivains est plus adapté à un contexte sans pow avec pop.
Pour un contexte avec pow un algo basé sur issuersCount me semble finalement plus approprié.
@cgeek j’ai repris ton algo « 3-3 » et j’en ai fait une nouvelle version que je nomme « issuersCount 3-3 » je la poste sur quel thread ?
Dans un nouveau du même nom que ton algo, puis tu peux mettre un lien ici.
Catégorie R&D ?
oui exactement, afin de supprimer une transaction précédemment réalisé il y a 6 blocs. mets toi dans le cas d’une plateforme d’échange de monnaie automatisé, afin d’évaluer le risque d’une telle attaque (et la pub qui va avec)
Bon dans notre exemple disons 7 personnes l’histoire d’avoir un bloc de plus (un auteur de plus) que la chaine principale, ce qui permettrait alors de faire forker tout le monde.
c’est sur, ça coute pas cher, et ça complexifie l’attaque car il faut rentrer chaque membre pirate dans les issuers avant de lancer l’attaque, et sans qu’aucun ne soit exclu.
pouvez-vous m’expliquer en vitesse comment est calculée la taille de la fenêtre courante?
merci
En gros : la fenêtre courante est relative à un bloc. A chaque nouveau bloc, si l’émetteur est nouveau, alors au cours des 5 prochains blocs la fenêtre s’agrandira de 1 unité. À l’inverse si un émetteur sort de la fenêtre courante car il n’a émis aucun bloc dans celle-ci, alors au cours des 5 prochains blocs on raccourci la fenêtre de 1 unité.
Ces effets sont cumulatifs.
Pourquoi 5 ? C’est pour laisser à chaque émetteur environ 5 chances d’écrire 1 autre bloc dans la fenêtre courante. Mais c’est un chiffre au pif. Quoi que 1 est trop petit, de même que 20 paraît trop grand et ne fait pas sortir assez rapidement un émetteur qui s’est arrêté.
au top ! Merci
voici quelques contraintes qui pourraient rendre l’attaque également plus difficile:
je ne suis pas très familier avec les temps en blockchain, mais pouvons-nous ajouter une restriction afin que le temps du bloc HEAD d’un fork ne puisse avoir plus de X min d’avance que le temps courant. (car l’attaquant est obligé de faire accélérer la chaine pour que celle-ci soit plus longue de x bloc)
est-il possible également d’ajouter une restriction du type: chaque noeud ne peut (re)transmettre plus de X blocs en moins de Y min a ses voisins (ex: pas plus de 3 blocs toutes les 5 min)
ce qui bloque la possibilité de retransmettre une nouvelle branche de fork pré construite d’un coup.
Oui c’est déjà le cas, l’heure instantanée est bornée : duniter/doc/Protocol.md at master · duniter/duniter · GitHub
Ceci dit la borne autorise une incrémentation de 0 secondes, donc l’accélération temporelle peut être quasi-invisible. C’est gênant selon toi ?
Oui mais je ne vois pas l’intérêt, car que se passerait-il si le X+1 bloc était le plus légitime ?
J’avoue je ne sais pas trop, je cherche à identifier d’autres traces qu’une telle attaque laisserait derrière elle, alors qu’un fonctionnement plus ou moins normal ne provoquerait pas.
Et du coup proposer des pistes pour arriver à les filtrer.