Oui mais dans ce cas tu n’interdis pas le spam via des petites sources. (N’importe qui peut verser 1.05 et se renvoyer sur une autre clé 1.00).
La seule solution est bien de maintenir le solde des comptes, et d’interdire un virement qui ferait passer un compte sous la petite valeur minimale définie.
@Inso Je parlais de renvoyer la différence dans une 2ème transaction distincte.
Dans mon exemple on a une source de 1,05 G1 puis une source de 1,00 G1. On n’a jamais de source de montant inférieur a 1G1 et l’on a pas de multiplication des sources dans l’index. Le pouvoir de spam d’un attaquant restera de 1 entrée d’index par G1 comme actuellement (et pas une par centime).
Sauf que la deuxieme transaction génère une source de 0.05 par définition.
D’ailleurs le virement de B vers A de 1 implique un virement de B vers B de 0.05 dans la transaction…
Justement non dans ton exemple B ne pourra pas recevoir le micro-paiement car il ne peut pas se créer une source de 0,05 G1.
Une conséquence de la règle du montant minimal d’une source implique mécaniquement qu’un compte doit posséder ce montant minimal pour pouvoir recevoir des micro-paiements. Reprenons l’exemple avec B qui possède 1 G1 au départ.
EDIT: Le fait de devoir posséder au moins 1G1 sur un compte pour pouvoir y réaliser tout type d’opérations me semble tout a fait raisonnable. Un simple portefeuille qui démarre a zéro pourra quand même vendre avec zéro; par contre pour acheter il lui faudra au moins 1 G1.
EDIT2: Évidemment ça implique de modifier les algo de génération du document transaction coté client.
Ok, c’est ça qui était pas clair. On propose donc la même chose en fait : les transactions dont les outputs génèrent une UTXO inférieure à 0.05. Tu es bien obligé de maintenir l’index des montants des UTXO ! (Mais c’est plutôt normal de toute façon).
Oui exactement mon but était d’exprimer mon accord avec cette proposition et de montrer qu’elle n’empêche pas les micro-paiement, principal argument contre cette proposition qui avait déjà été formulée par le passé 
j’ai édité mon exemple en détaillant les sources possédés par A et B a chaque étape, on constate qu’a tout instant t toutes les sources ont bien un montant supérieur ou égal a 1 G1, et pourtant on a bien effectué un paiement de 0,05 G1 
Par contre pourquoi est ce que tu penses que ça implique de modifier les algos de génération des documents ?
Supposons que A veut envoyer 10 G1 à B et que A à 2 sources DU (20x10, 04) créez aux blocs numéros X1 et X2. (B a un solde supérieur a 1G1 avant la transaction).
Aujourd’hui je peut faire :
inputs :
1004:0:D:PUBKEY_A:X1
outputs:
1000:0:SIG(PUBKEY_B)
4:0:SIG(PUBKEY_A)
Avec le changement proposé il faut faire :
inputs :
1004:0:D:PUBKEY_A:X1
1004:0:D:PUBKEY_A:X2
outputs:
1000:0:SIG(PUBKEY_B)
1008:0:SIG(PUBKEY_A)
EDIT: En bref, au lieu de devoir réunir des sources dont la somme est >= au montant total M de la transaction il faut réunir des sources dont la somme est >= M+1. C’est donc pas grand chose a changer coté client 
Je suis clairement favorable à cette règle proposée par @elois et @nanocryk.
Cette-ci pourrait rapidement être codée et remplacer avantageusement la règle BR_G106 - Low accounts.
que se passes t’il alors au block 52 ? il n’y a pas de “n+1” DU, il n’y en a qu’un! Va-t’on dire aux utilisateurs d’attendre le deuxieme jours pour depenser leur DU ?
le changement existera alors dans une version >11 du protocol?
inputs
|0|“1000:0:D:2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ:1”|
outputs
|0|“1:0:SIG(Com8rJukCozHZyFa…sfDQdPApxQRnz7QYFf64mm)”|
|1|“999:0:SIG(2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ)”|
supprimer BR_G106 empêche la destruction de monnaie ! pour moi c’est une feature qui disparait
Oui.
Je ne trouve pas cela important, surtout à coup de 0,99 Ğ1. C’est un épiphénomène aujourd’hui.
supposons que pour une raison X ou Y, (argent sale) on pourrais envoyer des 0.99 sur des comptes vide pour supprimer cette monnaie, plutot que de la transmettre a un beneficiaire dont c’est le role. Une entité dont ca serait le role “legal” de recuperer l’argent sale, ne serait-elle pas sujet à des tentations? ne vaut-il pas mieux détruire cette monnaie, tout simplement?
Il est tout autant possible d’envoyer cette monnaie avec la verrou SIG(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx), cela revient à un résultat similaire : la monnaie devient inutilisable.
oui mais elle reste dans l’index, et donc quelqu’un peux tomber dessus en ouvrant sont compte … Je chipote, mais il y a quelque chose de Gainsbourg dans la BR_G106.
On peut déjà bloquer de la monnaie définitivement en fournissant un output mal formaté, @Max en avait fait les frais sur la G1-test et cet effet de bord m’a fait perdre de nombreuses heures sur durs pour simuler le meme effet de bord.
Les sources de monnaies mal formatés du genre avec une parenthèse en trop ou en moins 1000:0:SIG(PUBKEY_B ou 1000:0:SIG(PUBKEY_B)) sont bien acceptés par Duniter qui les met dans son index, mais elles ne sont pas dé-pensables car duniter n’arrive jamais a consommer la source même avec le même défaut de formatage dans l’input.
Du coup il reste a choisir entre plusieurs scénarios possibles pour la transition :
S1 : On converse la destruction des sources pour les blocks avec version < 12. Ça reste chiant coté clients pour gérer ça, et on doit garder l’indexation des balances des comptes coté serveur blockchain le temps de la synchro. Seul avantage : pas de hard fork.
S2: La nouvelle version considère qu’il n’y a jamais eu de destruction de monnaie. Avantages : plus besoin de traitements spécifiques pour cette règle passée, ça permet d’effacer du code mort. Et coté client ça simplifie énormément la vie, plus de destruction monétaire a gérer pour calculer la masse monétaire ou les balances des comptes.
Seul inconvénient : a la 1ère consommation d’une source considéré comme détruite par les anciennes versions de duniter on a un hard fork.
Je serait partant pour une solution intermédiaire :
S3 : Stocker les sources détruites dans un nouvel index spécial “destroyed utxos” qui n’existerait que pour une seule version de duniter (la 1.8 par exemple). Et coder dans le logiciel une feature de soft fork comme pour le rejeu des certifications (on peut ré exploiter le nonce).
Avant le soft fork on reste en blocks v11. Lorsque l’on a suffisamment de blocks dans la fenêtre courante qui ont le bon marquage dans leur nonce on passe en blocks v12, il n’y a alors plus destruction de sources.
Dés le passage en block v12 sûr (soit forkWindowSize blocs après le 1er bloc v12), les noeuds vide leur index spécial “destroyed utxos” et injectent ces sources dans leur sindex. Du coup c’est comme si il n’y avait jamais eu destruction monétaire.
Avantage : plus besoin de traitements spécifiques pour cette règle passée, ça permet d’effacer du code mort. Et coté client ça simplifie énormément la vie, plus de destruction monétaire a gérer pour calculer la masse monétaire ou les balances des comptes. Et pas de hard fork.
Inconvénient : Un peu plus difficile a coder.
Quel scénario te semble le plus souhaitable @cgeek ?
La solution 2 me paraît préférable perso, avec un timestamp de déclenchement. C’est simple et élégant.
Par contre
good to know !
perso j’utilise une vue en BDD et parfois j’oublie de l’initialiser, ca ne m’a jamais posé problème mais effectivement on gagne un peu de temps de synchro donc S1 || S2 || S3 je m’en fou, je vous laisse choisir.
Par contre je reste sur mon impression de depart, on perds une feature et du coup je propose un “espece de”
/dev/null
une adresse (en dehors du champs d’adresses actuel) qui permet de flush un compte proprement plutot qu’en exploitant de petits problème technique ou le recalcul des balances.
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
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.