Transaction envoyées en echec

J’ai voulu faire une Ğrosse transaction de 2000 Ğ1 depuis mon compte membre à mon compte ventes.

Au début, tout se passe bien, je vérifie et mon compte membre est bien débiter de la somme, et au bout d’un moment, la transaction passe en « transaction non exécutée » et quand je clique dessus ça me dis « Transaction envoyées en echec » (depuis AFkAwZzM6i5imTMEyHL4xEJ6p9TNdMbYMyGNEzM1aL6B vers CWo859LBfsTBWDF8CvcyFuWyesBXCgViqMW1pRyoCesW).

Je veux bien de l’aide car cette somme servira à acheté des choses le plus vite possible.

ça devrait aller. dans maxi 3o min rafraichis le noeud duniter pour etre sûre

ça à été. J’ai globalement des question :

Pourquoi il y a des transactions « traitée et non validées » ? Que veut dire ce « validées » ? Par la blockchain ?
Mais même si elle est « non validée », elle apparaît comme faite et on peux utilisé notre argent.
Il y a aussi des transactions « non traitées », c’est quoi la différences entre « non traitées » et « non validées » ?

Jui perdu OSKOUR :slightly_smiling_face: :upside_down_face:

cool en fait il y a trois maniere d’ interagir avec la chaine de blocs, en ne si connectant pas correctement, en si connectant à un instant puis pas à un autre, en s’ y connectant apres un rafraichissement pour etre sure

Les comptes s’y connectes de 3 façon différentes? 1 seule ne serait pas plus efficace ?

c’ est en cours :wink:

Ah oui, dans 40 ans avec la migration dans Substrate :grin:

l’ avantage du client cesium actuel est qu’ il permet une vue d’ ensemble avec une relle interaction. le top ça serait de modérer gchange depuis a clef membre cesium avec les memes identifiants etc c’ était prévu ainsi au début et ça sera peut etre finalisé dans la prochaine mouture si les dev y trouvent un interet

En fait dans les paramètres Césium, tu peux choisir le délais d’incertitude.
En fait tu estime au bout de combien de blocs, un bloc écrit est considéré comme infalsifiable.
Plus un bloc est ancien (suivi par un grand nombre d’autre bloc), plus il est sécurisé, par défaut on estime que 6 blocs est suffisant.
Sachant qu’un bloc est écrit toute les 5mn, si tes paramètres sont réglé sur 6 blocs, ta transaction n’apparaîtra plus « non validé » dans 30mn.

Donc

  • En attente : dans la piscine en attendant qu’elle soit écrite dans un bloc
  • Taitée et non validé : écrite dans un bloc, mais en attente que x blocs (défini par toi et pour toi) soient écrits
  • Dernière transactions validées : écrite dans un bloc et x blocs ont été écrit après.

Si une transaction ne passe pas, c’est peut-être que le nœud sur lequel tu était est désynchronisé.
Et donc le reste de la blockchain n’a pas l’info.

1 « J'aime »

Ok. Et pourqui @nessbyz dit que ça va changer?

Dans la futur version, un bloc sera écrit toutes les 6 secondes, donc l’incertitude qui est réglé sur le nombre de bloc va de facto être moins longue (env 30s).

Après pour le reste, je sais pas trop, j’avoue ne pas comprendre trop son « c’est en cours » et surtout ses « 3 manières d’interagir ».

1 « J'aime »
  1. t’es sur un nœud planté à l’ origine 2. t’ es sur un nœud actif mais qui plante ensuite 3. t’ es sur un nœud stable

parceque les clients duniterV2s ne demanderont plus de se connecter manuellement, ils le feront de façon automatique tel que l’ a suggéré @matograine entre autres

1 « J'aime »

En effet tous ces problèmes d’attentes et de synchronisations seront totalement réglé après la migration Duniter v2s.

En attendant, va falloir continuer de bricoler comme vous faites…

Oui sans compter le fait que grâce aux lightnodes on pourra embarquer des mini noeud Duniter directement dans les clients, donc plus de problèmes de choix de noeuds, chacun sera son propre noeud.

Work in progress

3 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.