oui, transferAll va retirer le maximum de fonds possibles avec la configuration demandée, sans jamair échouer. keepAlive=false ne signifie pas “le compte doit être détruit”, mais “j’autorise la destruction éventuelle du compte”.
Non, le consumer est décrémenter quand le truc qui à incrémenter consumer n’a plus besoin de l’existence du compte.
Il n’existe pas de règle générale permettant de savoir si et quand les consumers seront décrémentés.
Il faut juste griser/désactiver la destruction du compte tant qu’il a au moins 1 consumer.
Tu ne peux pas. La notion de slot permet juste de déterminer qui est éligible à produire un bloc dans ce slot, ça ne garantit pas qu’un bloc sera effectivement produit.
C’est curieux comme la cadence des meilleurs blocs semble pertubé depuis quelques jours, vous ne trouvez pas ?
ça trottine un peu si vous regardez bien. Je suppose que @elois a des outils pour monitorer ça
1 bloc toutes les 8 à 15s en moyenne quand j’observe rapidement
Est-ce dû au fait qu’il n’y que 3 noeuds forgerons ?
Des fois 6s, des fois 12s, et 3 forgerons alors que authorityMembers.authoritiesCounter=4, je suppose que ça veut dire qu’un des forgerons n’écrit pas de blocs.
Il n’y a bien que 3 autorités, le compteur authoritiesCounter est buggé. En me temps il ne sert qu’à vérifier la limite MaxAuthorities je vais le supprimer.
Concenant le blocktime, je pense que ça à cause de l’arrêt de la finalité qui est bloquée depuis que le noeud de cgeek à été hors-ligne pendant 1 round. On voit l’offence au bloc 275971.
Le consensus GRANDPA ne supporte la perte de 33% des validateurs ou plus. Il en faut toujours plus de 66,6% en ligne.
Donc s’il y a 3 autorités on ne peut pas en perdre. S’il ya 4 autorités on ne peut en perdre qu’une, etc.
Je ne sais pas s’il est possible de régler ça sans reset la blockchain
Si il faut reset allons y, c’est fait pour !
Par contre avant, pour éviter que ce problème se reproduise, je propose qu’on s’occupe de faire une doc complète et claire sur comment devenir forgerons v2s de A à Z, je veux bien le faire avec Hugo par exemple, tout en montant mon premier noeud forgerons en parallèle.
Puis on lancera un appel ici à lancer plus de noeud GD, je pense que c’est le moment.
Mais je trouve ça très bien qu’on ai commencé avec très peu de noeud et qu’on ai eu ces problèmes, perso la plupart du temps pour comprendre quelque chose, j’ai besoin de me manger des murs… Sinon ça rentre pas
Moi je veux bien héberger un nœud, mais il faut s’attendre à des pannes régulières.
Je pense que ce n’est souhaitable qu’à partir d’un minimum de forgerons dans le réseau. Cela permet de tester la résilience du réseau en cas d’instabilité d’un nœud, mais il ne faut pas que cela mette en carafe le dit réseau.
Oui on va reset, je pense que ça peut être un bon exercice que quelqu’un d’autre bootstrap le réseau pour une fois, @HugoTrentesaux ça te dirai qu’on le fasse ensemble pour que tu apprenne ? On peut se afire fa en visio jitsi ou IRL ce week-end
D’un coup d’œil rapide je vois qu’il y a environ 1100 blocs non finalisés, donc le soucis viens de grandpa.
Certainement cette histoire de moteur à 3 pattes (manque de forgerons).
De toute façon je préfère me focus sur la ĞTest et lancer une ĞTest en Novembre à Bordeaux, on a pas besoin de monnaie de test commune entre temps vue qu’on peux tous bosser sur nos blockchains locales facilement.
Hi! we tryed to execute the purge chain commend in kapis’ node but we are not able because we get an error:
The command we execute is this: docker run -it duniter/duniter-v2s:v0.3.0 purge-chain --chain=gdev
The error message is this:
Starting duniter with parameters: purge-chain --chain=gdev --dev -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
error: Found argument ‹ –unsafe-rpc-external › which wasn’t expected, or isn’t valid in this context
If you tried to supply `--unsafe-rpc-external` as a value rather than a flag, use `-- --unsafe-rpc-external`
Any idea on how to solve it would be greatlly appreciated.
Rightnow the node is running, and the most recen block is 967764
