Ha pas bête, autoriser de rejoindre un fork seulement si c’est 5 blocs maxi en arrière et 6 blocs ou plus d’avance
(pour notre exemple: si la place de marché a bien attendu 6 blocs, la blockchain ne pourra être réécrite)
mais du coup en cas de split d’internet au bout d’un temps les fork se bloque et ne convergera jamais
donc ajouter une autre condition, par exemple une fois les 5 blocs dépassés,
rejoindre le fork qui contient le plus de noeuds membres.
Ce peut être tout simplement ça l’algorithme : rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre). Aujourd’hui Duniter n’a pas de vision du réseau façon Sakia, mais c’est assez simple à ajouter.
Voilà un algo bien sheep ! 
mais qui semble effectivement répondre au 3 problèmes précédent 
bon il faut quand même que chaque nouveau bloc soit accepté mais ça semble logique ^^
il est vrai que la toile de confiance nous apporte quand même de nombreux avantages.
Ce problème devient également corrigé par la règle: rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre)
cette méthode à l’avantage de trouver un consensus extrêmement rapidement.
Bon il faut quand même ajouter une petite condition en cas d’égalité parfaite, prendre la branche qui a la bockchain la plus longue.
Arrivez-vous à trouver des cas dangereux avec cette méthode?
Je cherche différente attaque possible, mais rien de réellement faisable si il y a un nombre de noeuds conséquent.
mais par sécurité je rajouterais la condition que tu avais préalablement:
Pour éviter un drop complet de la blockchain en local. mais l’attaque semble quand même très compliqué à réaliser pour la propager à l’ensemble du réseau.
Pour l’instant je n’en vois pas, mais il faut quand même trouver un moyen d’obtenir l’état du réseau avec 5.000 nœuds. Ce n’est pas si trivial que ça ! Mais possible, à n’en pas douter.
oui j’imagine…
En plus des contraintes réseau, il va falloir vérifier si chaque nœud est bien membres dans la blockchain.
et Je propose que la réponse de l’état d’un nœud soit signé par la clef privée du noeud, afin de s’assurer que l’on parle bien au bon nœud.
mais on pourrait aller bien plus loin avec ce principe de signature:
il serait possible d’éviter ces 10000 connexions, (5000 inputs, 5000 outputs) pour chacun des noeuds avec un système de cache, je m’explique:
quand on interroge un noeud, celui-ci renvoie toute sa vue qu’il a en cache, avec l’état de chaque noeud, dans l’état de chaque noeud en plus du numéro de bloc, hash, et autres info => on ajoute un timestamp de quand il a été requêté pour la dernière fois.
Le tout signé par la chef privée du nœud correspondant
Dans cette grande liste reçu, si ce timestemp + X min est dépassé pour certains noeuds, alors ont considère que les infos ne sont plus valables et donc on va aller interroger le premier noeud expiré directement.
Celui-ci nous renverra ses infos à jour mais également sa liste complète de l’état des autres noeuds, cette nouvelle liste complète permettra peut-être d’éviter d’aller interroger d’autres noeuds qui avaient également un timestamp +x. Min dépassé, et on continue ainsi jusqu’à obtenir une liste complète des nœud à jours.
Grâce à cela on limite très très fortement les communications entre tt les nœuds.
et comme chaque état d’un nœud est signé par sa clef privé, il n’y a aucun risque de falsification.
j’ai réussi être compréhensible? 
Edit: du coup la vue du réseau par les client (sakia/cesium) devient scalable et donc réellement faisable (ce qui n’était pas le cas pour moi avant)
Oui j’ai bien compris : on demande à un nœud les dernières infos qu’il connaît, ce qui évite de démultiplier les requêtes.
Comme ça, je dirais que le seul point qui me gêne est : que vaut ce “timestamp signé” ? Car c’est sur lui que tout repose. Notamment un nœud peut marquer absolument n’importe quelle valeur, contrairement à un blockstamp (n° de bloc + hash) qui ne peut être qu’une valeur passée. Donc un nœud peut facilement “changer d’avis”.
J’ai besoin d’y réfléchir davantage
pas vraiment car,
si le noeud au moment du requêtage direct, répond un timestamp qui n’est pas proche du timestamp du requêteur, on peut simplement l’ignorer.
maintenant as tu dans duniter une valeur de temps synchroniser entre les nœud? le problème viens probablement de là…
Edit: il est vrais qu’une coalition entre 2 nœud peut permettre d’ajouter dans la grande liste d’etat des noeud sur le noeud 2 un faux timestamp émise par le noeud 1.
mais si un noeud 3 requête le noeud 2 et trouve un valeur future du timestamp du noeud 1 (Temp actuel +X Min) alors il supprime le noeud1 de sa grande liste (et pourquoi pas le nœud 2 par la même occasion ^^)
et si ce faux timestamp est un temps déjà dépassé, le noeud 1 ne gagne qu’a se faire légèrement flooder (et ignoré a chaque fois)
J’ai pensé à la possibilité autre qui serait qu’une ID ayant déjà calculé “2 / nombre de noeuds calculants” en % des x derniers blocs calculés (par exemple l’équivalent de 1 jour de calcul ou 24h00 / 5 minutes par bloc par exemple), devrait attendre qu’ 1/3 des autres noeuds actifs aient calculé “1 / nombre de noeuds calculants” eux-mêmes sur 1 jour glissant, de manière à ce qu’il n’y ait jamais sur 1/3 des noeuds un noeud ayant plus de (1/nombre de noeuds calculants) de blocs calculés sur la dernière période de temps de calcul (1 jour).
Avec 10 noeuds, cela signifie que sur 1 jour glissant, aucun noeud ne devrait aller au delà de 2/10 = 20% des blocs calculés sur les dernières 24 heures.
L’avantage de la POW de la 0.4 est qu’un membre ne peut bloquer la blockchain que 5 min toute les (NB noeud) * 2/3 * 5min
Alors que la technique que tu proposes permet de calculer plusieurs blocs consécutivement, et permet donc un déni de service de la blockchain sur une durée plus longue. (sauf bien sûr s’il y a minimum 576 nœuds ce qui impose 1 bloc maximum par 24h par ID membre)
je suis d’accord que cette nouvelle idée est bien mieux si l’on garde la méthode actuelle de résolution des fork (6 blocs supplémentaires + 30 min), mais semble moins bien que la 0.40 si une autre méthode de consensus plus rapide est mise en place (comme proposé précédemment)
Dans le cas ou l’on garde la méthode actuelle de résolution des fork (6 blocs supplémentaires + 30 min)
cette nouvelle technique facilite également la réécriture d’une chaine à part, plus rapide, pour la publier plus tard, afin de supprimer une transaction préalable. car il y a moins de comptes membres à voler pour générer des blocs consécutifs (dans le cas de la présence de peu de noeuds dans le réseau [< 576] )
La possibilité que j’ai donnée n’est pas forcément une possibilité de remplacement. Elle peut compléter une autre contrainte.
Oui la solution de Galuel peut venir s’ajouter, sans remplacer.
Après, je ne vous cache pas que ma priorité est de revenir à l’algorithme de rotation de la 0.4 pour des raisons de sécurité, et que pour les points :
… on verra tout après le lancement de la monnaie.
Le prestataire n’est pas obligatoirement une banque comme celles que l’on connait. Un gestionnaire de compte comme le -compte nickel- fait parfaitement l’affaire…
Extactement. D’ailleurs est-ce que MAsterCard ou visa sont des banques ?
Haha, it’s ok, Google Translate normally works reasonably well.
Just been extra busy, so had no time to keep up with Duniter lately.
Le protocole en version 0.6 est désormais exploitable. Nous pourrons donc voir dès demain l’impact du retour de l’ancienne règle de difficulté 0.4 (légèrement modifiée toutefois).
A sample on the last 24H:
An interesting thing would be mesure this relatively to the handicap, which is not shown here. Pafzedog issues more blocks than others, but his personal difficulty is also higher.
Suite à notre discussion sur le chat, je reprends les trois points de tortue qui me semblent corrects :
le déni de service lui est réglé par le fait que seuls les membres peuvent miner + le protocole d’exclusion de la 0.40.
la double dépense par l’envoi de 2 TX simultané doit être réglé par un mécanisme de consensus plutôt rapide (et pas 1667 bloc) afin d’être sur que tout le réseau est OK pour dire que ces coins reçus sont bien a moi (6 blocs me semblent bien)
la réécriture d’une chaine à part, plus rapide, pour la publier plus tard, afin de supprimer une transaction préalable, est le gros point noir d’aujourd’hui. Car facilement réalisable avec le piratage de la clef de quelques identités membres, et extrêmement facilité par la preuve de travail personnalisé qui réduit fortement la complexité moyenne de la blockchain.
Et je cite cgeek :
Ce peut être tout simplement ça l’algorithme : rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre). Aujourd’hui Duniter n’a pas de vision du réseau façon Sakia, mais c’est assez simple à ajouter.
Qui d’un algo de la forme suivante :
Dans cette forme, pas besoin de connaître tous le réseau pour observer la majorité : le broadcast de signatures et leur accumulations permet de savoir de manière isolée quel block est majoritaire dans le réseau.
Aujourd’hui quand un nœud change son HEAD, c’est-à-dire quand il reçoit un nouveau bloc qui s’ajoute parfaitement au HEAD actuel, il le propage sur le réseau. On pourrait donc en effet ajouter une signature supplémentaire pour “propager son propre état du HEAD”.
Sauf que cet algorithme, tel quel, risque de provoquer des engorgements réseau comme cité par Tortue dans son post sur les 10.000 connexions.
Pourquoi cela n’arrive pas dès aujourd’hui ? Après tout, chaque nœud propage dores et déjà son HEAD : c’est dû au fait que l’on partage uniquement le HEAD, pas la signature supplémentaire. Et donc quand un nœud a déjà reçu ce nouveau bloc, il refuse une 2ème réception et donc stoppe la 2ème propagation. Tandis que si l’on ajoutait la signature supplémentaire, alors c’est comme si, à chaque nouveau bloc et en imaginant un réseau de 5.000 nœuds, on devait broadcaster 5.000 documents.