Transaction envoi junes validée mais compte non crédité

Capture|690x245

virement fait, validé, mais 90 minutes après toujours le compte à zéro !

Bonjour…

1 J'aime

Bonjour,

Il est possible d’envoyer des transactions du montant qu’on veut, cependant les comptes possédant moins d’1 G1 sont remis à zéro, les G1 sont donc supprimées.

Il faut donc mettre au moins 1 G1 sur le compte.

Ce n’est pas un bug, c’est voulu (pour limiter le spam). Il est possible que ce comportement soit supprimé au profit d’un montant de transaction minimal, dans une version prochaine du protocole.

1 J'aime

décision complètement nulle car ça détruit de la monnaie

C’est effectivement un inconvénient, mais ce type de mesure est nécessaire pour limiter le spam : si j’envoie 0.01 G1 (la plus petite subdivision de G1) sur un million de comptes, ça va prendre beaucoup de place dans les bases de données des nœuds Duniter.

Le montant minimal du compte multiplie par 100 le coût en G1 d’une telle attaque. (je suis d’accord que c’est pas idéal quand même)

Cesium pourrait afficher un avertissement à la personne qui envoie une transaction dans ce cas-là, mais ça ralentirait encore le paiement (une requête en plus), et on ne sait pas pour combien de temps cette limitation restera.

Quant à la destruction de monnaie, une somme inférieure à 1 G1 est négligeable, en pratique ça ne devrait pas poser de problème.

1 J'aime

Je t’invite à comptabiliser :

  • La somme des transactions inférieures à 1 June, soit X.
  • La somme des comptes dont les utilisateurs ont perdu le mot de passe ou abandonné la June (pas facile, mais on peut prendre les comptes révoqués non vides), soit Y.

Je parie mon string fluo que X est largement inférieur à Y, avec une somme que l’on peut considérer comme négligeable et qui rapportée à la masse monétaire le sera encore plus avec le temps.

On a donc une décision de conception qui :

  • Protège le réseau contre le spam.
  • A un impact quasi nul sur la masse monétaire (comparé aux comptes inaccessibles ou abandonnés).

Si tu es force de proposition pour arriver au même résultat (autre que restreindre les transactions à 1 June minimum, qui est déjà dans la roadmap) n’hésite pas.

2 J'aime

la transaction est quand même faite donc ça ne solutionne pas grand chose.
oui moins d’une g1 c’est négligeable, mais je pourrais faire disparaitre mon compte en bouclant sur des transactions de 99 junes… ça c’est plus genant

je ne comprends pas, ce qui est annulé c’est le solde inférieur a 1,00 june, mais ça n’empeche pas de faire des transactions de 0,01 junes

1 J'aime

Ça ne limite pas le débit des transactions, mais ça rend un peu plus difficile de beaucoup faire augmenter la taille de l’index des montants des comptes. C’est vrai qu’on peut faire mieux et qu’il y a des failles.

Comment ça ?

Effectivement il faudrait calculer la somme des transactions de moins de 1 G1 arrivant sur un compte vide + des transactions laissant un compte à moins de 1 G1, pour être précis.

Il n’y a pas de destruction de monnaie, ces montant inférieur à 1 june sont simplement innaccessible et invisible actuellement, mais il est possible que d’ici quelques années, avec les amélioration du protocole DUBP venants, toutes ces junes réapparaissent comme par magie sur les comptes respectifs.

Patience donc, cette solution est loin d’être parfaite, mais elle a le mérite d’exister en attendant que le protocole soit amélioré.

2 J'aime

interessant, et imaginons que sur ce compte montrant 0 il y ait virtuellement 53 jentimes (1 jentime = un centième de june), si je vire 58 jentimes dessus, on y verra 1.11 junes ?

1 J'aime

Très bonne question, je ne sais pas te répondre, tu peux faire le test et nous dire :slight_smile:

Là comme ça je pense que non cela n’apparaîtra pas, mais je ne connais pas suffisamment bien le protocole pour expliquer pourquoi.

Non.

Parce que les noeuds considèrent les montants inf. à 100 centiG1 (sur un script d’unlock unique) comme tacitement dépensés, sans que ce soit inscrit en BC.

Ce que tu as écrit plus haut est juste : si cette règle devrait être levée, ces sources non ecplicitement dépensées redeviendraient disponibles.


Du coup, si je ne me trompe pas, si un script SIG(A) a + de 100 et qu’on envoie 50 à SIG(A) || SIG(B), ces 50 sont considérés dépensés. Vérifier si on fait planter GTest avec ça :wink:

5 J'aime

réponse en image: 0.32 + 0.70 junes envoyéessur le compteet celui ci reste nul

1 J'aime