Oui mais je ne compte pas supprimer la mécanique des changements de version, simplement je ne souhaite pas que l’on ai des documents dont la version est antérieure à la v0.6 à venir car la 0.6 sera certainement notre point de départ pour une monnaie de prod.
Donc tout le code qui traite des documents précédents sera comme mort pour nous. Or cela apportera de la confusion aux futurs développeurs que d’avoir du code présent mais jamais exécuté.
Selon moi, il faut que cette monnaie de test ait un DU distribué chaque jour comme aujourd’hui, afin de tester facilement cette partie du code en cas de modification.
Édit et HS: Après réflexion, je me dis que le DU devrait également être distribué chaque jour sur la monnaie de production (avec “c” correct bien sur), Pourquoi?
Car j’ai peur qu’une partie des utilisateurs n’accède à la monnaie libre uniquement pour son DU, pour ensuite la revendre en monnaie non libre à chaque réception de DU.
Même si comme dit @Galuel, mes peurs n’appartiennent qu’à moi, mais si cela devait se produire,
fournir le DU chaque jour permettrait d’éviter une mise importante sur le marché de la monnaie libre en chaque début de mois/année
Et éviter une volatilité sur la monnaie inutile.
Imaginons également que l’on fournisse le DU une fois par an.
La perte de 10% d’un coup de la valeur d’un coin (en quantitatif) risque de générer des comportements curieux sur les places de marché.
Pour ces raisons je me dis qu’une distribution du DU le moins espacé possible me semble le moins risquée.
Mais ce n’est que mon ressenti, je suis loin d’être un expert en trading.
C’est juste, mais plutôt dans le sens de la nécessité de la continuité, il vaut mieux une production continue et régulière que saccadée tout simplement, tout en ayant un timing suffisamment “à taille humaine” permettant le contrôle et la réactivité. 24 heures semble donc une bonne unité temps pour la création.
Running 0.60.0 and getting similar errors:
2016-12-23T14:29:33+00:00 - info: SWITCH: get side chain #61052-000010EA27B8DFD60919BF616FB08547A09C31BF98855A4F6BFA0FEB5AF3BE9B...
2016-12-23T14:29:33+00:00 - info: SWITCH: revert main chain to block #60952...
2016-12-23T14:29:36+00:00 - info: SWITCH: apply side chain #61052-000010EA27B8DFD60919BF616FB08547A09C31BF98855A4F6BFA0FEB5AF3BE9B...
2016-12-23T14:29:36+00:00 - warn: Source T:F29550075E8509E4CA8814CE466E542F2DB22AC8412C4C56A1DABF3EFD49B8A8:11 is not available
2016-12-23T14:29:36+00:00 - warn: SWITCH: error %s httpCode=400, ucode=2015, message=Source already consumed
2016-12-23T14:29:36+00:00 - info: Block #60953 added to the blockchain in 141 ms
2016-12-23T14:29:36+00:00 - warn: Blockchain changed!
2016-12-23T14:29:37+00:00 - warn: Too high difficulty: waiting for other members to write next block
2016-12-23T14:29:37+00:00 - info: Pulling blocks from the network...
2016-12-23T14:29:39+00:00 - error: Blocks were not applied.
2016-12-23T14:29:42+00:00 - error: Blocks were not applied.
2016-12-23T14:29:44+00:00 - error: Blocks were not applied.
I notice https://github.com/duniter/duniter/issues/704 has been reopened and a commit by c-geek last week. Let me know if I can help out with testing a dev branch or anyhting… If not, what’s the ETA of v.0.61 ?
I bet on early January. It will be a v0.80 to mark the rupture with v0.60, since a lot of things will change in this version but still be compliant with TestNet and 0.60 nodes.
To circumvent the bug, you can try to reset + resync your node with the network. I know it is not a real fix, and I also know it would be better to release a 0.60.1 to make the fix. But we are so close to 0.80, and this version potentially fixes so many bugs, that I prefer to not release a minor patchy version and wait for the 0.80.
Tu veux dire à la “mise en service” de la monnaie?
Bonjour,
Je n’arrive pas à synchroniser sur Duniter serveur 1.7.11. ( ubuntu 18.04.2 - 64bit )
Dans le terminal est inscrit :
En 1.7.x, la commande de synchronisation a changé : duniter sync host:port.
Même probleme avec cet nouvelle commande !
Es-tu passé d’un nœud 1.6.x en 1.7.x sans supprimer l’ancienne base de données ?
Les bases de données sont incompatibles.
non, j’ai fait une réinstallation complète de ubuntu 18 sur mon ancien donc formatage du disque
Peux-tu fournir plus de logs ? C’est pas simple à comprendre le problème auquel tu fais face.
Les logs ci-dessus arrivent quand ?
Je vois “block resolution : 0 block…”
Donc je suppose que tu as lancé Duniter par duniter start sans faire de duniter sync.
Pour synchroniser sur le serveur g1.duniter.org, la commande est duniter sync g1.duniter.org.
Le host:port donné par Moul indique les données attendues, il faut le remplacer par l’adresse du noeud.
Merci bcp ! Problème résolu ! c’était juste ça.
