Interdire les transactions avec source < 1,00 Ğ1

En réalité on n’a pas encore d’ “adresse”. Un compte est défini comme un ensemble de conditions de déblocage.Le jours ou l’on aura un système d’adresse on pourra définir par convention une adresse trou noir oui :slight_smile:

En attendant pour supprimer proprement de la monnaie je propose la convention suivante : l’absence de contions de déblocages dans le output.

Aujourd’hui le ouput c’est AMOUT:BASE:CONDITIONS.

On pourrait définir une notation représentant ou groupe de conditions vide, par exemple ().

Du coup pour détruire de la monnaie il suffirait de rajouter un output : AMOUT:BASE:().

Règle du protocole a ajouter : si le groupe de conditions est vide on considère le output comme valide mais on ne l’insère pas dans le SINDEX. Du coup personne ne pourra jamais consommer cette source car elle ne se trouvera pas dans les index.

Je rejetterais S1, car c’est vrai que ce code est vraiment inutile et consommateur en ressources.

Quitte à devoir hardforker (première conso S2, ou S3 avec passage en v12 non géré par un nœud resté en v11) , je préfère effectivement la solution S2.

Concernant la destruction de monnaie, OK pour un motif de conditions. Ce peut d’ailleurs être un nom de fonction propre comme DESTROY(), enfin peu importe.

1 Like

Les trous noir sont plutot dense et remplis, mais leur localisation c’est le vide intersideral!

ca me va le champ vide, null, Destroy ou “()”, du moment que c’est propre

3 Likes

Cool nous sommes d’accord :smiley:

Dans la mesure ou ça ne vous dérange pas de faire un hardfork,ça me va de choisir le scénario S2 :slight_smile:

Dans ce cas j’aimerai qu’on interdise l’association de DESTROY() avec d’autres conditions. (C’est pour ça que j’avais proposé un groupe de conditions vide).

Concrètement ça veut dire que si un document transaction contient ou output ou DESTROY() est associé a d’autres conditions de déblocage alors le document transaction sera considéré comme invalide.

Si ce comportement vous conviens y a plus qu’a soumettre une MR sur la doc du protocole (je peut le faire si vous le souhaitez :slight_smile: )

1 Like

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 Like

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 Likes

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 Like

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 Like

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

1 Like

@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 Like

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 Like

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 Like