Interdire les transactions avec source < 1,00 Ğ1

transaction
protocole
duniter

#21

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


#22

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


Demandes récurrentes sur Cesium => évolution de Duniter ?
#23

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.


#24

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)


#25

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é.


#26

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 !


#27

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


#28

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


#29

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.


#30

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.


#31

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


Documentation du protocole DUBP