Bonsoir/jour,
J’ai des transactions bloquées depuis 5 jours :
Éléments de diagnostic :
BCnd895BnYZZmrVR22y5qUfbZ2FXEZDTrcer4JRNAFsd
Des idées d’où ça pourrait venir ?
Ce script utilise Silkaj en arrière plan.
Silkaj n’est pas été testé pour les transactions en chaîne. Ce problème ne m’étonne pas.
Je dirais qu’actuellement la gestion de sélection des sources de monnaie de SIlkaj n’est pas adaptée à l’enchaînement de tx.
Les transactions se retrouvent avec les mêmes sources et de fait n’entrent pas la chaîne car Duniter a une règle DUBP interdisant ça. Il y a surement d’autres problèmes qu’on ne voit pas du fait de ce dernier.
J’ai déjà expérimenté ça sur la Ğ1-test lors de l’envoi de tx en chaîne. C’est déjà arrivé que ça ne passe pas lors de la rémunération des contributeurs du projet Duniter. Matograine a dû également être confronté à ce problème lors de ses développements.
Une manière de temporairement pallier ce problème et de faire des transactions multi-destinaires avec la gestion de différents montants qui devrait bientôt entrer la branche dev.
Ça me semble un point prioritaire. À ma connaissance, il n’y a pas de ticket à ce sujet. Un début de contribution possible…
Pour régler ça il faudrait prendre en priorité les sources n’étant pas utilisées par les txs en piscine ? Ou plus simplement permettre de faire plusieurs txs d’un coup ?
Aucune idée. Ça me semble des bonnes pistes à suivre.
Surement que la première personne qui creusera ce point pourra répondre à ces questions.
Oui, ou simplement avoir un cache de très courte durée, genre dans .config/silkaj/temp.
Il suffirait d’y mettre les sources, avec un marqueur de consommation.
Lors de l’appel suivant de Silkaj, il pourrait détecter ce cache, et s’il n’est pas périmrée, l’utiliser en excluant les sources commonnées, et puis en le mettant à jour. Un fichier .lock pourrait permettre une lecture/écriture saine du fichier de cache. 
Oui, j’ai évoqué cette solution dans l’issue.
Que signifie “source” dans ce contexte ?
Peut-on amoindrir le problème de notre côté ? Par exemple en augmentant la durée entre chaque transaction ? Ou en changeant de nœud d’une transaction à l’autre ?
Autres questions : au bout de combien de temps les transactions arrêtent-elles d’être en “pending” ? Et à ce moment là que se passe-t-il ? Elles disparaissent ?
Je me confronte à ce soucis depuis un moment…
C’est tout ce que j’ai pu réussir à faire, tirer au hasard un noeud BMA astroport/duniter_getnode.sh at master - astroport - P2Git pour y égrainer mes TX le plus lentement possible… Bon c’est grâce à cette contrainte que je me suis tourné vers ipfs
gratitude si vous arrivez à améliorer ce point
Une source est une quantité de Ğ1 appartenant à une clé publique. Chaque DU créé correspond à une source supplémentaire sur ton compte, d’une valeur d’un DU. Une transaction consomme des sources pour en créer ailleurs. C’est comme si, possédant 3 billets de 10 UNL, pour envoyer 25 UNL à quelqu’un tu brûlais tes 3 billets pour en imprimer un de 25 à envoyer, et un de 5 à garder.
Or, chaque source a un identifiant unique, et c’est par cet identifiant qu’une transaction spécifie les sources qu’elle utilise.
Changer de nœud n’y changera rien : les deux transactions consommant la même source, elles sont de toute façon incompatibles dans une même blockchain. Et oui la solution la plus simple sans recoder un client pour l’instant est d’attendre que la transaction précédente soit validée avant d’en créer une autre.
Je ne sais pas comment Duniter nettoie sa mempool, mais un jour il décide de la supprimer et elle disparaît effectivement (des nœuds qui la suppriment, mais chaque nœud a une mempool différente).
Tu allais attendre jusqu’à quand pour remonter ce problème majeur au projet Silkaj ? Il faut le dire quand quelque chose ne va pas. Ça aide beaucoup le projet. On se rend compte souvent qu’on rencontre le même problème que d’autres personnes. Ça sera pour la prochaine fois 
Tuxmain a déjà bien répondu aux questions, je vais y ajouter mon apport.
J’ai rajouté « source de monnaie ». Ça devrait déjà éclaircir le point sans le détail donné par Tuxmain qui est très bien.
Oui, avec ce contournement ça me semble une bonne piste stable :
Oui, en augmentant la durée entre l’emisison des documents de transactions. Plus de cinq minutes pour être sûr. Mais, c’est surement pas suffisant pour être certain que la transaction passe.
Non, comme expliqué par Tuxmain.
Je sais pas très bien. Voyont voir ce que disent les paramètres de Duniter :
{
"currency": "g1",
"c": 0.0488,
"dt": 86400,
"ud0": 1000,
"sigPeriod": 432000,
"sigStock": 100,
"sigWindow": 5259600,
"sigValidity": 63115200,
"sigQty": 5,
"sigReplay": 5259600,
"idtyWindow": 5259600,
"msWindow": 5259600,
"msPeriod": 5259600,
"xpercent": 0.8,
"msValidity": 31557600,
"stepMax": 5,
"medianTimeBlocks": 24,
"avgGenTime": 300,
"dtDiffEval": 12,
"percentRot": 0.67,
"udTime0": 1488970800,
"udReevalTime0": 1490094000,
"dtReeval": 15778800
}⏎
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Certification life-span in the sandbox │ a month │
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Identity life-span in the sandbox │ a month │
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Membership life-span in the sandbox │ a month │
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
{sig,idty,ms,}Window sont définis. Par contre pour la transaction, le document le plus utilisé, txWindow n’est pas défini. Ça doit surement être la même valeur.
Après, comme dis Tuxmain, chaque mainteneur de nœud pourrait mettre en place des règles différentes sur la mempool de son nœud pour gérer l’expiration des documents.
Concernant la sélection des sources de monnaie dans Silkaj, je ne vois pas trop pourquoi ce problème a lieu. Silkaj enlève les sources des transactions trouvés dans les pendings. Peut-être qu’il est plus rapide que Duniter à mettre à jour ces indexes, soit c’est un bug dans Silkaj. À investiguer.
Ok, j’imagine qu’on devrait pouvoir faire ça de notre côté : endormir le script après chaque transaction et le réveiller toutes les 5 minutes jusqu’à ce qu’on constate que la transaction est bien passée. Le script devrait être utilisé essentiellement en arrière-plan via un CRON, donc si on le repense et qu’on le retravaille en ce sens ça ne devrait pas poser de problème.