Excellent Tortue et gege53, je vous vois synchronisés dans Sakia. Merci pour votre réactivité 
Bon ca remarche, mais du coup, comme j’ai effacer le repertoire default, j’ai perdu l’association à mon compte…
C’est bon tout remarche comme il faut, j’ai un peu du mal avec ces histoires de secret key, password et cie, faut vraiment que je le liste le TRM
La TRM ne parleras pas des histoires de secret key, password etc ! Ce n’est que dans la partie technique ça 
Merci @cgeek j’en ai profiter pour tester la mise a jours de mon nœud spécialisé avec “*” dans le package.json et ça marche il s’est mis à jours en 0.50.4 !!
Par contre malgré que presque tout les nœud ont bien fait la mise à jours, ça semble toujours forker fortement 
oui j’ai mon noeud qui boucle a tenter de rejoindre la branche principal:
2016-11-29T09:28:07+01:00 - trace: SWITCH: apply side block #58766-000024DECEAE129A809BCE40ED70CB529CCCFB9A6B120E7976E71A4F045528ED -> #58765-000003C30C3DD4E42400869964D1FCEC447A0DAC9A762055C4284318DB224631...
2016-11-29T09:28:08+01:00 - warn: Source T:5ECA9487CEF255DA1ED7B294DE118A3C51A5A329977295DE328741DEBC1AEDA1:11 is not available
2016-11-29T09:28:08+01:00 - warn: SWITCH: error %s httpCode=400, ucode=2015, message=Source already consumedOui, le problème qui persiste est celui dont le symptôme est relevé par @Tortue : le basculement entre branche est buggué (visiblement au niveau du mécanisme qui prévient la double dépense).
A noter que DUP 0.6 pourrait calmer le jeu, mais autant profiter de cette profusion de forks pour renforcer l’algorithme de basculement.
Pareillement, je m’y met dans la journée en espérant identifier la/les erreur(s) 
Edit :
J’ai donc trouvé l’origine du problème, liée à l’issue #704 aujourd’hui close.
Explication technique
TLDR;
Les transactions ne s’enchaînent pas correctement dans la blockchain, et créent des situations de fork à chaque nouvelle transaction émise tout en empêchant la résolution de fork de les résorber.
Le protocole spécifie depuis la version 0.3 que les blocs doivent avoir des transactions en version 3, peu importe que le bloc soit en version 4 ou 5.
Cependant, un bug présent jusqu’à la version 0.50.0 (incluse) de Duniter modifiait la valeur du champ Version de la transaction pour y inscrire la même valeur que le champ Version du bloc une fois celui-ci ajouté à la base de donnée du nœud. Donc, un nœud avec ce bug propageait des blocs incorrects tandis qu’il recevait un bloc correct.
Cela posait d’abord des problèmes de synchronisation : quand un nouveau bloc était trouvé, celui-ci ne se propageait pas sur le réseau étant donné que le bloc était vu comme invalide.
Sauf que ce bug a également eu un effet pervers par le biais des transactions : les logiciels clients tels Sakia/Cesium ont envoyé des transactions en référençant des transactions précédentes telles que le leur présentaient les nœuds, c’est-à-dire parfois avec une version incorrecte de transaction source. Logiquement, les nœuds auraient dû refuser ces transactions car les sources associées n’auraient jamais dû exister, mais ayant eux-mêmes enregistrés les transactions avec ces versions incorrectes, les sources associées ont existé de fait, et les nœud ont accepté ces transactions.
La blockchain se retrouve donc avec des transactions qui s’enchaînent entre elles via un mécanisme d’empreinte, sauf que celle-ci référence parfois une transaction en version 5, alors qu’une telle transaction n’existe pas (elle existe, mais en version 3).
Ajoutez à cela que le mécanisme de synchronisation initiale ne contrôle pas ni ne force la valeur du champ Version d’une transaction et l’on obtient un réseau pollué par de faux enregistrements, ce qui contribue très largement à l’apparition de forks d’une part, mais surtout empêche le basculement de branche d’autre part.
Cette situation crée donc des forks, et en plus les empêche de se résorber.
Pour résumer :
- la blockchain est intègre, au sens où les empreintes de blocs sont toutes correctes et l’intégrité des transactions est garantie par leur signature
- le problème vient de la référence qui lie 2 transactions, l’empreinte, qui est calculée avec une version parfois incorrecte
Solution
TLDR;
cgeek va faire une nouvelle version bientôt.
La solution que je retiens évite de revenir sur une partie de la blockchain (plusieurs mois …).
Je vais donc modifier le protocole pour acter le fait qu’un bloc v4 ou v5 peut contenir des transactions consumant des transactions précédentes dont la version diffère de celle signée originellement.
Concrètement quand un bloc passe, si celui-ci contient une transaction TB qui consomme une transaction TA d’un bloc précédent via une empreinte TB->TAv3, alors si la transaction TAv3 n’est pas trouvée, on tente encore 2 autres coups :
- TB->TAv4 (transaction source dont l’empreinte est calculée avec le champ Version: 4)
- TB->TAv5 (transaction source dont l’empreinte est calculée avec le champ Version: 5)
Dès qu’un des coups fonctionne, on s’arrête là. De sorte qu’aucune double dépense n’est possible : c’est juste qu’il existe 3 empreintes possibles menant à la même source.
3 Likes
Piouf beau micmac tout ça !
Bien joué pour avoir trouvé l’origine du problème et toutes ces conséquences ! 
Lors du passage en prod du coup tu garderas toutes ces conditions devenues inutiles ? Où tu feras le ménage (au risque de créer de nouveau bug) ?
N’est il pas intéressant de relancer une nouvelle test_net fraichement créée quelques semaines avant la mise en prod? (si ménage du code)
Tu vises juste … c’est un point délicat.
Mais en effet, je pense retirer tout code inutile afin d’avoir une base la plus propre possible, quitte à relancer un TestNet court (quelques jours, préparatoire à une monnaie de prod) afin de valider le code. En plus, ça aura l’avantage de chauffer un peu tout le monde avant la mise en prod et régler les derniers détails.
Il me semble que la simplicité est primordiale à la fois pour éviter les bugs, mais aussi pour que d’autres développeurs puissent contribuer à soutenir leur monnaie.
3 Likes
Dans tous les cas il semble bien de garder une monnaie test, même avec une monnaie de prod en route…
2 Likes
Oui excellente idée.
Peut être même pourrait t-on lors du lancement de la monnaie de prod, lancer une monnaie de test aux paramètres quasi-identiques.
Pour pouvoir, en cas de besoin ultérieur d’intervenir sur la monnaie de prod, faire dabord l’intervention sur sa monnaie teste jumelle pour voir si ça réagi comme prévu !
C’est ce qu’il faut faire, mais la monnaie de test devrait tout de même avoir un c test >> c prod le reste étant similaire. Normalement une bonne mise en prod passe pas une mise en environnement de test, vérification, avant de publier une release publique… Bon en pratique on ne le fait pas toujours, ce qui a tendance à créer des soucis… Mais il y a aussi des soucis à tarder à résoudre un bug… Donc bref…
1 Like
merci pour l’explication technique, c’est intéressant !
Je pense que même pour une version de prod ça peut être mieux d’avoir un cœur duniter capable de vérifier les transactions sources sous plusieurs versions différentes.
Car en cas de besoin, on sera aussi amené à avoir parfois (certes très rarement) un changement de version même sur une monnaie de prod non ?
Sans aucun doute. Bitcoin lui-même évolue et change de versions.
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é.
1 Like
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.
1 Like
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.
2 Likes
Tu veux dire à la “mise en service” de la monnaie?
