Transaction traitée, non validée

Bonjour,

J’ai fait une transaction, je suis débité mais c’est noté « non validée ».
Faut-il patienter ?

Je ne sais pas sur quel noeud je suis… Y a-t-il un moyen de le savoir ?
Merci

Sh1

Oui, dans le menu paramètres de Cesium.

Une transaction est passée dès qu’elle est dans un bloc. Mais il peut y avoir des « rollback » qui supprime les derniers blocs. C’est pour cela que l’on considère qu’il faut attendre 6 bloc (1/2 heure) pour être certain que la transaction soit validée.

Dans la vue réseau de Cesium on peut observer les blocs et vérifier si la transaction apparaît.

Merci !

Bonjour,

Une transaction pour un règlement qui m’avait été fait, est restée plusieurs jours dans cet état “Transaction traitée, non validée”, puis à fini par disparaître sans laisser aucune trace / preuve, ni dans mon compte, ni dans celui de l’acheteur à l’origine du paiement.

Comment cela peut-il se terminer ainsi, avec des transactions perdues et sans information ?!?
Y a-t-il encore des bugs dans Duniter qui peuvent conduire à ce type de déconvenue ?

Avec quel outil puisse-je retrouver cette transaction dont je connais l’émetteur, le receveur, le montant et la date mais à la minute seulement ?

Merci d’avance.
Christophe

La transaction en question, qui était datée du 08/05/2023 à 12h27 dans mon compte Césium, aurait dû être intégrée au bloc #624799 de 12h27 ou à défaut dans le bloc #624800 de 12:32, mais il n’y en a pas trace.

Comment savoir ce qu’il s’est passé et pourquoi / comment le système a pu faire disparaître celle-ci ?

Les transactions en attente ne sont stockées que dans les “piscines” d’une partie des nœuds. Elles peuvent disparaître sans laisser de trace si elles ne sont pas écrites en blockchain assez vite. Il n’y a alors aucun moyen de les retrouver.

Elle peut être supprimée sur certains nœuds et pas sur d’autres, donc il faut essayer de se connecter au nœud qui a été utilisé pour émettre la transaction. Avec de la chance, elle sera visible “en attente” sur Cesium. Mais rien n’est sûr.

Bonjour tuxmain,

Merci pour les explications.
Cela veut-il dire que des transactions effectuées et visibles dans Césium par les 2 parties (acheteur et vendeur), ne sont pas garanties d’être enregistrées dans le livre de compte (la blockchain) ?!?

J’ai dû mal à croire que c’est possible (acceptable).

Mais même au delà de ceci, la transaction a fini par disparaître purement et simplement de mon compte Césium, comme si de rien n’était.

Cela me fait douter de la confiance qu’il est possible d’accorder à un tel système d’échange, mais comme je suis novice je suppose qu’il y a probablement quelque chose qui m’échappe et qui justifie tout ceci. En attendant, j’ai perdu un paiement et je vais devoir trouver un moyen de retrouver mon acheteur croisé par hasard lors d’un GMarché. :confused:

Oui. Si elles sont “en attente”, il faut qu’un bloc soit écrit par un nœud qui les connaît (puisqu’elles sont répandues dans le réseau entre nœuds qui se connaissent, mais ne font pas objet d’un consensus global). Une fois qu’elles sont écrites et qu’un peu de temps s’est passé (quand Cesium les dit “traitées et validées”), il est quasiment certain qu’elles sont définitives.

Ce problème est compliqué et on n’aura jamais un consensus immédiat et parfait. Il faut savoir que la blockchain n’est pas un livre de comptes central mais distribué et opéré par des dizaines de machines potentiellement adverses qui doivent arriver à un consensus.

Dans la V2 ce sera beaucoup plus rapide (traitement 6s, validation définitive 30s).

Ok, attendons la V2 et en attendant surveillons l’état des transactions pour garder un moyen de contact avec l’autre partie en cas de transaction non validée.

Quelles sont les valeurs en V1 de ces 2 délais ?

@ChristopheG25 merci de témoigner de ce problème… Je suis conscient de son existence et m’y suis heurté quand j’ai programmé l’automate de paiement par SMS (G1SMS)…

Une blockchain est pair à pair et l’établissement d’un consensus n’est pas immédiat. La prochaine version du coeur devrait accélérer cela, en attendant…

Pour y palier, dans les lieux sans connexion, ni équipement informatique, il est possible d’utiliser le G1BILLET… Je termine la mise au point de terminaux qui assurent le paiement entre “G1PASS”… Sorte de “CB avec code PIN” qui commande le terminal pour assurer le paiement. Dans ce cas, celui-ci exécute des scripts pour contrôler la bonne synchronisation avec la blockchain (et réémettre le paiement si besoin)…

1 Like

La blockchain fait en moyenne un bloc toutes les 5 minutes, donc le délai théorique minimal de traitement est d’en moyenne 5 minutes (la plupart du temps entre 3 et 8 minutes). Cependant la propagation des transactions en attente est imparfaite donc ça peut prendre plusieurs blocs.

Une fois que la transaction est traitée il y a le risque d’un fork. Ça arrive de temps en temps, et dans ce cas on peut attendre quelques blocs pour qu’elle soit réécrite dans la nouvelle branche. La plupart des forks durent moins de 2-3 blocs il me semble, donc 20 minutes après l’écriture suffira en général. Duniter n’annulera jamais automatiquement des transactions datant de plus de 100 blocs donc on peut considérer vraiment sûre une transaction de plus de 8h20.

1 Like

Merci à vous, pour vos explications et vos informations.

Dans le cas de ma transaction, le 08/05 nous avions tous du réseau même si le niveau du signal était moyen (2 barres / 4 sur les mobiles). J’avais constaté l’arrivée de ce paiement et son l’état “non validé” sur mon téléphone (la transaction était a l’écart des autres et signalée par un icone rouge), mais sans m’en inquiéter plus que cela. Mes autres transactions, en émission comme en réception, se sont toutes bien passées ce jour là.

Concernant les G1BILLETs ou G1PASSs, cela fonctionne-t-il directement de mobile à mobile via le bluetooth ou par une forme de signature de l’acheteur sur le mobile du vendeur ?

Pour l’instant en l’absence de réseau, nous utilisons des coupons à remplir par les 2 parties, en faisant confiance aux acheteurs.

G1 Coupon GMarché V1.1

Le G1PASS est la copie de l’expérience utilisateur (UX) que nous avons avec la CB.
Il contient le QRCode d’une version chiffrée par PGP des clefs d’un “G1BILLET”… Cela évite de devoir posséder un smartphone… Dans ce cas, un laptop avec webcam se transforme en Terminal de paiement à qui déléguer nos clefs le temps de réaliser l’opération…

Ce n’est pas une application mobile à proprement parler… Il faut plutôt voir cela comme un “ERP” programmable. Il utilise des outils python natools.py créé par @tuxmain et jaklis mis au point par @poka

Cela ajoute des services à Duniter et plus généralement aux clefs cryptographiques utilisées par Cesium et Gchange auxquelles on peut assigner (par conversion et dérivation de clefs) des données stockées sur IPFS.
Cela offre une couche de données parallèle.

Par exemple:

La clef du compte ğchange
7jikBcC2Cd89SGGDuMXNPqyBXn2FeBFY1XnKAQgyAxeA
convertie en “adressage IPFS”, devient : /ipns/k51qzi5uqu5dioeckikst5f8jw1tbljom6acjbw9zerl3671921krs4nm1531r (ou 12D3KooWGZ5uvjmjPXPdr9meXxGiAe42274tfsL1y89LYPqs4uN6 )

On y trouve un “bloc note” TiddlyWiki) (TW) inscrit dans un environnement pair à pair duquel on produit des flux rss et autres données accessibles aux applications qui convertissent et dérivent leurs clefs de façon similaire…

Comme chaque clef peut contenir une application. Pour le cas du G1BILLET, sa clef IPFS jumelle pourrait servir à prendre et archiver la “photo” de celui-ci…