Je suis de nouveau synchro avec @Melua, le serveur g1-test.duniter.org également.
edit : par contre ça fait bien 10 minutes et pas le moindre nouveau bloc en vue 
J’ai rien dit !
1 Like
Le réseau est reparti. Mais il a fallut une intervention humaine manuelle.
@jytou, je pense qu’il faut peut-être s’organiser un peu pour les stress tests.
Propositions :
- Un contributeur lance un stress test à une date et une heure précise et prévient les autres contributeurs sur le forum. Le but étant d’observer ensemble le réseau et d’analyser les problèmes qui apparaissent.
- Un contributeur lance un stress test pour ses propres analyses. Sans prévenir personne. En ce cas, il a la responsabilité d’observer le réseau et de stopper son stress test au moindre problème. Si le problème persiste, il avertit les autres contributeurs immédiatement sur le tchat ou sur le forum.
Ainsi, cela évitera un effondrement et un blocage de 2 jours du réseau, sans que personne ne s’en rende compte.
Bon maintenant vous pouvez retourner barboter dans l’eau avec votre bouée canard. 
J’ai un Rasp qui synchronise pour ajouter au réseau GTest, il a vraiment du mal. Mais si vous voulez faire un stress test, ça peut être pas mal de prévenir des membres susceptibles de mettre en place un noeud, histoire que ça forke moins. Un stress test sur GTest aurait du sens à partir d’une dizaine de noeuds, non ?
Et j’ai justement commencé à écrire un script de spam, je le mettrai volontiers en pratique… Mais à partir de septembre 
Bon j’étais bien motivé mais j’ai manqué de temps. Je ferai une pre-release avec synchro WS2P la semaine prochaine.
Voilà qui devrait ravire les Raspberry PI, entre autres 
Il semble n’y avoir que vit qui calcule des blocs sur Ğ1-test.
1 Like
Le sujet est un peu trop long pour que je le retrouve mais il me semblait que quelqu’un avait proposé l’idée de rémunérer en ğ1 les personnes calculant pour ğ1-test. Ça me semble pertinent pour attirer les personnes souhaitant recevoir des ğ1 mais ne pouvant pas rejoindre la toile de confiance ni échanger des biens facilement (comme ce gars en Australie). Où en est la discussion ?
2 Likes
Personnellement je ne sais pas. Mais très bonne idée pour maintenir à flot ce réseau délaissé !
Tu peux lancer une instance Remuniter pour Ǧ1-test et faire un appel au dons pour ce compte Remuniter. Annonce ton projet sur un sujet dédié du forum et écoute les commentaires.
Si certains veulent t’aider pour la mise en place technique ils le feront et si les admins veulent héberger l’instance sur un des trois serveurs officiels Duniter, super !
Fait donc un sujet dédié de ce projet.
Je te soutiens, car je ne calcule que pour Ğ1-test…
Et effectivement, il faut soutenir les contributeurs techniques motivés, surtout s’il ne peuvent pas devenir membre à cause de la distance.
2 Likes
Vu comme c’est documenté, je ne vois pas comment je vais installer une instance remuniter : https://github.com/duniter/remuniter
Je pense qu’il y a plein de bonnes volontés mais les expirations d’adhésion sont fréquentes sur GT (à cause du rythme du réseau).
Vu comme c’est demandé, même si ça me prend 20 minutes, pour l’instant je ne vais pas documenter.
edit : 5h plus tard, et malgré mon exaspération, voici un peu d’aide.
Je lance Remuniter de cette façon :
node index.js remuniter --mdb remuniter --paychunk 500 --payperblock 20 --paystart 1
En détail :
-
--mdb remuniter: permet de forcer Duniter à utiliser le dossier$HOME/.config/duniter/remuniter. Optionnel, car c’est censé être le dossier par défaut quoi qu’il en soit pour Remuniter. -
--paychunk 500: effectue un paiement tous les 500 blocs écrits -
--payperblock 20: paye 20 centimes par membre pour chaque bloc écrit par lui -
--paystart 1: commence à payer à partir du bloc#1
=> Utile pour commencer la rétribution en cours de route d’une monnaie
Ceci étant déjà décrit dans l’aide :
node index.js --help
[...]
--payperiod <seconds> Number of seconds between each pay loop (default 180).
--paychunk <chunk_size> Number of blocks paid in each loop (default 10).
--paystart <block_number> Block number from which we pay issuers (default 0).
--payperblock <amount> Amount paid per block issued (default 1).
--nopay Disable Remuniter pay loop (equivalent to --payperiod 0).
À noter que Remuniter n’est pas pensé pour faire du cross-blockchain. Si vous souhaitez que Remuniter paye en fonction d’une blockchain externe, ou même sur d’autres critères qui n’ont rien à voir, il faut étudier le code et modifier la partie qui vous intéresse.
Je ne me rappelle plus moi-même précisément de l’algorithme, mais l’étude du pay loop est sûrement une bonne piste : https://github.com/duniter/remuniter/blob/master/lib/main.js
Le mieux étant de lancer sa propre instance localement en mode debug avec un Visual Studio Code ou un Webstorm.
2 Likes
Ca devient en effet compliqué :
Nous sommes encore deux à calculer, j’ai temporairement augmenté les ressources allouées pour aider.
Ah bah fallait le dire que mes 3 nœuds seraient plus utile sur G1-test.
Tu peux en laisser 1 sur la Ğ1 quand même, c’est le plus important
ok deal … 2 calculant (si j’arrive a créer un compte et a me faire certifier) pour test et 1 miroir G1
1 Like
Merci @cgeek pour ces informations.
En y repensant, je vois mal comment rémunérer le calcul d’un bloc par un compte membre de Ğ1-test, en Ğ1, sur un compte Ğ1 de la même personne… Comment faire le lien entre les identités, les comptes ? Non, vraiment, je crois que cette idée sent le sapin.
Il y a 2 nœuds dont un appartenant à “Vincentest” qui sont en 1.6.23. Il faudrait les mettre à jour !
1 Like
normalement c’est bon 
Le noeud avec la clef publique commençant par GF5i8XE2EdYyFKvpD2Fh est en 1.6.22 !
Merci de mettre vos nœuds Ğ1-test à jour en 1.6.25.