Tu peux définir “dust output” ?
Je dirais 0.01 g1, et une “adresse” doit contenir au minimum, mais je n’en suis pas certain.
255 inputs, 255 outputs. Quand à la taille actuellement c’est un nombre de ligne qui est défini dans le protocole. Là tout de suite je ne le trouve pas, mais je l’ai vu dedans et sinon quelqu’un d’autre pourra sûrement le préciser.
Il me semble bien qu’il y a plusieurs sujets qui en parlent sur ce forum, avec des propositions pour les limiter.
0.01 par output, oui.
Une adresse ne doit pas contenir moins de 0.1 DU.
D’accord, je ne savais pas que c’était en fonction du DU.
Mmh, en fait j’ai dit une bêtise 
C’est interdiction d’avoir moins que 1.00 unité dans la base courante.
Je n’en était pas sur, et avec la base et le DU actuel c’est la même valeur donc ça aide pas 
Discussion à propos de l’utilisation de Merkle tries comme structure principale des blocs et qui permet de “stocker” l’état de la monnaie, permettant de supprimer des anciens blocs au fur et à mesure, ainsi que de prouver certaines informations que pourraient demander des clients (les nœuds ne seraient donc plus des tiers de confiances pour ces requêtes).
La RFC à été mise à jour pour prendre en compte les idées exprimées, et la partie “Block” contiendra les détails de la structure du Merkle tree.
Nouvelle mise à jour : structure du document revue pour essayer de le rendre plus digeste. Intègre aussi les dernières idées au niveau des transactions et un nouveau format d’addresses unifié.
Ces derniers jours je relis pas mal d’anciens posts du forum pour voir les différentes réflexions autour de Duniter et de certaines faiblesses. L’une d’entre elle est que l’équipe de développeurs à un pouvoir assez important sur les choix d’évolutions. Ne serait-il pas une bonne idée d’intégrer à la blockchain un système de vote qui permettrais de modifier certains paramètres ? De plus, essayer de déplacer un certain nombre de limites qui sont codés en dur en paramètres intégrés à la blockchain, de telle sorte qu’elle puisse évoluer sans nécessiter de modifications dans le code ?
Avec les techniques exposées précédemment sur les groupements de transaction, on se rend compte que les votes seraient très simple a intégrer et qu’après leur échéance leur données pourraient être oubliées.
A quel paramètres tu penses ?
La plupart des paramètres de la blockchain qui pourrait s’adapter à son usage sans modification du code ou fork de la blockchain. L’idée est simplement de pouvoir faire évoluer les règles de la monnaie sans avoir besoin d’avoir des connaissances techniques en informatique, et sans devoir attendre que l’équipe de dev en ai envie ou aie le temps.
Pour ma part je ne comprends pas trop pourquoi le DU est actualisé tous les 6 mois et pas plus régulièrement, de sorte qu’elle s’adapte rapidement aux nombre de membres et d’avoir une évolution continue du DU et éviter des “cassures” tous les 6 mois.
Si d’autres personnes pensent la même chose, il est possible d’en parler, et de proposer aux membres un changement. S’il obtient la quasi-totale majorité, alors il est accepté automatiquement par le protocole. On peut envisager ça pour le temps inter-bloc, si on veut augmenter la rapidité de validation des transaction; voir même c s’il s’avère que dans quelques décennies l’espérance de vie d’un humain soit significativement plus longue (ou plus courte, pourquoi pas).
Pour moi ce qui est important c’est que tout le monde puisse participer et donner sa voix, et pour ne pas qu’un petit groupe comme le “staff” semble prendre toutes les décisions, ce qui à déjà été remonté sous la forme de “malaises”.
A cause de ça : Nombre de chiffres requis pour le DU - #4 by Galuel
Sinon, faire un protocole qui change c’est vraiment compliqué. Je comprends bien la problématique, cependant, rien n’oblige à l’implémenter pour la v11. Il faut savoir rester raisonnable dans les objectifs recherchés…
La v11 ne sera pas la dernière version du protocole de toute façon. Il n’y aura techniquement jamais de dernière version, toujours de nouvelles choses à faire.
Ya un moment ou il faut savoir fermer le cahier des charges. Ce qui n’empêche pas de réfléchir en profondeur sur la méthode de gouvernance de la blockchain pendant ce temps, pour une version ultérieure.
L’intention est louable mais je pense que c’est très dangereux pour la simple et bonne raison que sur les sujets pointu la majorité a souvent tord.
Ceci étant il y a une infinité de dégradés entre notre fonctionnement actuel et une démocratie totale, et je suis favorable a une gouvernance davantage partagée, a impliquer davantage les utilisateurs dans les décisions.
Cependant, le vote direct a la majorité me semble être une très très très mauvaise méthode et je suis convaincu qu’un tel choix nous mènera a la mort technique de la monnaie suite a une mauvaise décision de la majorité.
Je n’ai pas la solution idéale, je pense que nous devrions demander conseil a des spécialistes ie gouvernance, je sais que @poka a une certaine expérience en gouvernance sur un autre projets, j’aimerais que tu nous apporte ton point de vue poka, sans doute d’autres personnes un t’elle des connaissances dans ce domaine, manisfestez-vous
Ma crainte principale est la suivante : Imaginons en décision entre deux choix A et B, que la grande majorité des utilisateurs souhaitent A mais qu’une partie des informaticiens ou théoriciens y soient fondamentalement opposés, expliquent et démontre que c’est très dangereux, mais hélas la plupart des utilisateurs ne comprennent pas ces explications trop techniques et maintiennent leur vote pour B : et suite a ce mauvais choix un problème technique majeur survient et la monnaie s’arrête (ou son bon fonctionnement est fortement altéré).
Une solution serait peut-être que les développeurs de la duniter team est un droit de véto pour bloquer un changement qu’il considérerait trop risqué.
Typiquement, la réévaluation du Du tout les 6 mois, il y a des raisons techniques précises qui l’impose liés au nombre de chiffres que l’on stocke dans Duniter pour stocker le montant du DU. Et même si dans le nouveau protocole tu veut descendre au millième plutôt qu’au centime, ça ne déplace que peu la limite.
Un fonctionnement qui me conviendrai, et que j’ai déjà cité plusieurs fois dans mes discussions perso, ce serait un mécanisme de prise de décision par traitement des objections, inspiré par exemple de l’Holacraty.
L’idée est qu’un changement ne peut être acté que s’il n’y a plus aucune objection valide a ce changement (que toutes les objections valides ont donc été traitées). Alors oui c’est possible d’implémenter un tel protocole mais c’est encore plus compliqué que le protocole de la monnaie ou de la wot, j’ai lu en entier le protocole holocraty (il y a longtemps déjà) il me semble vraiment très bien fait mais aussi très complexe a implémenter :
Merci, ça va me faire une très bonne lecture.
Ça vaut vraiment le coup, c’est un système vraiment très bien fait, et qui m’a fait définitivement rompre avec le concept archaïque de “vote”
Je pense que cette discussion va intéresser @1000i100 aussi 
Pour compléter mes propos : la V11 va devenir rapidement importante pour des raisons de performances et de robustesse du réseau avec la montée en charge.
La gouvernance peut encore attendre, prendre des décisions tel que modifier c ou la vitesse de calcul des blocs, il n’y en aura pas besoin avec une dizaine d’année minimum.
Quand je parlais de vote, c’était bien pour exprimer une prise de décision et non une méthode particulière 
Cela reste toutefois beaucoup trop complexe pour le moment, donc on verra plus tard.
J’essaye surtout de faire un protocole qui permettra de rajouter de nouveaux éléments avec le moins de hard fork possibles. On pourrait par exemple mettre les paramètres dans l’état, mais pas encore de moyen de les changer.
+1, je serait favorable a ce qu’on réfléchisse a l’intégration d’un protocole de gouvernance pour la v12. Mais se sera long, on peut par exemple se fixer comme objectif une v11 stable pour 2020 et une v12 avec gouvernance intégrée stable pour 2023.
La lecture est un peu trop conséquente pour que je m’y atèle maintenant, mais de ce que j’en connais, cela me semble des mécanisme en effet très intéressant pour s’adapter efficacement aux nouvelles situations entre individu fortement investi par une raison d’être commune.
Hors, plus la communauté grandi, moins il me semble probable qu’elle constitue un groupe d’individu fortement investi et avec un raison d’être commune, donc je ne sais pas à quel point ce système serait robuste face à une incitation financière à grande échelle pour faire pencher des choix dans une direction.
Pour ça, le véto de facto des développeurs de part le besoin d’aller changer le code me semble un compromis temporairement acceptable.
Des règles plus facilement changeable que ce soit par vote simple ou par d’autres méchanisme (comme ceux inspiré de l’holacratie), me semble pouvoir prendre toute leur place quand il n’y aura plus une monnaie libre unique, dont la réputation et la confiance dans ses fondement théorique dépend, mais un ensemble de monnaies libres certaines plus stable et conservatrice, d’autres plus expérimentales…
Mais nous en somme loin aujourd’hui.
http://trm.creationmonetaire.info/appendice-2.html#les-4-libertes-economiques
Pour rappel, la première des 4 liberté défini dans la trm est tout de même :
Sans quoi la position monopolistique d’une monnaie, fut-elle basé sur Duniter, ne pourrais plus être considéré comme libre.
Et cela me semble valable que le monopole soit un monopole légal, ou un monopole d’usage / de facto par une position de premier arrivant notable.
Mais je dérive (un peu) du sujet “protocole v11”