C’est exactement ça, encore que la division par 10 ne détruit pas tous les centimes : juste les comptes qui contenaient moins de 10,00 unités, puisque forcément au changement de base, ces mêmes comptes ont alors moins de 1,00.
1 Like
cool , et pour les 23 ans?
c’est pas qu’au bout de tout ce temps de création monétaire, la somme est tellement importante qu’il faut décaler la virgule pour que le logiciel puisse continuer à la gérer?
Je pense que c’est surtout pour garder des nombres siginfiants pour l’être humain, plutôt que pour des limites logicielles.
alors la question des 23 années reste alors entière!
Les 23 ans sont une estimation à la louche me semble t’il du temps qui s’écoulera avant que l’expression quantitative d’un DU commence à être génante et nécéssite un décalage de virgule. (Un peu comme le passage de l’ancien au nouveau franc) Ce nombre d’années sera variable en fonction de la vitesse de propagation des membres, qui influeront par le nombre et la croissance, sur la quantité de Ğ1 relatifs à 1DU_Ğ1.
C’est ce qu’il me semble comprendre, mais comme la plupart d’entre nous, je me suis habitué à la prudence tant il y a de paramètres subtils dans Duniter qui m’échappent encore.
1 Like
Concernant les 23 ans, cela ne vient pas de Duniter mais de la monnaie libre : pour une monnaie établie avec c = 10%/an, le DU quantitatif décuple toutes les 23 années environ.
3 Likes
@cgeek une idée de ce qui a pu se passer? Demain je t’envoie l’intégralité de mon DU quotidien, on va voir si on reproduit.
Je vois qu’elle n’apparaît pas dans la base de ton nœud, par contre elle est bien dans le mien, mais elle n’a pas été incluse dans un bloc (pas de bloc_number, le champ time est vide, et le champ received est rempli, Le reste ressemble aux autres transactions).
J’ai envoyé la transaction depuis Cesium, qui est lié à g1.duniter.org donc lui-aussi doit l’avoir. Et je ne vois pas pourquoi elle a atterri chez moi, et pas chez toi. Il y a eu un cafouillage quelque part, mais où et pourquoi? Ma question reste sans réponse. Parce que mon compte apparaît toujours à 0 dans cesium (ce qui paraît logique s’il a enregistré la transaction). Et ça se matérialise d’ailleurs aussi par le fait que j’ai perdu le solde de transactions remuniter inférieures à 1Ğ reçues depuis (mais là je viens d’en recevoir une exactement égale à 1Ğ et je suis donc maintenant à 1Ğ).
Edit: vraisemblablement, elle fait des brasses dans les piscines, peut-être devrions-nous lui apprendre le crawl? 
La propagation est un mécanisme à rebonds, il suffit que le nœud receveur initial de la transaction se loupe pour que la transaction ne soit pas propagée.
Ce problème peut être contourné en envoyant la transaction, non pas à 1 seul nœuds, mais plusieurs. Comme ça on limite les risques de “brasses” 
C’est ce que fait Sakia il me semble.
Ce qui est tout de même suspect à mes yeux, c’est que j’ai envoyé 5 transactions à peu près dans la même fenêtre de temps, 4 sont passées sans aucun problème, et la 5ème se retrouve à faire des brasses. Coïncidence ou pas qu’il s’agisse pile poil de celle qui mettait mon compte à 0, je me pose simplement la question. Pour le fun, je viens de t’envoyer une transaction de 1.1UD qui vide à nouveau mon compte. Passera-t-y, passera-t-y pas?
On voit d’ailleurs ces deux transactions dans la section « sending » de https://g1.duniter.org/tx/history/FEkbc4BfJukSWnCU6Hed6dgwwTuPFTVdgz5LpL4iHr9J
Bon celle d’aujourd’hui vient de passer. Reste celle de l’autre jour qui reste en carafe.
Si tu es un peu joueur, tu peux agrandir la fenêtre d’élagage en ajoutant par exemple 1000 au tableau (la taille de la blockchain étant de 820, cela revient à désactiver l’élagage) puis faire ceci :
duniter reset data
duniter sync g1.duniter.org 10901 --cautious
Puis requêter la base de données comme suit :
select * from s_index s1 where s1.conditions like "%FEkbc4BfJukSWnCU6Hed6dgwwTuPFTVdgz5LpL4iHr9J%" and exists (
select * from s_index s2 where s2.identifier = s1.identifier and s2.pos = s1.pos and s2.written_on = s1.written_on and s2.op != s1.op
)
order by cast(written_on as int);
Je vois que tu as perdu 0,52, 0,30 et 0,20 à cause du compte vide au moment de la réception.
Je ne comprends pas vraiment ce que ça veut dire. 
Tu veux que je patche le code pour ajouter 1000 mais où?
Sur ma base locale, cette requête me renvoie 2 lignes, une CREATE et une UPDATE mais avec un tx différent du hash de la transaction qui pose problème (et dans la table, il y a 3 entrées avec ce hash, et ce hash correspond à la transaction que je t’ai envoyée aujourd’hui et qui est passée…). Mais vu que je ne sais pas à quoi correspond s_index et les différents champs qui la composent, c’est pas commode à interpréter. Il faudrait que je prenne le temps de regarder tout ça d’un peu plus près.
Eh bien Duniter ne conserve pas l’ensemble des opérations qui ont été effectuées, et par exemple quand une source est consommée, celle-ci est élaguée (supprimée) de la base de données si elle dépasse un certain âge, car elle n’est plus d’aucune utilité.
Ce que je te proposais c’est d’ajouter une ligne, pour obtenir :
const bindexSize = [
1000,
block.issuersCount,
block.issuersFrame,
conf.medianTimeBlocks,
conf.dtDiffEval
]
Puis d’exécuter les commandes données afin d’obtenir l’historique complet des opérations réalisées, sans perte (sans élagage).
Ce qui te permettrait d’avoir plus que 2 lignes.
J’ai donc fait tout ça mais je n’ai que 3 transactions qui apparaissent, et pas celle-là, qui n’apparaît pas non-plus dans la table des transactions. Je referai un test demain.
Pour la petite histoire, j’ai essayé de revider mon compte, et ça n’a pas fonctionné comme prévu. Depuis Cesium, après avoir vérifié le solde de mon compte à 12,3Ğ, j’ai envoyé 5 transactions de 2Ğ, puis une de 2,3Ğ. Les 5 premières sont passées sans souci.
Pour la dernière, celle qui vidait totalement le compte, c’est un peu plus compliqué. Pour un observateur inattentif, on aurait dit que tout s’était bien passé, cesium disant que la transaction avait été envoyée avec succès. Mon œil de lynx (!) a aperçu pendant une fraction de seconde un truc rouge dans le coin de la fenêtre d’envoi avant qu’elle se referme. En allant ensuite sur « Mes Transactions », j’étais bien à 0, mais un petit F5 m’a montré que la transaction n’était en fait pas passée, cesium ne me l’affichait pas et m’indiquait que mon compte n’était pas à 0 mais avait 2,3Ğ. Je suis retourné pour la soumettre à nouveau, et ai fait une petite capture d’écran pour voir ce que c’était:
Donc cesium a bien repéré que la transaction mettrait mon compte à 0. Le plus curieux, c’est que cette transaction est passée cette fois dans cesium, mais avec un montant légèrement différent: 2,29Ğ (alors que j’avais bien indiqué 2,3, c’est une certitude). Cesium me l’a affichée pendant un moment, et me mettait bien que mon compte était à 0,01Ğ (cohérent, même si ce n’était pas ce que j’avais demandé). J’ai essayé d’envoyer les 0,01 restants, cesium m’a dit que la transaction avait été envoyée, mais un petit F5 sur mon compte m’a indiqué que la transaction en question n’existait pas et que j’étais toujours avec un solde de 0,01Ğ.
Depuis, le temps a passé, et ce qui a été inscrit dans la blockchain est différent de l’histoire que cesium m’avait racontée. La transaction à 2,3Ğ a bien été diffusée et est bien passée (au bloc 1166), et celle à 2,29 est maintenant dans les transactions non exécutées de cesium, qui m’affiche bien un solde final de 0, et affiche aussi la transaction à 2,3Ğ comme exécutée. L’histoire n’est pas la même, mais le résultat final est cohérent, ce qui est très bien.
Je suis conscient que c’est vraiment un cas à la marge, mais je tenais à le signaler pendant que c’est frais.
Mets en copie kimamila, ou bien fais un ticket github, sinon cette fraîcheur tombera dans les oubliettes ! Le ticket étant la solution la plus appréciée
2 Likes