Bonjour à tous . Si j’ai bien compris , la première certification va mourir d’elle-même car elle est défectueuse ( Pas bien compris comment la blockchain peut posséder des exemplaires verreux ?)
Je refais donc une certification pour @Taskede aujourd’hui.
Merci à @gerard94 s’il peut détailler , s’il en a le temps , comment on peut avoir été aiguillé sur un fork qui aboutit à une certification invalide 
1 « J'aime »
Bon , pas très surprenant : je n’ai pas réussi à émettre une deuxième certification. Il va falloir que j’attende la fin des deux mois pour pouvoir certifier @Taskede . Même si ce n’est pas un bug , pour le profane , c’est un obstacle à la certification qui est un peu fâcheux.
On verra donc à la mi-janvier…
1 « J'aime »
J’ai bien vérifié et je ne vois aucune certification de Zap vers Taskede, ni dans la blockchain, ni en attente.
Non, car Cesium la mettrai alors dans les certifications en erreur. @gerard94 : pour rappel, la date des certifications en attente n’est pas présente dans la résponse de l’API BMA /wot/lookup/<pubkey> : Cesium doit donc aller cherche le bloc pour récupérer l’heure, et ce faisant il valide que le bloc est bien valide 
je la vois bien, sur le noeud g1.duniter.fr ou g1.le-sou.org :
Ca peut arriver, lorsque le réseau émet des blocs contradictoire, car les certifications référence un bloc précis. Si le bloc associé devient invalide, la certification aussi.
mais en l’occurrence, ici ce n’est pas le soucis.
Cette certification est donc bloquée en attente depuis le 13 novembre .
Depuis, vers d’autres membres, j’ai émis une certification avec succès le 20 novembre et aujourd’hui même 13 décembre , validée en quelques minutes.
Et sinon c’est possible de certifier sur un fork ou pas? Si ce n’est possible, qu’on arrête de dire « il est possible que tu aie certifié sur un fork ».
1 « J'aime »
Je vois la même chose que @kimamila.
@CM63 On peut émettre une certification sur un nœud parti sur un fork, cela fait partie du fonctionnement normal de la blockchain. Un fork en réalité ne tourne pas sur la blockchain, ce qui est dans la blockchain est gravé dans le marbre. Ce sont des opérations dites « en piscine » qui sont comparées avant validation dans la blockchain. Dans un fork ce n’est pas une opération en particulier qui est rejetée, c’est un block d’opérations émises dans une période donnée. On peut donc avoir émis une opération légitime rejetée parce-que groupée dans un block contenant une autre opération douteuse.
Le rejet d’un block fait donc partie de ce qui assure la fiabilité de la blockchain, et n’est pas forcément lié à une mauvaise manipulation d’un utilisateur en particulier.
Ben oui c’est quand même pas génial, donc il se peut que notre demande de certification ne soit pas acceptée pas parce qu’il est passé sur un fork, mais qu’est-ce qu’on y peut? Le système renvoie quand même que la certification abouti alors que ce n’est pas le cas?
Non le système renvoie que l’opération a échoué. Dans le cas de @zap je pense que le cas est en cours d’investigation. Il y a forcément une explication logique, il suffit de la trouver. Mais comme ce n’est pas forcément une priorité dans les nombreuses issues à résoudre peut être va t’on attendre gentiment que la certification expire afin de la libérer. D’autant plus que taskede est déjà fort bien certifié.
D’ailleurs, il serait peut être bon de poser une issue pour que ca ne tombe pas aux oubliettes.
Ok, ben c’est un peu ce que je voulais dire, si ce n’est pas courant, ce n’est pas urgent, mais il faut quand même pas l’oublier.
Parfaitement. C’est un fonctionnement normal de la blockchain qui assure sa sécurité. Il est toujours possible de créer des blocs litigieux, intentionnellement ou accidentellement, et il faut qu’un consensus puisse se faire entre les nœuds du réseau pour choisir les blocs acceptés par tous. Il y a donc une sorte de système de vote entre nœuds calculants qui permet d’abandonner les blocs litigieux, et c’est ce qu’on appelle un fork. Évidemment, à chaque fois, s’il n’est pas accepté, les données du bloc sont perdues, certifications, adhésions, transactions, etc… Cela se produit régulièrement. C’est pour cela qu’on ne peut pas dire qu’un bloc a été validé tant qu’il n’est pas suivi d’au moins 3 à 6 autres blocs. Plus il y a de blocs après lui, plus il sera difficile de le remplacer par un autre, et donc mieux ses données seront protégées.
1 « J'aime »