hello.
J’ai fait deux virements samedi soir. Depuis ça m’indique ‘Transactions en cours de traitement’ et je ne reçois plus mon DU.
Ma clé publique : CShdDDHuMr8zT9DV2ChoyDRDJt67bJKGcoxHmJ77MawX
Pseudo : nox
Si tu utilises Cesium, tu peux changer de serveur pour g1.duniter.fr:443. C’est le nœud duniter.org qui était désynchronisé et que l’on est en train de remettre sur pied.
Salut, même souci, des virements effectués Samedi soir, je n’ai plus de trace.
Exemple : Samedi soir 20:57 à Pascale RONCORONI montant de 185 G1 , plus de trace de la transaction
Ton virement a du tomber dans la piscine d’un noeud désynchronisé 
Merci tout est ok. a+
Je ne sais pas comment ça marche exactement, j’ai donné un exemple mais j’ai fait plusieurs virements et j’attends également des virements de Samedi soir, voire hier. Je n’ai plus l’historique, j’espère que rien a été perdu car je ne saurai pas retrouver les personnes à qui je dois des Junes ou qui m’en doivent, les RML ont été intenses :).
De plus ce matin j’ai fait des virements, je me demande maintenant si mon solde est suffisant pour les transactions que j’ai effectué et que je ne retrouve pas.
J’ai essayé deux fois de te faire un virement hier mais il a disparu à chaque fois.
J’attends que la situation se stabilise et je te fais le virement…
Comme quoi, il faut trouver une solution à cette centralisation sur le noeud duniter.org. Cesium pourrait choisir un noeud aléatoire parmis une dizaine de confiance par exemple…
1 Like
C’est une solution.
Il faut également prendre en compte le problème de raréfaction des interfaces BMA.
Tu as probablement raison, c’est ce qui doit limiter la propagation des données sur le réseau.
Question bête, mais ça prendrait trop de place de sauvegarder la piscine quelques jours ?
Après écriture, on met le document dans un coin et on ne le supprime que X jours après ? (Ou si plus de place, après c’est chaque nœud qui gère sa politique).
1 Like
En fait c’est déjà le cas. Les documents ne sont supprimés des piscines que quand ils expirent, ou pour une transaction quand elle ne passe pas après plusieurs essais par le nœud.
Et bien sûr tout document écrit en blockchain est retiré des piscines. En cas de rollback à cause d’un fork, les documents sont réintégrés en piscine.
1 Like
C’est ce qui se passe dans le rollback que je ne maitrise pas, dans ma tête j’imaginais un “dépouillement” de la blockchain pour en reconstituer les documents, et donc un processus laborieux.
Y-aurait-il moyen alors de “sauvegarder” les documents encore en stock avant un reset ? De toutes façons s’ils sont là c’est qu’ils ont été émis, donc tenter de les remettre en blockchain ne coûte pas très cher quand c’est ponctuel après un fork. Ca permettrait de limiter les pertes.
@Nartagnan avant de proposer quoi que ce soit il faut comprendre les causes des pertes, dans le présent incident il y en a deux :
- Le fait que les documents soient dater par les clients au temps du bloc courant, alors que le block courant peut très bien être supprimé par un roll back, et le document de venir donc invalide, il ne pourra donc jamais être écrit en blockchain car il n’est plus valide, et il n’est pas possible de le rerendre valide car il est signé cryptographiquement, l’utilisateur doit donc réémettre le document…
Solution : que les clietns datent les document qu’il construisent a t moins 3 jours.
- Le fait que le nœud G1.duniter.org soit trop utilisé et les autres noeuds pas assez, dés que ce noeud a un problème, tout ce qu’il n’a pas pu synchronisé avec le reste du réseau se retrouve perdu.
Solution : Dans Cesium sélectionner un nœud au hasard parmi un pool de nœuds. (Sakia ne souffre pas de ce problème car il envoi les documents a plusieurs nœuds, enfin je crois).
EDIT : Donc in finé il n’y a rien a faire coté Duniter (outre corriger le bug qui a empêcher de roll back). C’est coté clients que se trouvent les solutions.
Il me semble que @kimamila avait fait en sorte que Cesium envoie les documents sur tous les forks détectés par l’application. Ca me semblait être une approche correcte.
Si c’est vrai alors toutes les pertes sont uniquement du au cas 1, ça tombe bien c’est facile a résoudre coté clients 
Oui, mais pourquoi donc aucun des forks n’a pu accepter les docs perdus ? Même si l’idée que tu proposes est intéressante et simple à mettre en oeuvre, je ne vois pas en quoi le cas 1 aurait fait disparaitre des documents.
Ça ne les fais pas disparaître ça les rend invalide, mais coté utilisateur c’est perçu comme une disparition donc c’est pareil
Pourtant si un doc A est envoyé sur 2 forks F1 et F2. Si le noeud sur F1 rollback sur F2, en quoi le doc A disparait du noeud ?
Je ne sais pas comment @kimamila gère ça, peut être que Cesium n’a perçu qu’une seule branche, peut être qu’il percevait bien les 2 mais que le document a été envoyer sous une seule version (avec un seul et même blockstamp), tant qu’on en sais pas comment c’est gérer coté Cesium on ne peut rien conclure !
1 Like
Salut je n’ai toujours pas de trace des virements que j’ai effectué Samedi soir, est-ce perdu ? Dois je les refaire pour ceux dont je me souviens ?
Pour les autres virement je ne sais plus à qui je devais de la June et d’ailleurs il se peut que des virements devaient m’être envoyé durant cette nuit (pas sûr).
Auriez vous avez la possibilité de le voir quelque part ? Est-ce que les virements on été effectués mais je ne les visualise pas ?
Exemple : virement de 185 G1 destiné à Pascale Roncoroni à 20h57 Samedi 26/05.
Pardon de mon insistance… 
1 Like