Bonjour tout le monde !
Comme décrit dans le titre des transactions qui ont eu lieux hier lors du Gmarché à Pierrefeu dans le Var n’apparaissent toujours pas sur le compte des personnes intéressées.
Elles ne sont même pas en « transactions en attente » rien, néant…
Même en changeant de noeud dans Césium+ (idem en changeant le noeud duniter) pas de transactions en vue pour certaines personnes.
Elles sont sûr de leur compte car pour l’occasion elles avaient imprimer leur QR Code pour que cela soit plus simple.
Ces dernières semaines, l’affichages des informations dans Césium est vraiment très variable d’une personne à l’autre, suivant le noeud Césium+ utilisé etc.
Cela ne rassure pas du tout les « nouveaux » qui du coup se demandent si les transactions ont bien eu lieux ?
Connais-tu des clés publiques impliquées dans ces transactions ?
Si les QR codes ont été utilisés, ce n’est probablement pas une erreur de destinataire. Ça ne devrait donc pas impliquer Cesium+. Tout dépend des nœuds Duniter utilisés.
Salut @tuxmain Alors si je ne me trompe pas :
EWoBd1uPyZm45RjLqidwmZEsPeWCA6KPszi6W4yihLH3 a effectué hier un virement de 500 Ğ1 à BaiJR8NMfr7p6GmehV4pgqD5vGDrWQ2WdoVtH2cJUVGm.
Ensuite BaiJR8NMfr7p6GmehV4pgqD5vGDrWQ2WdoVtH2cJUVGm a fait un virement de 80 Ğ1 à 4JBKAVKgGCanfgjvuc7dVvfmVn4HER91sUuzYvYmuSo6.
Enfin 4JBKAVKgGCanfgjvuc7dVvfmVn4HER91sUuzYvYmuSo6 a reversé 10 Ğ1 à BaiJR8NMfr7p6GmehV4pgqD5vGDrWQ2WdoVtH2cJUVGm.
Au passage il y a un autre soucis avec le compte de Ann BaiJR8NMfr7p6GmehV4pgqD5vGDrWQ2WdoVtH2cJUVGm Césium affiche 2 identités avec la même clef publique… mais pas tout a fait le même pseudo, par contre les transactions affichées sont les mêmes…
Une personne du coup par contre s’est trompée en certifiant le « mauvais compte » mais quel est le mauvais compte ? Puisque la clef publique est la même…
Du coup pour éviter les ambiguïtés on se fit à la date de création du « bon compte » qui est du mois d’Avril.
Suivant si on change de noeud Duniter, on a pas les mêmes infos concernant cette double identité avec la même clef publique.
Effectivement ces 3 transactions ne sont pas dans la branche principale. Elles ont dû être écrites dans un fork, ou envoyées à un nœud qui s’est déconnecté sans les diffuser ou qui est mal configuré… Elles peuvent donc être refaites sans risque de doublon.
Je ne les ai pas non plus trouvées dans les pools. (j’ai essayé l’adresse BMA /tx/history/<pubkey>/pending je ne suis pas sûr que ce soit ça)
La personne qui s’est créée 2 identités peut choisir laquelle conserver. Elle peut révoquer l’une, mais ce n’est pas nécessaire. La première à obtenir 5 certifications deviendra membre. Certifier la mauvaise n’est pas un problème, tant qu’elle ne sera pas membre la certification ne sera pas écrite, et elle disparaîtra en 2 mois si j’ai bon.
A priori une des personnes me dit que quand elles ont fait les transactions de 80 Ğ1 et 10 Ğ1 il lui semble que toutes les deux étaient sur le noeud Duniter dont le nom contient Normandie…
Ensuite dans l’après-midi quelqu’un leur a dit de basculer sur le noeud de Presles (c’est vrai que quand ça bug un peu, ce noeud paraît stable…)
Bon je ne suis pas certain que l’info t’aide plus, mais bon, je transmets car aujourd’hui j’ai beau cherché, je n’ai pas trouvé de noeud dont le nom contient Normandie…
Ok ok, merci.
Du coup forcément est en train d’en découler une discussion en privé ou des questions se posent…
Notamment en tant que nouvel utilisateur de la monnaie libre, l’expérience n’est pas encourageante… Le fait d’attendre tout un après-midi pour voir si la transaction est validée et finalement devoir recontacter des gens pour répéter l’opération…
Les transactions pour être traitées sont soumises à la « qualité, résilience et état » du noeud utilisé lors de cette transaction.
Si un noeud tombe down pendant la transaction, un autre ne peut-il pas prendre le relais ?
Pour les nouveaux utilisateurs, faut-il obligatoirement les aider à choisir un noeud réputé « Fiable » ?
Etc.
La monnaie sur un compte est découpée par sources. Chaque DU crée une source valant 1 DU. Quand on fait une transaction, on demande d’abord à un nœud la liste de nos sources, pour les additionner et arriver au montant voulu. (comme quand on cherche des pièces dans un porte-monnaie)
Une transaction faite à partir d’un nœud désynchronisé risque donc d’utiliser de vieilles sources qui ont déjà été utilisées, parce que le nœud ne sait pas encore qu’elles l’ont été. Cette transaction pourra donc être valide pour ce nœud, mais invalide pour les autres.
Les nœuds diffusent aux autres nœuds qu’ils connaissent les transactions qu’ils reçoivent. Si un nœud est bien configuré et synchro, il peut s’arrêter après avoir reçu et partagé la transaction, elle pourra quand même être traitée.
Quant au « traité, non validé » sur Cesium, ça signifie que la tx est écrite en blockchain, mais depuis peu de blocs. Le risque qu’il y ait un fork qui supprime cette transaction est donc encore relativement élevé. Cependant en général quand il y a un micro fork, la tx peut être annulée puis réécrite automatiquement sur l’autre branche. La moyenne étant 1 bloc par 5 minutes, et la validation à 6 blocs, ça prend en moyenne 30 minutes. Mais elle est utilisable avant ce délai sans aucun risque.
C’est sûr que c’est pas aussi confortable que VISA, mais ça l’est bien plus que Bitcoin (taxes très élevées et temps d’attente très long).
Pour avoir une vue la plus fiable possible des serveurs « majoritaires » dont le consensus fait foi, je conseille fortement d’utiliser Sakia.
Des trois clients existants, c’est le seul qui soit p2p.
Je ne dis pas que tout un chacun doit utiliser Sakia, mais au moins un organisateur de l’événement, un représentant du collectif local, ou le geek de la bande, pour avoir une liste des serveurs fiables, et donc des transactions rapides et sûres.
Lors des RML de Toulouse, une liste des serveurs fiables étaient affichée sur les murs ! Simple et pratique en cas de soucis dans Cesium.
Je ne suis pas sûr que changer de serveur Cesium+ corrige des problèmes de transaction, mais plutôt des problèmes de profils/pseudonymes disparus ou d’affichage des DUs.
Merci pour cette précision @vit !
Je n’ai jamais utilisé Sakia encore, il faut que je regarde comment ça fonctionne, mais effectivement si cela permet d’avoir une vue de « noeuds fiables » lors d’évènements comme ça c’est très intéressant pour éviter les frustrations des « nouveaux ».
Hier par exemple il était prévu que si des nouveaux sans compte arrivaient de leur proposer de leur ouvrir un compte, de leur mettre quelques Junes dessus et d’essayer d’échanger.
Ce qui a été finalement le cas de 6 personnes ! Autant dire, qu’il vaut mieux éviter que cela bug si nous voulons les voir devenir de fiers utilisateurs(trices) de la monnaie libre ! cette remarque est aussi valable pour des gens qui viennent de rejoindre depuis seulement quelques semaines et qui font leurs premiers échanges.
J’ai eu le même problème hier sur le gmarché de Lodève.
Entre le noeud officiel qui répond trop lentement depuis le bastionnage du serveur (et donc considéré comme down par cesium car timeout) et le noeud fallback qui était désynchro, c’était vraiment de mauvaises conditions
Il est vrai que l’expérience utilisateur qui en résulte est décourageante
Pour limiter le problème, @kimamila il faudrait que la liste officielle des fallback nodes ne contienne que des noeuds très régulièrement surveillées afin de s’assurer qu’ils sont toujours synchro.
En particulier, le noeud normandie-libre géré par @Paidge devrait retiré vu la faible disponibilité de @Paidge pour l’administrer.
@kimamila je ne comprend pas comment fonctionne l’ordre de cette liste, c’est à l’envers ? Pourquoi c’est le noeud normandie-libre qui a été proposé a tout le monde alors qu’il est tout en bas de la liste et que les noeuds en haut de la liste étaient dispos et synchros ?
Dans le ĞMixer, pour à la fois ordonner les nœuds BMA par préférence et répartir la charge, j’ai fait une liste de listes d’adresses. Quand on envoie une requête, on prend une adresse au hasard dans la première liste. Si elle échoue, on recommence. Si toutes ont échoué, on recommence sur la liste suivante.
Il y a aussi le problème que la plupart des nœuds sont très lents pour toute requête BMA même simple, et que certains comme le mien ne répondent jamais à une requête de l’historique des transactions.
(Vivement GVA)