Interdire les transactions avec source < 1,00 Ğ1

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 J'aimes

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: )

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