Interdire les transactions avec source < 1,00 Ğ1

Tu peux même indiquer que les 3 méthodes sont possibles : valeur vide, juste les parenthèses (), et la méthode DESTROY(), sont synonymes.

Cool :slight_smile: pour moi c’est bon, pour Junidev aussi apparemment.

1 J'aime

Ok, dans ce cas si tu veut bien je voudrais d’abord externaliser la doc du protocole avant de faire une MR :slight_smile: (cf ce thread : Documentation du protocole DUBP)

Cool ! :slight_smile:

Je ne vois plus de noeud v1.6 sur le réseau. Les miens ne se synchronise plus. Ils finissent toujours sur un fork… j’ai donc laissé tombé.

Je note au passage que cela revient à rendre explicite la destruction de la monnaie, dans le document de bloc, ce qui permettra d’avoir des indexeurs de BC “non contextuel” (sans calcul de balance à chaque bloc). :slight_smile:
Ca me va donc très bien !
L’historique des mouvements sur un compte sera donc correct (enfin !) par exemple dans les statistiques de compte dans Cs+.

Grand merci à vous !

2 J'aimes

Je me demande si ça ne cache pas une régression de la 1.7. Tu en penses quoi @cgeek ?

pas sur, c’est aussi du au temps de synchro, je penses.

Comme @kimamila, je dirais que le temps de synchro fait qu’ensuite le nœud galère à raccrocher les wagons. Ça mériterait investigations cela dit, mais je n’ai plus trop d’énergie à donner pour cette version de Duniter.

1 J'aime

Ce n’est pas tant le fait qu’un bug traîne dans la 1.6… j’espère surtout que ya pas une anomalie dans la chaîne en 1.7. mais si c’est un fork une fois la synchronisation effectuée, ça doit aller effectivement.

Et voila j’ai soumis une RFC pour le protocole V12 : https://git.duniter.org/nodes/common/doc/merge_requests/10

Pour visualiser les différences il faut regarder les diff du 2ème commit: https://git.duniter.org/nodes/common/doc/merge_requests/10/diffs?commit_id=527f359d5c63b0dae0080223f1255a21ad0aaf21

1 J'aime

10% * DU(t) est plus conforme à l’évolution que 1 Ğ1.

1 J'aime

@cgeek @Moul @Inso , la je suis en train de refondre la génération des index dans Dunitrust et notamment des index liés aux transactions, j’en profite pour ne plus appliquer la suppression des sources des comptes dont le solde passe sous 1G1, conformément a l’évolution v12 sur laquelle nous somme tombés d’accord :slight_smile:

En conséquence, Dunitrust n’indiquera pas le même solde que Duniter tant que cette règle ne sera pas également supprimée de Duniter :sweat_smile:

Cependant, je ne peut pas encore interdire les sources inférieures a 1Ğ1 tant que Duniter ne l’aura pas fait car sinon je vais refuser des blocs considérés comme valides par Duniter et les noeuds Dunitrust ne resteront donc pas synchronisés.

C’est pourquoi j’aimerais qu’on avance sur ce sujet, il reste à décider si le montant minimum d’une source sera a 1Ğ1 comme nous l’avions convenus ou si l’on considère la proposition de @Galuel.

Je crains que 10% * DU(t) soit trop limitant que diriez vous de 1% * DU(t) ?

10 % de 1 DU(t) fait 1,01 aujourd’hui avec un DU de 10,11.
Si plus tard on a DU de 11, ça fera 1,1.
Les ouptuts de 1,01 à 0,01 seront interdits, puis de 1,1 à 0,01.

Cette mesure interdirait le montant des outputs je suppose. Pas du mouvement d’unités d’une clé à une clée différente au sein d’une même tx ?
Quid des backchange inférieur à cette valeur ? Si j’envoie 100 en coupant une source de 101, le 1 restant ne peux pas me revenir, car il est inférieur à cette limite. N’est-ce pas ? Ou, un cas laisserais passer ça ? Ça complexifie.
La seule solution et de l’envoyer en cadeau au bénéficiaire en surplus. Les clients devront mettre en place ce cadeau s’il se produit. Gestion qui ferait pas de mal à éviter vu le nombre de cas à gérer pour les transactions du point de vue client.

Je ne comprend pas ta remarque, tout mouvement d’unité se fait forcément par un output. Les backchange aussi. La règle sera l’interdiction de transaction contenant des outputs d’un montant inférieur au seuil, ça a déjà été discuté en long en large et en travers depuis des mois :slight_smile:

Ben non, il suffit de choisir les sources telles que somme_inputs > montant + seuil. On a alors un output du bon montant, et un backchange > seuil.

Le problème d’un output trop petit ne se pose que si on vide un compte contenant 101 en créant un output de 100 en un de 1. (par exemple). C’est un cas très particulier.

1 J'aime

Et 10 × (unitbase+1) ? Ca a l’intérêt de beaucoup moins varier que le DU, ce qui permet de le coder « en dur » pour des projets logiciels d’une durée courte.

1 J'aime

Tu n’a pas précisé l’unité mais je suppose que tu parle de centimes de Ğ1, dans ce cas ça me semble être une bonne idée mais je proposerais plus un coefficient de 100 :slight_smile: (Pour que le seuil soit a 1 Ğ1 en base 0).

1 J'aime

Pou être précis,

  • 10*10^(unitbase+1) ou
  • 100*10^unitbase (ce qui est plus compréhensible)

Oui, c’est ça. D’ailleurs, c’est ce qui est calculé sur GTest pour le montant minimal des comptes : maintenant qu’on est en base 2, les comptes < 100GT passent à 0.

1 J'aime

Je crois que pour une meilleure communication avec les utilisateurs lambda, il est préférable de parler en DUğ1.
Donc c’est peut-être plus compliqué à coder, (pas de beaucoup je pense) mais je crois que si on mets une limite ce devrait être 0,100 DUğ1.
Merci à vous

Personnellement je préfère fixer la limite minimale à 100 * 10 ^ (unitbase+1), c’est infiniment plus simple techniquement et ça permet de rester sur la limite actuelle de 1 G1 (même si la nature de la limite change, son montant resterait le même).

Je rappelle qu’il s’agit d’une limite purement technique qui ne sert que à éviter une attaque qui consisterai a faire trop grossir l’index des sources. Il n’y a donc aucun besoin de rendre cette limite « élégante ».

De plus, je considère que toute complexité inutile doit être évitée, principe KISS (Keep It Stupid Simple), donc je trouve que faire varier cette limite en fonction du montant du DU courant est une complexité inutile, qu’on peut éviter.

Certains argueront que unitbase restera a zéro pendant plus de 100 ans et que donc au bout de quelques décennies une limite a 1 Ğ1 sera insuffisante. Je répondrais qu’on s’en fiche car à long terme les sources de monnaie ne seront plus stockées en blockchain, nanocryk avais proposé des mécanismes en ce sens, et j’ai toujours cette idée en tête pour le long-terme, @cgeek aussi d’ailleurs, on a même abordé brièvement le sujet aux RML14. Tout ça pour dire que le but de cette limite est de nous protéger pour quelques années, au plus une décennie, et que donc 1 Ğ1 répond suffisamment bien au besoin technique.

@cgeek quel est ton avis concernant le montant minimal d’une source à adopter ? Ce serait bien que l’on tranche enfin cette question, en discussion depuis déjà plus de 6 mois :slight_smile:

2 J'aimes

Oui, c’est une limitation temporaire. Le montant 1,00 Ğ1 fait parfaitement l’affaire.

La limitation sera levée dès que nous ne stockerons plus les sources, et j’espère bien que ça ne mettra pas 10 ans à être implémenté. :slight_smile:

2 J'aimes