NTP Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number 123
Celui qui se prend pour un professeur n’a parfois pas les moyen de se rendre compte que celui qu’il considère comme son élève ne l’est pas.
NTP sert pour se mettre d’accord sur l’heure mais n’est pas un système de consensus distribué et sécurisé.
Utiliser ceci ferait une couche extérieure au protocole blockchain, ce qui ajoute de la complexité car il faut gérer un protocole de plus et car il n’est pas spécifiquement conçu pour cette application (donc certaines fonctionnalités peuvent être en trop ou manquer).
C’est probablement pour ça que les blockchains préfèrent gérer ça en interne, ce qui apporte à la synchro du temps les avantages de la crypto de la blockchain.
pardon, mais la blockchain (ou son protocole) est bien encapsulé dans un processus? je ne dis pas qu’il faut implémenter ntp exactement, mais je suis surpris qu’il faille 2 heures de décalage pour rejeter un evenement « trop » dans le « futur ». A cause du temps qu’il faut pour casser les « nonce » et empiler les logs?
Un noeud qui observerait ce temps blockchain ne pourrait-il pas insérer des « bad bloc » cohérents par rapport aux « 24 derniers blocs » et créer du bruit dans le réseau? Ah c’est vrai il doit avoir une clef membre… et se ferait repérer… on arrive au pb des 51%
Oui, tout tient au problème de la majorité, cela dit c’est pareil pour tout ce qui est distribué, anarchique.
Mais pour rester sur le sujet, pour insérer des blocs il doit respecter les hashes, et là on arrive au problème de régulation de la difficulté qui est résolu par ailleurs. À moins que par « bruit » tu ne parles de spam ? Je ne connais pas le détail des antispams de Duniter, mais j’ai le pressentiment que toucher au timestamp n’ajouterait pas une limitation insurmontable.
Après on pourrait imaginer une blockchain « Einstein-proof », fonctionnant dans un environnement temporellement distordu et sans notion de simultanéité. J’ai toutefois peur que le besoin ne s’en fasse pas ressentir avant un certain temps…
La nuisance par le bruit. Communément appelé spam est la façon la plus efficace de faire taire ce qui cause dans le réseau et qu’on ne veut pas entendre parler.
Alors oui. C’est de ça dont je parle… Quelles sont les protection antispam pour bannir un rigolo qui voudrait interférer… La clef qui doit être membre est une bonne protection. Mais ne peut on quand même pas sussurer assez pour irriter sans se faire repérer ?
Pour ralentir un nœud, le plus efficace est de lui faire faire des calculs coûteux, comme vérifier un bloc. D’après ce que j’ai compris, Duniter stocke les hashes des blocs invalides pour ne pas les vérifier plus d’une fois.
Il y a aussi des paramètres de bannissement (IP ou clé publique je ne sais pas) fondés j’imagine sur le temps local, aucun besoin de consensus ici.
Pour plus de détails tu peux regarder si il y a une doc ou alors dans le code (ou même la config ça aide aussi).
@tuxmain
Merci pour ta bienveillante attitude à transmettre l’information. Et de faire l’effort de répondre simplement à mes questions tordues 
Si j’ai le temps… Je trouve, qu’il y a une meilleure entraide et une plus grande créativité dans ScuttleButt …
Oui, c’est sûrement plus fun. Ça a l’air en tous cas.
La monnaie c’est pénible… Mais ne faut-il pas que quelqu’un s’y colle ?
Je n’ai pas très bien compris le soucis que tu te poses (j’avoue ne pas avoir tout lu), mais pour la plupart des soucis de Duniter/G1 il y a des solutions bien connus. Reste à les mettre en place. Le problème, à mon avis, est le manque de développeurs pour les mettre en œuvre. Et comme évoqué ensemble au téléphone, toutes ces évolutions doivent être réaliser sans “casser” le bon fonctionnement en prod, pour conserver la base d’usagers (dont la valeur est en elle-même quelque chose d’important).
Répartir a zéro dans une G2 paraît idéale pour certains, mais ils auront les même soucis dans quelques temps, sur d’autres fonctionnalités toutes aussi importantes.
3 Likes