Plus précisément : le code qui vérifie que l’émetteur est membre n’est pas le même selon qu’il s’agit de la génération d’un bloc ou de sa vérification. Celui de la vérification de bloc fonctionne bien, tandis que le code de génération de bloc que tu as corrigé était différent et incorrect.
Petit laïus à ce sujet : on peut voir ici que le code de protocole était bien respecté, ce qui n’a pas empêché un bug critique d’être présent dans le « meta-code » qui enrobe le protocole, ici celui de génération de bloc.
En tout cas @Moul : bien joué pour ta trouvaille et le correctif associé, ainsi que la livraison qui a suivi. Il manque juste un test automatisé pour verrouiller ce comportement. Comme pour @bpresles, je te fais un don personnel de 100 DU car vraiment vous me faites non-seulement gagner un temps que je n’ai même pas, mais en plus vous permettez à la Ğ1 de poursuivre sa route sans moi, et ça j’en suis très heureux
Par contre je vais diminuer les dons la prochaine fois car si vous continuez je vais vite être à sec
Ce n’est certainement pas ta faute, le problème c’est surtout qu’il n’existait pas de test automatisé qui couvrait ce cas. D’ailleurs encore aujourd’hui, il suffit d’un refactoring et ce bug peut se reproduire. Donc, ticket#1354.
Ce n’est pas une bonne raison mais tu en as d’autres.
Ce code est spécifique au bloc zéro. Il est désormais inutile pour la Ğ1, mais nous pouvons le laisser car ce n’est pas non plus du code mort (surtout si demain d’autres veulent lancer leur propre monnaie).
C’est du routing BMA. Quand un nœud reçoit un nouveau document (peu importe son origine, WS2P, BMA, ou le serveur lui-même [cas d’un bloc forgé]), celui-ci le propage à d’autres nœuds BMA. Cette propagation se fait à un maximum de nœuds membres et à quelques nœuds miroir.
Comme au-dessus. On contrôle que l’émetteur est membre pour une certification externe. Majeur. Besoin d’un test (ticket#1355 aussi).
Exactement.
Bien vu et il faut retirer les méthodes appelantes, jusqu’à celle non utilisée de plus haut niveau. Ticket#1356.
Non, il s’agit simplement des adhésions de sortie (OUT) qui auraient pu être enregistrées en piscine si un ancien membre en avait envoyé une. D’ailleurs c’est un cas à tester si ce n’est pas déjà fait. Ticket#1357.
Je suis plutôt pour, en valorisant le ticket avec un niveau afin que le bounty soit fonction de la difficulté / de l’intérêt porté à sa réalisation.
Par exemple il y a des tickets difficiles mais pas prioritaires, et des tickets simples mais à grosse valeur ajoutée comme les tests automatisés verrous.
hier, j’ai téléchargé la desktop 1.7.15 et la synchro à bloqué à 99 % de Apply ( la mise en mode veille auto de ubuntu 18.04.1 y est-elle pour qqc ? )
Aujourd’hui, je télécharge la desktop 1.7.16, pas de synchro proposée, le noeud se met à “fonctionner” mais je ne trouve qu’un seul peer et voici mes logs : http://hastebin.com/ibowuleqal
Est-ce que c’est normal ?
Suis-je connecté au bon peer?
Si cela n’est pas le cas, comment se connecter à d’autres noeuds ?
Il reste une heure et demie à rattraper. Et la difficulté a chuté à 75.
Je pense aussi qu’on a battu le record d’identités dans la fenêtre courante : 49.
J’ai eu le même problème, j’ai supprimé tout les fichiers/dossiers dans duniter_default sauf config.json.
Il a fallut plusieurs tentatives en changeant de nœud avant de réussir à synchroniser complètement.
Persévère !
Oh oh, ca ressemble à un historique sous Silkaj ça !
Allez hop un petit bouton vite fait, pour faciliter les dons à @moul (en passant par son nœud, tant qu’à faire):
Salut @vit !
j’ai effectivement fait ça, c’est une manip indiquée sur l’UI du desktop
et j’ai réussit à synchroniser, mais le réseau ne me reconnait que comme mirroir. enfin, c’est ce que je voit depuis mon client #duniter-desktop …
Ou, sinon c’est les blocs contenants un nouveau membre qui font crier les nœuds (< 1.7.16) qui essayent d’ajouter cette fameuse certification (celle de lacoteau −> SebasC).